Delivering Value With Data-Driven Products with Logi Analytics CEO Steven Schneider

Hello, my name is Steven Schneider, and I'm the CEO of Logi Analytics. We here at Logi Analytics believe that applications are the best way to deliver information to end users, and we help software teams all over the world embed analytics into their applications. Makes those applications more data-driven, have a superior end-user application experience, and ultimately drive more engaged end users. But today, I'm not going to talk to you anymore about Logi. I'm not going to talk to you about why we're so great. I'm going to talk to you instead about what is a data-driven application, why you should care, and how making an application data-driven positively impacts both your end users and how it affects the various roles within your application team. But first, our fundamental thesis as a company and our reason for why we need to exist and why you should be thinking about making applications data-driven. First, we believe that software is, or will become, and now is, the face of most businesses. I think Capital One is a good example. If you ask most people what they think of Capital One, they would tell you it's a bank or a credit card company. That's how I think of it. I have a Capital One card in my wallet. That being said, I don't think I've ever actually spoken to an individual at Capital One. I interact with them every week through online software. I interact with them through the portals that they have. And if you ask the employees of Capital One if they think of themselves as a bank, they'll probably tell you they think of themselves as a technology company or a software company. ADP, what do you think of them? Business services, payroll? No, they'll tell you they're a software company. Even companies like John Deere, a tractor company and farming supply, Today they have a major software business as a part of their business. Software is becoming the face of most businesses and is becoming a predominant part of how most businesses interact with their consumers. Secondly, that applications are increasingly becoming analytic applications. 10 to 20 years ago, applications were primarily about data entry. It was about creating a sophisticated transactional system of record. And the flow of information was into the application from the end user, and it was about documenting what has happened. Today, applications are different. Data doesn't just come from the end user using the application, it comes from a myriad of different data sources, be it user input, business processes, machines, other applications. The flow of information is reversed. Now applications are much more about how do I get information from the application to the end user, not the other way around. And applications are expected to report not only on what has happened, but what is happening, what will happen, and what the user should do about it. And every application team today, whether it's a software vendor working on a commercial app or an IT team working on internal application, faces a challenge of how do I take my applications and make them more valuable to end users. And one way to do that is by thinking through what is a data-driven application and how do you make your application data-driven. Now, at Logi, we survey a wide range of software companies and application teams and ask them what benefits they get when they think about making their applications data-driven. And when they deliver analytics in the context of an application, the benefits that are delivered are different depending on what the role is within an application team. And just some examples, development teams that often get a number of end-user ad hoc requests for custom reports, custom dashboards, custom analysis, custom entries, are able to push more of those, more of those requests back to the end user themselves and enable a self-service model that frees them up to do more development, drives user engagement, and results in happier end users. And as a result, you see end users using more time in their applications. End users are now demanding it. 10 years ago, no one demanded it. They thought of their application as that transactional system of record. And now in most surveys, 85% of end users will ask for analytics to be part of the applications they use, and it will help drive increased customer satisfaction. Product managers at software and SaaS companies find they can charge more for it. They can differentiate their product for— and they can differentiate their product and improve their overall rates as well. And these are just a sample of some of the key benefits that in our surveys, they report that they see when they think about making their applications not transactional only, but also data-driven and analytically focused. Now, we talk a lot about— I'm talking a lot about data-driven apps. I'm talking about analytic apps. And I really haven't defined what that means. So let's talk a little bit about what dykes a data-driven application and what are the characteristics that we here at Logi think about when we look at a data-driven application. The first is that an application needs to be informative. And it needs to distribute insights to the individuals, the end users of the application, in a way that they can consume it in the context of the application and is relevant to their persona and what they're trying to do. And this is critically important because an application, for example, in the gym membership management space that is tailored for the users in a gym that are checking in and out users, for example, has a very different type of interface, a different type of UX, different types of information that they're gonna wanna receive compared to say an application that is in treasury management and focused on an analyst that wants the needs of slicing and dicing and working through the data. And even within one application, you have different roles. And so you need to be able to just distribute the information in a way that matches the needs of the end user of that application and matches their persona. So that's number one. Second, an application needs to be queryable. What does that mean? Well, that means once I presented information to the end user in a way that they can consume it, it needs to be able to allow them to ask additional questions. Because you cannot anticipate what all those questions are that people are going to have in advance. Right? So it must give them permission, perhaps with guardrails, but permission and opportunity to further explore the information you're giving and ask questions that you didn't anticipate. Third, it has to be actionable. So what does that mean? Well, I've now delivered information to the user so that they can make a decision. In that gym membership example, Maybe that decision is a user has come into the, to the gym and I want to intercede and offer them a personal training session or something based on some characteristics. How do I do that? Well, by making the analytics in line with the transactional part of the application, you can very quickly make it easy for that user to press a button and immediately kick off a personal training session or immediately kick off a backend workflow. So it has to be actionable. You can't just give the information to a user and then say, now you have it, go do something with it, and not actually provide them a mechanism to do so. And that's— so that's another important characteristic of a data-driven app. Fourth, predictive. Well, so in that gym membership example that I talked about, applications now have to have a view on not just what has happened, what may happen in the future. And in the gym membership example, that user's coming through the turnstile to check into the gym, and the person at the front desk sees them and is checking them in. What if that application can actually look at the characteristics of that user or that person coming to the gym, the characteristics of how often they've come now and come often in the past, and predict their likelihood of churn and give that, give that person at the front desk the opportunity to intercede when it looks likely that that person is going to quit the gym here soon and actually take action by saying, how's it going? What's happening? Maybe you need a personal training session. So these applications are now becoming more predictive, uh, in terms of looking at the information they collect, not just from user input, from all those other data sources, and informing the end user of that application on what they should do. And finally, self-learning. So this is less about things that the end user actually takes action on and sees, about providing feedback to the application team on what is working and what's not. Now, if you were to go back, I used to say 10 years ago, 5 years ago in many applications before that advent of continuous delivery models and where people are still pursuing waterfall or even every couple months type release cycles, there was a gap between how a user interacted with the application, what they thought of it, what worked, what didn't work, what the performance was. And it was often done through surveys or looking at logs. Today, by delivering analytics embedded as part of that application, Advanced applications can understand what users are using and provide immediate feedback to application teams on what's working, what UX workflows break down and people don't get access to information they need, what questions are being asked in the queryable sections that maybe we should answer out of the box. And that provides feedback to the application team and to product management to better deliver software in their next release that meets the needs of the users. Now, engaged end users is great, But if I'm a product manager or software and SaaS company, I need more than that. And so what are the true business benefits that once you start making application data-driven that you could derive? Well, for one, you can differentiate your software from competitors, resulting in higher win rates. You can reduce customer churn by improving engagement, having higher and larger number of end users. In fact, larger number of end users, especially once you span the one or two personas that maybe are using it more, most frequently, and expand that usage base through more analytical capabilities, you can increase overall revenue, you attract new end users, you can overall increase customer satisfaction. I'll tell you, at Logi, many people come to us not because they just have a new product that they want to embed analytics in and be part of that and derive as part of that application, but also because they may have a product that has been around a little while and they want to overall modernize that application to decrease churn, and increase upsell from their existing customer base. QAD is a good example of that. So QAD— well, not that last example, but QAD is a good example of a software company that is using analytics at the forefront of their application to drive differentiation, increase revenue. So QAD is an ERP software company. They make software for ERP and supply chain for global manufacturers. And when QAD set out to deliver their next generation application, they wanted to transform the ERP space and crush SAP. And they wanted their app to be more than just that transactional system of record. They wanted to embody this concept of using the application to push information to end users. They came up with a term, they call it decision-making intelligence. And one of the most— and the most important things for QAD's CTO was to keep users in the application. They wanted to make sure that they weren't just providing a subset of the information that they needed. And then require users to go outside the application to a centralized BI model to get it. But they want to make sure to deliver the information in the context of the application and allow the end user to take action based on that information all within the application. He and the rest of the QAD team recognized the value of the data that they were capturing. And whereas 10, 20 years ago, the value of the application was about capturing the data, now so much more is about how do I recognize and utilize the value of the data that I've already captured and I'm gathering from all those sources. Resources. And taking that data out of the application and relying on some kind of central BI tool or some kind of analyst sitting somewhere in another room actually diminishes the value that that application provides. Now, and that was a critical thing for them when they thought about their next generation application and how they were going to deliver these data-driven applications of the future. Now, I've defined what is a data-driven application. I've defined the characteristics of a data-driven application. But if you look back at these questions or these different characteristics that I talked about, many of these you will look at and say, well, these are very end-user aspects, right? I'm looking at this and I'm saying, oh, as an end user, I need to be informative. As an end user, I need to be able to ask more questions. As an end user, I want to be able to take action based on the information I get. As an end user, I want to know what's going to happen so I can take action on it. Those are all very end-user type characteristics. But as you think about delivering these data-driven applications within your organization, there's a number of other roles that are affected that both— that will derive business impact from this. So yes, end users will access the power of analytics to make decisions and they'll make better decisions. Yes, they'll be able to work through the data and ask questions they don't know and collaborate and share with that information. But there are other roles that are really important that have a stake in this game. Product management is one of the key ones. And they're a key role in the application value chain. Product management cares about making sure they have a differentiated product. So just going and saying, here are my 5 competitors and they are doing these 5 things from a data-driven standpoint, let's do that, isn't really adequate and isn't really going to move the needle. It's about thinking about from my application and where I play in the segment of the market and the value that I want to provide, how do I provide a differentiated offering through analytics. It's about how do I deliver my roadmap on time and on scope, and how do I do that without taking away from all of the other things that my development team needs to do, and how do I focus on the priority, most important things. And the third thing, which I think is frankly critically the most important, is how do I make sure to deliver the ultimate— to maintain ultimate control of what my end user experience is as a product manager, you are tasked with the impossible. You are tasked to build the perfect application for your end users. It must exactly match the needs that they have when they have them. The UI flow has to exactly match the use case that they're trying to accomplish and the skill level that they have. And it needs to be your product. And so as you think about delivering these kind of analytic applications, Just outsourcing that to kind of a third-party BI system that you go out to, that they then will ultimately leave your application experience to get access to the information they need, means that you lose control. And you have to think about these analytic applications as your application. And you got to redefine what is the experience that you want your end user to have. And having that ultimate control is critically important. From a development team standpoint, as you think about taking a transactional application and moving to more of an analytic application. The questions that this development team often ask are, how long is this going to take me to build? How long is it going to take me to deploy? Can I leverage the existing technology infrastructure choices that I've already made? And this is particularly relevant in older applications where they were designed around transactional models. And so the data sources and the data models are set up to support that and not necessarily set up to support the modern data sources designed for high-scale reporting or high-scale analysis. DevOps is a really interesting role. So I will tell you, here at Logi, and we work with 1,000+ software teams all over the world, DevOps is a role that we only began to see play a major part of our— the decision process a couple of years ago. That day is gone. DevOps is in every single opportunity that we talk to, and they play a critical role in making sure that the end product is delivered a clear role in making sure that it scales, that it scales in a cost-effective way, that it's highly available. And so as you think about taking a transactional application and making it an analytical application, not only the user requirements change, and not only the requirements for product and development change, but those DevOps requirements change as well. In a self-service model where you're allowing end users to create their own reports, their own dashboard, their own visualizations, their own analyses, there are artifacts that get created. How do you make sure those artifacts are maintained, for example, as you deploy multiple versions, or you move from one piece of infrastructure to another, or you scale? And so these are all the things that that role understands as well. And it's important to understand all of the different business impact that each of these different roles are trying to derive as you think about making an analytic application. So today, I've reviewed— What is an analytic application? What is a data-driven application? What are some of the key characteristics that make it and why you should care and why they drive certain benefits? I've talked a little bit about a case study of a company, QAD, that is essentially building their whole next-generation application and product around this mindset of data-driven applications, a term they call decision-making intelligence. I've talked about the different roles that you need to consider as you think about making data-driven applications. I'd like to leave you with a couple of takeaways, and then I'll answer some questions. First, you can't think of applications as transactional systems of records anymore. For the most part, that day is gone. It's about the direction of flow of information has changed, and you need to think about how do I present that information to my end users. Second, you will find that by making your applications more analytically driven, they will have increased value, higher user engagement, and stickiness in the applications, which derives a whole host of business benefits such as decreased churn, higher overall revenue, better product differentiation leading to higher win rates. But then as you go out and you deploy these analytic applications and you think about these analytic applications, you have to always keep in mind the needs of the end user of your specific application, which is different than almost any other application out there. And that is why maintaining that ultimate control and not pursuing a one-size-fits-all approach is most recommended. So with that, I thank you for your time. I'll answer some questions now. And if any of this interested you and you'd like to learn more, I would encourage you to check us out, Logi Analytics. We empower the world software team with the most intuitive developer-grade analytics that can be embedded in the context of your application. With that, let me see what some of the questions are here that have popped up. Let's see here. Uh, is the slide deck available for download? That's a good question. Uh, yes, it will absolutely be available to download. Uh, if you'd like to contact me, steven@logianalytics.com, I'd also be happy to provide this and any additional information as to how we think about data-driven products and analytic applications. There's also a question about recordings. Those will be available as well. I don't know if there's any other questions. If anyone else has any other questions— oh, one just came in here. How would you prioritize what metrics or KPIs to use to develop a product? Well, so the first thing I would do is I would look at my end users of the application and understand what are the core metrics and KPIs that they hope to get out of their application, right? It really comes down to the end user requirements. Now here at Logi, we think a lot about keeping it simple because it's very hard to kind of pre-think what all the different things that people are going to want are. So focus on the 5 or 6 KPIs that we think are most relevant to the end users. Empower them with an end-user self-service capability, that ability to ask more questions, and then monitor through this self-learning model. So monitor what questions people are asking, and those are your best candidates to then move into the kind of informative buckets where you're just providing that information out of the box without them having to ask things. Okay. Um, can you give another example queryable as a characteristic of data-driven applications? Well, this really comes down to giving end users the ability to ask more questions through some sort of interface. And that may mean navigating the data model of your application. That may mean creating a standard report that has a metric that one individual using that application or a small set of individuals using the application want to look at on an ongoing basis. So kind of a report builder type concept. It may be providing an analyst-driven type interface. I used an example earlier. I think of a treasury analyst at a financial institution. That wants to take a dataset and perform a more freeform analysis on that data in real time and save some of the results. And those are all examples of, of queryable type models that you can deliver as part of an application to allow end users to ask questions that you haven't thought about in advance. OK. One of the comments here is data-driven decisions can only be made if there's a large dataset available. Is there anything to be done if I have a limited set of data? Well, again, it comes back to the application. But we're seeing a lot of companies starting to enrich, for example, the data that are in the application. Again, data applications before were primary— or applications before were primarily based just on the user input. You start thinking about the type of data that you can collect that would be informative to the application from other business processes, other applications, other data stores, or even enriching the data that people enter, I think you'll find there's a lot of really good valuable information in there that is going to be helpful to your users and drive engagement. Let's see here. When an organization is looking to deliver analytics, they usually want those analytics delivered in the context of their domain and not unstructured BI. How do you work with embedded customers to build that domain experience, expertise into the analytic experience? What I would argue, that is the role of the product manager, right? The product manager's role is to understand the need of the users and to tailor that analytic experience in the context of the application so that actually matches the needs and understanding of that end user. And I think that's actually where BI has failed in a lot of ways. I mean, I would argue that the entire BI industry started because of the failure of applications to deliver analytics in the context of their applications, right? Why would you take people out of the apps where they do their job all day and take them to a central place where the security doesn't match, the fields don't match, the timeline doesn't match? This is crazy, right? So I actually think when you flip your mindset and say we don't need that centralized BI model, but rather we're going to deliver people information in the place where they work every day, and you can empower product managers to do that, that's just a much more powerful mechanism for distributing information. And people are asking about, like, well, how would this work with unstructured data? How do I work with timescale data? How do I work with all these different kinds of things that are not necessarily traditional operational type data or transactional type data? Well, look, Logi, that's what we do. We are exclusively focused on helping application teams deliver analytics within the context of the application. And so it's the exact kind of problems that is part of our developer-grade platform we deliver to help application teams do that. Okay. Some people are asking questions here, and I'm happy to provide this after the fact, is, are there content available on things like SaaS metrics of what does MRR and ARR need to be, and what percent of MRR and ARR should they be when I talk about charging more for analytics? We have benchmarks as part of our State of Embedded Analytics report, which if you Google online, you could find that, that detail what are people often charged extra for, how do they segment. For instance, there's maybe a small piece of analytics that comes part of an application that's for free. There's other parts that are more— that can be resulting in upcharge. There's really a myriad of different packaging options that exist. One of the questions that come up is, have you seen demand for integrating machine learning into embedded analytics from your customers? Customers? The answer is yes, but we really group that into kind of a predictive model. Really what it comes down to is how can I embed predictive models into a multi-tenant type application so that I'm looking at the data model specific to that customer and making informed recommendations on what should happen. And we're seeing that, for example, in healthcare. I saw that in a scheduling application was a really good example where they were looking at no-show rates and how do I model and optimize how many people I should schedule from a clinician standpoint to take into account no-shows. And in that example, it's not about, for the end user, machine learning. It's about how many people can I schedule. It's about making it very simple and very actionable in the minds of the persona using the application. It's 10:24. I think I only have one or two more times, um, one or two more seconds for a question. Um, so I'll give you here this one, one last one. How do you see traditional reporting evolving as more self-service analytics and dashboards available within applications? If I only listen to my users, I have to continue to maintain traditional reports. So I'll tell you that I think there's a difference of opinion, even within Logi on this thing. I will tell you the traditional reports are not going anywhere. As CEO of a software company, I get a whole host of traditional reports every week, and you will have to pry those traditional reports out of my hands, out of my cold dead hands. I rely on them, but that doesn't mean that's all I rely on. I also rely on self-service capabilities. I also rely on predictive capabilities. I also rely on dashboards, right? So it's really about a maturity of expectations from end users and in terms of how they want that information delivered and what's the best way for them to get that information. We're at 10:25, which I was told was my cutoff. We are at 22 open questions. So there's a whole host here on here. My email address is steven— S-T-E-V-E-N— @logianalytics.com. If I did not answer your question, please send it to me, or if you have additional questions that you didn't put on, and I will make sure that we get an answer to you relatively quickly. With that, I think that's my time, and I thank you all for joining. Thanks so much, Steven, and thanks to all of you. Hope to see you on other sessions. Enjoy SAS or Annual. Have a good one.