 We welcome you all to the session Eyes on the Price, how we use KPI trees to maintain focus on business outcomes. The session will be delivered by two Shrees, Srikanth Balakrishnan and Sriram Narayanan. Srikanth Balakrishnan is the Technology Director at Travelopia. He is currently responsible for innovation and product management at Travelopia. He runs a global innovation team there with spans across multiple geographies and time zones like India, US, and Europe. Sri loves product development, change management, and re-engineering. Welcome, Sri. We have Sriram. Sriram was formerly VP, Transformation Advisory at ThoughtWorks, currently as a product management consultant. And prior to that, he has held a product tech and innovation leadership positions. He helps tech and non-tech organizations worldwide to improve their performance through changes in their operating model, organization design, and ways of working. And, you know, he also helps to deal better with some of the challenges in the digital age, especially with COVID and remote working. Without further delay, I'll hand it over to both the Shrees. Sri, please take it over. Thank you. Hello, everyone. Thanks for your interest in this topic. Let me quickly share my dream. As software delivery teams, we are under a lot of, you know, there's a lot of work we do, a lot of some of our work sees the light of production. Some of it doesn't, unfortunately, go as a way to production. But this talk goes beyond that. It doesn't stop at production. It says, okay, so what if it went into production? What after that? How did it really help the business? Because if you think about it, like, why do companies invest in technology in the first place? They are looking for some kind of benefit. I skipped ahead of myself. I should have said that there are three sections in this talk. I'll be taking the first and the last section. And the part about how it's being used at Travlopia, I'll request Sri to talk about that in the middle. So as I was saying, why do companies invest in technology? Because ultimately, they want some kind of business benefit out of it, right? They want to either grow their revenue or protect their revenue, reduce churn, or save some cost, or they want to reduce risk, be in compliance with regulations, they want some business benefit. And so they invest in technology. But there is a path from the investment to the business impact. There is a path. And that path is generally understood as the inputs to impact sequence. So there are inputs, what you want to do. Then there are a bunch of activities. Then there is the output of those activities. That output results in some immediate outcomes. But those immediate outcomes are really meant to create some ultimate business impact, right? So this is known as the inputs to activities, sorry, inputs to impact sequence. And it is quite its well understood sequence, even in the social development sector. They understand this sequence and they use this sequence. I have drilled into that a little bit. I have expanded it out a little bit on this slide to say that there are two kinds of inputs. There are decision inputs in order to make the investment decision. And there are execution inputs to begin execution and for the ongoing execution, there are execution inputs. So what does this mean in our world? In our world of, when we are supporting the business through the development of digital capabilities, or if we are building software products, what is this map to? So a decision to invest in a feature or a capability or a digital initiative is usually backed by some kind of business case, right? It might be a formal business case, or it might be an informal pitch, whatever it is. So there is a business case based on which there is a go-no-go decision like, okay, should we invest in this or not? Once the decision is made to invest, that's when you start planning for execution. And as part of the planning, you might do some specking out of what you want to build. You might describe it in the form of requirements or you might describe it as hypotheses and so on. Execution goes on. There's a roundup development and then software goes live in production. Ideally, this whole process is iterative. It's not linear as it is shown over here. But we know that that is not always the case, right? Especially in large organizations. Although in theory, they recognize it needs to be iterative. In practice, it is often linear. So software goes into production and then as an outcome, there might be some kind of improvement in some low-level metric, what we call as product analytics or service analytics. Typically, it's a product or a service analytic. There is some movement in that low-level metric. But what we really need or the reason why people decided to invest in that initiative or capability or feature, whatever it is, is because they were looking at this side of the picture. They were hoping for some business impact out of that investment. So movement in a metric that matters, not just in a low-level metric. So to take an industry neutral example, let's say you're running some kind of business where you're operating a call center. And during the pandemic, for example, people could not work out of the call center. And at that time, there was a lot of talk about, hey, we need to switch to chatbots, right? And even otherwise, people want to minimize the call volume at the call center because as the business grows, they don't want to keep hiring more and more people at the contact center or call center. And so somebody creates a business case saying, hey, if we do chatbots, if we invest in chatbots or they are called virtual assistants in some places, say if we invest in them, we'll save call volume and we'll improve customer experience, right? Because customers don't have to wait waiting for an agent and keeping hearing some music and so on. So that's the rationale for making the investment, right? And ultimately, whether you buy a chatbot, whether you build it, you might have to, even if you buy it, you might have to configure it for your use case and so on. But you have software in production, which is live in production. And usually, many teams just stop at this point. They say, hey, if you put it into production, success, we have a successful agile delivery and they stop at that point and they move on to the next project or initiative. Some teams, they actually go forward and say, okay, we put it into production, but what is the usage like? Is the chatbot being used? And they might actually say, oh, okay, during peak hours, when it most matters, we are seeing thousands of sessions for our chatbot. That means, yes, there is a great, great adoption for our chatbot and we might celebrate that. But the point is, is this the real? Is this the final outcome? Is this the thing that you're caring about? From a business point of view, even this falls short. Okay, so what, you had a lot of chatbot sessions, but how do I know that people are maybe interacting with the chatbot and maybe they are not getting the full answer for what they wanted and maybe they are still ending up calling the call center? If that is happening, then really, the objective is not met. So really, what you want to demonstrate is that not only there is a lot of chatbot sessions, but actually it's helping to reduce the call volume in the call center and it is improving CX. So that is what we mean by business impact in this context and demonstrating improvement in a metric that really matters. And this is very often, this is missing, especially in large organizations. This itself is not so common. This is really rare in big organizations and there are reasons for that. One of the main reasons is this path from outcome to business impact is not simple. There might be many factors contributing to this business impact and your whatever you're doing might only be one of the factors. So even if you attempted to draw that correlation that because of what we did, call volumes is going down, it's usually not so straightforward to make that connection. And that is where something like a KPI tree, which we are going to talk about in this session, can help. Because when there are multiple factors that influence the ultimate impact, you need a shared understanding of what those factors are. And I have found in my consulting experience that if you represent those factors in a tree like representation, so this tree is now sideways. I've drawn it sideways here to illustrate the path from outcome to impact because at the outcome level, there might be many factors. But at impact level, you're concerned about one or two metrics that really matter to you. So if you had a tree like representation, then it helps to clarify that, okay, what I did had actually moved the needle on this particular metric over here, which then impacted this metric and which then impacted this metric. You'll be able to at least reason about your contributions to the metric that really mattered. And so that is what we call as a KPI tree in this context. So to illustrate this in the context of the chatbot example, we just, I just talked about what we care about. The metric that we care about is call volume. That is why the business or the decision makers, they decided to invest in this technology. But let's this scenario here, it captures the situation before the chatbot. It says, what does your call volume depend on? Call volume depends on a number of factors. I'm not captured everything here. But the more you do self service, the more you enable self service, call volume is going to go down. That is one factor. On the other hand, the more your business grows, call volume is going to go up. Similarly, there are external factors like holidays, maybe during holidays, the call volume goes down depends on the geography and the culture. But there are external factors also that influence something like this. Now, what we are talking about through our digital capabilities is we are talking about enabling self service. So chatbot is not the only thing that helps self service. Even before chatbot, you are the IVR menu, the interactive voice response menu in your call center is also a self service channel. Your website is another example of a self service channel. Your mobile app is another example. And what we are doing with chatbot is providing yet another channel. So somebody says, I want to fund this initiative, makes the pitch that we should spend some money to develop chatbots. So that becomes an initiative. And in the KPI tree, as initiatives are approved, you can grow the tree like this and say, okay, I have a new initiative that is meant to move this metric. This metric, along with other channels, will move this metric, which will ultimately move this metric. But acknowledging that there are other contributing factors. This is just a quick overview of what are KPI trees. We will see more real-world KPI trees when I hand over to Shree shortly. But just to summarize, so what is a KPI tree? The concept itself is not a new concept. If you Google for KPI trees, you will find some material. But the way we are using it, and the way I, when I engaged with travelopia about a year ago, I found an opportunity to, I saw there is an opportunity to use this particular kind of tree in some context in travelopia. And that is why I shared it with Shree and she liked it and it has been adopted quite a bit. So ours is a specific type of tree where the bottom of the tree consists of product analytics, service analytics, process analytics. And you have the ultimate outcomes at the top. And why are we calling it a KPI tree? Because every node in that tree represents a metric or a KPI. The tree does not have your, it does not represent your roadmap or what your, it does not represent what you're going to do to improve that metric. That is an initiative. An initiative is something that you fund and execute in order to hopefully move some metric. But those initiatives are represented as an overlay. So these yellow boxes are not part of the KPI tree. They represent an overlay. You know, you are saying through these initiatives, I'm hoping to move this particular metric in the KPI tree. So with that sort of context setting, I'll now hand over to Shree for taking us through how we are using it at Travelopia. Over to you, Shree. Yeah. Thank you, Ram. Can someone confirm, can you confirm Ram? Can you see my screen through the screen? Yes. Excellent. Good morning. Good to see everyone. Good participation today. Thank you, Shree Ram, for setting the context. I think before I jump into Travelopia and the context, I think one thing that we need to understand is like Shree Ram said, software delivery is one part of it, right? But how do we kind of constantly focus on if we move the needle? And my challenge that I work in Travelopia and any other company has been, how do I do things to ensure that the outcome is moved and outcome could be an overall top-level final movement of key metrics of the company. And in Travelopia, I'll give you a brief on why it is relevant for us. So just the introduction of Travelopia, in terms of Travelopia is a KKR-owned company and we are a portfolio. We have about 10 brands that represent Travelopia and the number of projects at any point of time that we run will be 80 to 100 projects at a point in time, right? So the kind of the context which that the leadership team, myself and other directors have to go through when we work with different brands is extremely crazy, right? So reading a lot of text is not the easiest thing when we jump across projects. And of course, when Shree Ram, I got him as my advisor coach on how do we solve this at scale. And that's when I was discussing with him saying, hey, I'm struggling with consuming so much of parallel information and I can't really synthesize this information. And they started as a simple conversation saying, hey, we should probably try this KPI tree and see if we can represent our various set of brands information in the structure. Yeah. So that's the genesis of KPI tree at Travelopia. We actually took a real life example of one of the brands that I work in Travelopia and kind of say, of course, I can disclose the brand name, but kind of high level must all the, you know, PII information, but at least it gives you a sense of how certain initiatives, which is if you look at the pink color, yellow color, both are the outcomes, outputs of the technology team might be focusing on, which connects back to different project investment, which again connects back to different teams. Yeah. And if you look at the top one, which is the green color, the ultimate outcomes, that's when it kind of impacts the sales team or customer experience team or a risk team or one of those teams, right? So just to give you probably an example here, I don't know if you can see my mouse movement. Can you show it up? Yes. Okay. So if you look at one of this example, the rate came to me was saying, hey, can you simplify the domain, right? Of course, we can simplify the domain because the brand had about 20, 25 domains running in 20 different websites. And we said, oh, we can simplify the one domain to the main, but the question constantly was why? And then there was many answers that came, but we laughed into saying, it's either content discoverability or reducing the endeavors, which the hypothesis, again, this is an important one to remember, whenever we are doing all this, business leaders tend to say, oh, I'm going to save X amount of time, but those are generally hypotheses that need validation, right? So this activity leads to this outcome of marketing, reducing the adverse, which further leads to reduce increasing the number of leads that enhances the sales, right? That's how we can tie it back to a bottom node, which is yellow color to the top green color. Yeah, just to just just expanding this a bit more on a very specific use case. So for example, one of the projects that came was, hey, how do we ensure that the sales team is increased spending more time on newer sales, right? So we did an audit on what they are currently doing. And we figured out that they're spending too much time on after sales calls. Then we started looking at, okay, they're spending too much time on after sales call, what all can we do, right? And that's when we said, if there is a self-serve portal, hopefully it'll reduce the after sales call. Now, of course, it's to be seen whether that initiative will lead to that outcome of reduction of after sales call, but at least that's how the hypothesis is built and worked and expanded in Germany, yeah. How do we use it in travel? We use it, for example, to track the brand outcomes, like I said, I have 10 brands to deal with. So brand outcomes, we kind of use it. We also have internal shared services. So we also kind of use KPHG to track what are the outcomes of the shared services? How does it invite different teams, different projects? So those are two actual use cases that we kind of use it. I mentioned a bit earlier about it, but I think and being a large organization, I mean, we are a 2,500, 3,000 people company globally. So to get access to the CXOs for these discussions are monthly ones or once in two months, right? So the number of projects, the leadership team generally handles this quite a lot. So cognitive load reduction is definitely one of the biggest challenges we had. And we're trying to reduce that using a KPHG, yeah. And it's not just my statement. I also got it validated by some of the other CXOs who are using it. And it's, yeah, this makes sense because I can see all my initiatives that have been telling people in one snapshot. Very, I mean, this happened in the last couple quarters where you kind of realized, like when you introduce a tool, of course, leaders like me and Sriram would have kind of spent a lot of time initially canvassing for this tool. But later, when we start seeing adoption of the tool, it was, it was interesting to see there are tools, testing use case that emerged by using KPHG, right? So one on the left side, the project came saying, hey, can we do lead automation? So the yellow color that I'm pointing here is what came in as like an activity saying, hey, can we do lead automation, right? And why do we want to do lead automation? So this is lead automation is about assigning a lead to a particular salesperson as soon as the lead comes, right? And the working assumption at that point of time was it'll improve conversion, all right? So the project came to the technology team, it was just these two. Oh, let's do a new version of lead module, so that we increase the conversion. And when our product team had done a deep dive, they figured out that it's not just conversion, there are a lot of sub metrics that we can impact, right? So for example, we can improve the percentage line leads, we can improve the average first time to attempt, we can improve the number of attempts, which increases the average first time to contact, hence improving the conversion. But the lead automation module only impacts the percentage line leads, right? So from a macro assumption that conversion will increase, you're able to kind of identify a metric and say, okay, that's a metric that we can now start focusing and implementing if we do a new software, not all the metrics, right? So it was also kind of a bit of realization for the business thing, oh, just software, just do software won't help, we can potentially have to try different things to make conversion better, right? On the right side, I think there's another interesting example where if you look at the yellow initiators, which is TX dashboard, TX we call it TRIP execution theme and the DVDs day by day, which is again part of an operations activity. And if you look at the top, this both was requested by one team, which is a TRIP execution team, yeah. Now the TRIP execution team only has so much time to participate in a development activity, right? I mean, when I mean by participate, they need to participate in planning, daily stand-ups, rolling out testing and whatnot. And then when we realized it, hey, the team is asking for two initiators, which is TX dashboard and day by day for guests, but the TX team doesn't have the capacity for supporting both, they only have capacity for supporting one. And remember, we are a running travel business, which is very different to a SaaS business, right? I mean, we are a running ship and we're doing technology transformation. So when you run a business like that, it's very different from an Amazon or a technology-first company. So we had to prioritize. So this was another example where we really could say, oh, we're asking for too many things, can we stop one and kind of focus on one, get the maximum impact out of it before we start the next, yeah. So metrics identification and prioritization or two other initial examples, we could find the due action. The other one is, I'm sure all of us are familiar with business cases, especially if you work in a leadership level at a large company, business cases are quite common. And one of the challenges, like I said, text is always tough to consume. You have to read, read, read. But in a KPR tree, it's easy to visualize and then you can start focusing on, okay, which initiator are we really focusing on? Is it the initiative X, initiative Y, initiative Z, or which metrics are we focusing on, right? So it becomes a much more pointed direct conversation rather than much more those conversations in a general business case talk. Yeah, again, we talked about this summarizing, which is initiative comes saying that both are important, but then we kind of find out what metrics can be important. In fact, then kind of prioritize X versus Y. Yeah, this is very interesting. So I think sometimes you don't realize, we can have bottlenecks while we do initiatives, right? Because it's the same thing that is going through a change or the same team may not have enough people to support it. So when we kind of take initiative X and initiative Y, initiative X might be done by squad one initiative, Y might be done by squad two, but it impacts the sales team, you kind of realize that they may not be able to consume all of it at one shot, right? So definitely we need to visualize that bottlenecks. The other areas, what we have started seeing as, I mean, we're trying to see used across the board for sure, asking very tough questions like why do you want to get this done? Are you really sure this is improving the metrics or not? If yes, by how much? Otherwise stop the development, it's otherwise wastage of investment, right? Definitely avoid duplicate parallel initiative. And I've seen this where technology is trying to do something, the CRM team is trying to do something else, marketing team something else, but the moment you put it all together, we kind of realize that all of us are chasing the same goals, can we all join hands together and work together rather than parallel initiative? Yeah. The third point was very interesting, I was sharing this with Sridharam that, I mean, of course, software engineers like to move around because they like newer experiences. And so what we realized is when new team members want to come on board, whether it is a product owner or QA developers, sometimes earlier it used to take ages to explain the context why we're doing what we're doing and to excite the developer on one of these years. And this is super simple, right? Five minutes you explain the context, everyone is onboarded, the bigger picture is here, right? And that, of course, helps in sharing understanding and alignment. And the most, most, most important which I'm eternally thankful to Sridharam's advice in the last one years, it just really helps to make business more accountable, right? So in the past, one of the constant challenges has been the, okay, the technology is delivering this and the magic happens. And we all know magic doesn't happen, right? Technology transformation has stopped and it has been owned by the leader. But there's always this assumption that you write a piece of code and technology will just transform my business, which is never the case, right? So with KPH3, what we started doing is going back on slides. So for example, in this slide, we can always say, hey, we can, of course, develop the TX dashboard. I'm talking the right side TX dashboard example. But then, coordinating with a guest of execution productivity, you know, execution team productivity is all the ownership of business, not the ownership of technology. Of course, technology can help, but it's not technology alone cannot impact the right. So making them accountable in this activity, I'm responsible for this, but you need to take ownership of the other side. It becomes like a left and right hand conversation. And that I find it extremely pleasurable and joyful to kind of make them accountable. Otherwise, the assumption was technology will own everything and deliver the magic, right? Yeah, how do we maintain it? Should we want to add some thoughts here? Sure. I mean, there is, I think one more slide where I won't take over control, but I'll just quickly. So yeah, Travlopia was already using Myro for a bunch of things. And so we felt it a good fit to use, use it for this tree as well. Although, you know, you can, you could even start off with, you know, like if you're using Office 365, then maybe you could even start off with PowerPoint, or if you're using something like Lucid charts or things like that, you know, any, any kind of collaborative diagramming tool that you have, you could use it. It needs to be owned by either a business owner or a business tech partner or what is called as a business relationship manager in some cases. Or it could be owned by the product owner depending on your situation. If there are trees, if you are doing trees for shared services, then the managers of those shared services could own those trees. Then the extent, extending its use is that if you're also tracking, say, initiatives in JIRA, right? You don't, you don't only have, say, JIRA or Azure DevOps or whatever you're using. So not only you have, say, epics and features, but you also have, say, initiatives mapped in JIRA, then you can put a link backwards and forwards from the KPI tree to JIRA and back so that even, even, you know, everybody, people who live mostly in JIRA can also have a traceability back to the KPI tree and vice versa. People who look at the KPI tree can go into JIRA as well, right? And so there are some details of how to do that, but, you know, you can, I don't want to go into that. I think that there is one last slide, Sri, that, that, which is the next one, which is also yours. Yeah. Yeah. I think we talked about it earlier, but I think the most important thing is it just calls out what can impact and what cannot. So in this case, we had a very interesting example where the business said, or do this initiative and the safety will save a lot of time. Yeah. And when we first heard it, we said, yeah, fantastic, we'll jump in, we'll start building this module, we'll start solving this, and we all started building the initiative. We started doing things and that's when we started using KPI tree and it made us realize that we can save time for the business by doing an initiative, but what will business do with the same time is something the business has to kind of figure out, right? It can't be owned by the tech. So I think, again, this was a great example where sometimes we think it's common sense, but it's not so common sense that people don't recognize that it's a common knowledge. So the moment we had KPI tree, we said, yeah, we'll finish this initiative, but then saving time goes back to the pillar head or the business had to see what exactly it can do with the same time, right? So some very interesting details, a healthy conversation KPI tree facilitated for us, which is fantastic. Yeah, I guess it's back to you, Ram, right? From the next slide? Yes, yes. Thank you, Shree. Let me, in this backup, share my screen, of course. Yes. Yes. And hide my controls and get rid of my desktop. Okay. So this is the last section where even, I think, it's been a few months or maybe six months or six months plus at Travelopia. There is still a lot that we can potentially do with KPI trees. And hopefully we will at Travelopia as well, but just to give you a short summary of what else is possible. So some of this we've already seen, right? So the tree itself is this part about, but when you overlay the initiatives, the work, the projects that you approved or products that are going on, that then it becomes an articulation of your product strategy or your business strategy, right? So for example, here it says because you're working on these initiatives, these initiatives are going to impact these metrics and these metrics will hopefully impact these higher level metrics will then impact these ultimate outcomes. In a way, it becomes an articulation of your business strategy or product strategy because what you're saying is that I don't have anything currently going on to improve this metric over here, but I have some things going on which are going to improve these metrics. In other words, like my strategy for this year is to focus on these metrics and how by executing these initiatives. So in a way, it becomes an articulation of your, so that is one type of overlay. You can do other type of overlays. For example, if you want to, you already have a plan or a roadmap and you might have like quarterly plans, right? But you could overlay that plan saying, okay, this is what I plan to do in the first quarter, second quarter and third quarter and what is the benefit that the business can expect through those initiatives is like, you know, they can again follow through the tree and understand that. So it's overlaying your map or a plan on the KPI tree to make it more useful. That's another type of overlay. If you're using OKRs, for example, then you might already have some kind of visual representation of your OKRs, but you could also map them to this tree here, right? Because they are different things. The KPI trees are something more basic. The KPI tree itself does not say what you are going to do, what your goals are, what your targets are, no. The KPI tree is just saying, what are the forces in your business? You know, what are the lower level metrics, how do they influence the higher level metrics and so on, right? It's telling the long-term story of your business. But with the help of overlays, you can make it more interesting. So here, what we have done is we have overlaid these objectives and key results onto the tree here. So then people can understand, oh, this is my key result. But how does it really matter? Because I'm supposed to do this, and thereby achieve this key result. But that is then going to hopefully make a difference here and which will hopefully then make a difference at this level, right? Because there is an objective is at this level, key result is at this level. So that is another use case. There are some advanced use cases where I have in the past helped clients who had challenges with prioritization. There are multiple stakeholders and there are difficult decisions to be made about prioritization. I have helped them use a KPI tree to move away from prioritizing the actual work, instead focus on the outcomes. And so use the tree to prioritize outcomes. Like, through this quarter's efforts, we want to move this metric and this metric in the tree. And then once you prioritize outcomes, then after that prioritizing the work becomes much easier because you're just mapped, you already mapped the work to the tree saying, you know, this initiative is going to impact this metric and so on. So I call that as prioritize outcomes, not work. And that is a bit of an advanced use case, but it is also possible. Talking about the relative importance. So Sri already showed one example with a sales funnel where basically once you visualize that, you know, a particular initiative is going to help in the middle of the funnel and another initiative is going to help in the top of the funnel, right? So which one do you do first, right? And if you know that the situation is that you have a bottleneck in the middle of the funnel, right? If you know that there is a bottleneck in the middle of the funnel and the tree helps visualize that, then no brainer that you have to focus on the bottleneck first. There is no point in prioritizing an initiative which is going to generate more leads because that is the top of the funnel and you have a bottleneck in the middle, right? So that is one use case. Similarly, you can overlay a customer journey on the relevant subsets of the KPI tree to understand to making decisions about initiatives, those kind of overlays can help. And finally, the part about, you know, this understanding the contribution of your initiative, like you did something like you developed a chatbot, did it really help save call volume? How much, right? That is a whole other topic called business retrospectives, which is a method that I've evolved over a period of time with clients. And that really helps to improve the business impact of investments and initiatives. A quick overview of that, I'm just checking, I guess I have another five minutes, so I should be fine. Is that, you know, basically think of business retrospective, any retrospective, if you talk about a Scrum retrospective, for example, right? What is it really about? It's about continuous improvement, right? We do retrospectives in order to continuously improve. However, the typical Scrum retrospective is just an execution-only retrospective, like sprint after sprint or whatever, you're doing a retrospect on, you know, just the execution part of the thing, right? Whereas, for example, people who've read the Lean startup book, who are familiar with build, measure, learn, kind of loop and so on, that is a slightly, you know, outer feedback loop, where you're measuring the outcome. And here's the, we're not talking about the ultimate outcome, we're talking about this product analytics, service analytics, but still that is better, where you're measuring your product analytics. And based on that, that is informing the next round of execution, which is, this is essentially what the build, measure, learn loop was, right? But really, if you want to talk about like, did I did, I had immediate outcomes, that's fine, but did it really result in impact, right? So the difference between a lot of chatbot sessions as the outcome versus actually a savings in call volumes, right? If you want to bring that loop into place, then that's where the framework or the method called business retrospectives will help because they help you complete these outer loops, because now we begin to say, okay, we have this chatbot, but can we demonstrate that because of the chatbot, call volume went down by 2%, right? Similarly, increase example, right? We did this self-service, we've reduced the after sales overhead for the sales guys, but can we demonstrate that as a result, they were able to attend to more sales calls and sales actually went up as a result, that those kind of retrospectives would be this outer loop, right? But you need a lot of measurement infrastructure in place to be able to put these outer loops into place. And a lot of organizations, they don't have the measurement infrastructure in place. And I call that measurement debt, similar to technical debt or tech debt, right? You know that if you have tech debt, your delivery slows down, your cost of change increases, there are more bugs and so on, right? Similarly, if you have measurement debt, then you can't assess the impact of what you're doing. And so as part of the business retrospectives method, I have a module that actually puts a measurement improvement program in place. So the COO or the CFO has to fund a measurement improvement program so that you can get rid of measurement debt and then you can actually activate these loops, right? But that's a much larger topic. What we've seen so far mainly with KPI trees, even in the Travelopia case is the first module of business retrospectives, which is alignment module. And as we shared already, that is having a lot of benefit. But you can go all the way. There are many more modules and out of the six modules, four modules make good use of the KPI tree. The other modules don't necessarily require the KPI tree. But this is a separate topic. If you're interested in it, if you're in a position where you believe you want to improve the business impact of investments in technology, then do get in touch and I'll be happy to share more about this with you. So that's all we had to share. Happy to answer any questions or if you have any comments, happy to hear them. Thanks, Sree.