Everyone. How's it going? Good. Oh, yes. It's not. Well, that's fine. And it gives it another few minutes for people to to trickle in, before we kick off. But thank you all for joining. I'm excited for today's the today's session. Can we give one? Yeah. I'll just wait until there's kind of a pause in the, request to join, and then we'll kick off. It's kind of like when you're making popcorn and you wait for the the pops to stop for, like, ten seconds, and then you can it's safe. Yeah. All the things settle down a bit. Yeah. Okay. I think we'll kick things off now. I'm sure a few more people join, but that's alright. Thank you all for for joining. Like I said, my name is Taylor Brownlow. I'm head of data at Kount. Kount is, a whiteboard for data. So if you can imagine in kind of a a SQL IDE, BI tool, and a notebook into a bureau, Kinda what we are. We're running the session. This is the first of our metric tree operational clarity master class. So thank you guys for coming out. I wanted to before we kick off with Ergas today, there's gonna be a really great chat. I wanted to give a bit of background on on the overall, master class that we're running, why we're doing it, and maybe what you guys can expect over the next few weeks. So, yeah, I guess about a year ago, we started a Slack community for heads of data. Just as a place where these heads of data could talk to each other, get advice, ask questions, just kind of, yeah, get some real advice from their peers. And a few months ago in that Slack community, we just started getting loads of questions and discussions around metrics, which I'm sure you guys have all seen a lot of posts about it yourselves and have a lot of questions. And, basically, the idea for this master class came out of a lot of the discussions that we were having in that group. And there are a lot of questions spanning the gamut from kind of what is the metric tree, what's the theory behind it, which I'm gonna be covering today, to really practical things like how do I start this project, how do I get approval, How do I build one? What tools do I use? What's available? As well as kind of, you know, moving ahead, this is kind of open doors for how my data team should operate. So, yeah, it's based on that those questions that we created this MasterClass session. It's four sessions. You guys are all first one. We have one on on Thursday, which is gonna be building a metric tree live. We have one next week with some data leaders from, Bumble, Mubi, and Clio, and they've all built metric trees, and they're gonna come tell their stories to pull out really practical things that they kinda wish they had known earlier. So that's gonna be a really great session. And then next Thursday, we'll be meeting Ali Hughes will be going through a lot of the research that he's done into how this idea of operational clarity can really unlock a different way of working for your data too. So all that being said, you will get all the recordings for these after each session. We'll send out the calendar invites after each session, so you'll get the one for Thursday after today. And I'm also gonna try to prepare some notes after each session as well so you have kind of a a summarized version of of everything that we're building up throughout these four sessions. So hopefully, we have a pretty good kind of summary list at the end of this. Okay. I think that's all the the admin stuff I had written down to cover off. So we can get into today's session. So today, we are talking with Auguste Pilate, as a vlogger, hopefully, you guys all know, an author, and a consultant, like, during the day. And, yeah, we're gonna be talking a little bit about the theory behind metric trees. So first of all, August, thanks for joining. How are you doing? Thank you for having me, Taylor. Doing quite well. I'm excited about this session given that, metric trees has been bit of an obsession of mine over the past couple of years since I got introduced to them. So very happy to share what I've learned, so far, especially some of the some of the connections to other concepts that I've made and sort of the the roots of, where my trees came from, kind of explain a little bit of that and some of the differences with a few other tools that people have encountered. And, yeah, pretty stoked. Yeah. Me too. I think one of the things before we start, that you you said really well last time we spoke, There's just this this fear of kind of metric trees becoming, like, memeified kind of because they're so big right now, they kind of could use their potency. And so I think this session in particular feels really important to avoid that because as we kind of break down what is and isn't a metric tree, what are the kind of foundational principles behind it, I think it helps it stand on its own, not just as another hype cycle output. Yeah. Yeah. Exactly. So I can I can go in into a in in into some details about kind of what I mean about that? So there's there's been a lot of concepts in the data space. I'm sure a lot of the people here are familiar with, you know, data mesh or, you know, this thing or that thing. And a lot of these concepts tend to sort of the pace of the spread of the of the concept itself sort of outstrips the benefits or or, like, the the the science or or the theory behind what brought it to fruition in the first place. And so I'm specifically worried I'm I'm I'm particularly worried about this in in with metric trees because it I don't want it to become, oh, here's this, like, thing that this tool, this whole that has a cult following. Right? Like, this this thing that it's like a a thing, and it's it's really not a thing. It just, it's it's basically, it's a graphical representation of the business model. And the way that I think about it is if you're if you if you know the term fractal, so a fractal is something that repeats in in multiple levels, both at the micro level and at the macro level. So I think of metric fees like a fractal, which is they can apply to one small department with with a few people. You can build a a metrics tree just that has, like, two or three levels that only applies to your team where you have, you know, your goal metric at the top, and then you have the other metrics that are associate associated with it. Or you can take it and apply it from that one department or group to the department to eventually to the division and all the way up to the company. And you can sort of keep going. It's the idea is that it it's practical. It it repeats at at multiple levels. But the thing that I wanted to sort of specify or or the what what I wanted to to make super clear is that it's it's it's a graphical representation of the business. And so I personally don't care for labels. Right? If you if you're kind of saying, oh, what is this a KPI tree? Is this a metrics tree? Is this a that tree or that tree? To me, it doesn't matter. To me, it it's all about, can you map your business or the thing that you care about, that the area that you that you have influence over? Can you map that into a graphical representation with some metrics that kind of give you a signal of, is it doing well or is it not doing well. Right? That's kind of, like, one of the one of the uses of the metric. And and I'm sure we'll get into into the specifics later on, but I just wanna, like, that that kind of circle this back. It's not that it's like a new thing. It's metric tree needs. You know? It's it's basically, it's a graph. A tree is just a graph. It it it explains how two or three metrics are connected with each other. It could be connected through a mathematical formula, like, conversion rate times average order value, gives you revenue. Right? Or it could be some sort of a causal relationship. This metric causes that metric, or it could be a correlational. You know? When this metric increases, it tends to cause this other metric, not caused, but it it sort of, marches in step with this other with this other metric and so on and so forth. So it's like there's no set of rules or regulations or laws behind this thing. It's like you just map your business in a graphical way to to the truth. So that's Yeah. I think this Brad. There's a few things that we should we should unpack, I think. Yeah. One of the one of the first questions I was gonna ask you was around this definition of a of a metric tree, I think, which you've touched on quite a bit there. I think one of the first questions that we got asked in from this community is like, oh, well, what's the difference between a KPI tree and a metric tree? And I think, yeah, it's very tempting to get kind of caught up in the the differences between them. I think it's nice to reorient, as you say, to to say I'm like, okay. The objective is to, can you map out how your business works? Yeah. Call them something to be like. If you want to call it a KPI tree, if that helps you sell it to your to your boss, by all means, call it a KPI tree. If they think in terms of KPIs, you think in terms of metrics, it's sort of the same thing. You know, key performance indicator, has the, like, the additional aspect of it being key as opposed to a metric. It's just a way to measure a specific thing. But, yeah, I don't like to put spit like, boundaries around what a metric tree is versus what a KPI tree is and what are the, you know, the benefits and drawbacks of one versus the other. Yeah. I I suppose one distinction, I think. I'd be curious what what you think about this, certainly in my mind anyway. A KPI tree, at least when I've seen them, tend to just be more, like, text based or definitions rather than numerical values attached to them. And I think one of the main kind of the value points that we'll bring to, I think you also use the word diagnostic as well. Like, can you use this to diagnose issues? And so if you're trying to use a tree in a diagnostic sense, then that also feels like, okay. Well, there there probably need to be some some numbers in there for that to take place that yeah. I don't know if you've seen that Okay. That as well. Yeah. I see I see what you're getting in there. So yeah. So there are also, let's say, I guess, multiple levels of of of the metrics tree because there is one version of it is, let's say, a graphical pure graphical thing, Figma graph or a mural graph or something that you draw by hand with with boxes and arrows that says, you know, here's revenue at the top, and it has these components. And this component will attain you. UAR has, you know, number of lead times the conversion rate and number of leads. It's like, whatever you feed into the marketing times that conversion rate and so on and so forth. So when you build something like that, there's more like a show and tell type thing. It's not dynamic. There's no there's no data behind it. There's no refreshability. Right? There's no it it it's not a tool that you are using to diagnose or run the business. But what would I what I call that a KPI tree versus the the real thing, a a metric tree? Like Yeah. Yeah. Call it Maybe not getting into the semantics. Yeah. Yeah. It's I think it's I think it's semantics. And I also think that you should, by all means, start with a graphical thing, a simple boxes and arrows thing where you can actually put you know, here's the conversion. Right? You can put text in there, and you can say, here's what I want to build. And by the way, like, you can walk into the CFO's office or the CEO's office with something like that and say, hey. Have I have I captured everything here? I often and we can get into this later. I often recommend people go to the CFO, grab the p and l, the profit and loss, and, like, try to turn that into a metrics tree. It's sort of like the easiest way to get started. And then if you want to, like, implement the tree, that then it's a much bigger undertaking because first you have to, you know, model the data that comes in. You have to build the metrics themselves, then you have to, like, connect them with with each other to sort of build. And there are almost no tools that that that I've seen that sort of help you build other than the count is a very good, example of this because you can, you know, calculate one thing here and then connect it to this other thing. And then so this is one way to to to make it, like, real or live or refreshable, like, if you wanna think about it in in in those terms. So I personally I sort of, like, overload the definition of the concept where I I I say it's a metric tree. If I see graphical thing that somebody puts on a board with, marker or if it's a Figma thing or mirror thing or if it's, like, the thing that actually refreshes, like, something that you build in a BI tool. Right? Yep. Your your BI tool tool tool of choice. So, yeah, that's that's how I think about that. Yeah. I like that. And just just real quick, I saw Natasha has a question. I think we'll come back to it when we get, closer to this topic, if that's okay. But I did wanna call out, that there is a q and a section if you guys have questions. It's kind of hidden in Google Meet. So if you go into activities and then q and a, you can find it there. So if you do have questions, please drop them in there, and I'm keeping an eye on them as we go. Don't be afraid to do that. Okay. I think that's great. I think that's I think we're circling around a a good Yeah. Definition of metro trees and happy with this. And I think based on that, we've also touched a bit on how we see them used, but I think maybe it might be worth kind of painting this picture because this is another point that I get a lot get a few questions of, like, oh, is this you know, do I no longer have to build dashboards because this metric tree is now gonna be the answer? Is this now you know, we don't need analysts because this is now gonna replace all the diagnostics that the data team is doing? Or, you know, how how should someone be thinking about it in terms of how it sits with the yeah. Yeah. How does the data team be thinking about it? So one thing that I that I you talked about earlier, was sort of, like, the history behind the tree. And I wanna just briefly briefly talk about that, and then we we can go into what it is and what it looked like. So when I met with Abby, who is sort of, like, the, at least in my mind, he's the originator of the metric trees. He mentioned that he got the idea from something called the DuPont analysis, DuPont tree, or however you wanna call it. So DuPont back in the, I think, fifties or sixties. They wanted formula that there was one engineer who came up with the formula to calculate the return on equity, ROE. And the way that they represent it is so it's like this, like, multiple equations, multiple ratios that are multiplied with each other. And they represented it as a graph with ROE at at the very top and then its components, you know, going all the way down to the to the elements. So Avi took that idea and said, how? I can probably put this around metrics. Right? So I I can take the key metric, let's say, new ARR or just ARR or or MRR, the business for a SaaS company, and connect it all the way down to the levels that I can potentially control, like the leaf nodes as opposed to these, intermediary nodes. And so the moment that I saw that, I was immediately captured. I was like, oh, I could've when I was an analyst, I could've if I had known this, I would've probably succeeded and remained the analyst instead of becoming a data engineer because I I hated being an analyst, having to answer all those questions. And so then I found connections to other other trees, other types of trees, because trees are very popular for decomposing, a problem. And I would briefly mention one. So from theory of constraints, which, you may be familiar with the book, The Goal by Ellie Goldrass, he created these thinking processes, which are these logical trees that break down problem into into components, and, eventually, you try to find the root cause. One of these trees because there are several that have, like, the current reality tree, which is also known as the problem tree and that, etcetera. So one of these where I immediately saw the connector with with the metrics tree is known as the gold tree. So the gold tree has not that many levels. So the top level is your goal, what you wanna achieve. Then the next level are your critical success. So these are the factors that you need to achieve the goal. And if you think about the metric tree, the goal in your top metric, and then the critical success factors are the the elements that make up that goal. You know? ARR, you have new you know, you have, resurrected ARR, you have, you know, churn, etcetera, etcetera. And then underneath these critical success factors, you have these, multiple levels of necessary conditions that need to be in place in order for the critical success factor to become true in order for you to reach the goal. So I was like, oh, wow. This is this is basically a gold tree, but with metrics. So that's another kind of another link to say the past and sort of some, you know, some kind of theory behind this. Then another one, and this is the last one that I'll mention, is something that I saw done by a consultant where it he called it the profit tree. So if you search for profit tree, you'll find this this article. And it it it's about this website is about learning how to create this k this business cases, right, for for consultants. But it's exactly the same thing. You take profit. You decompose it into costs and and income, and then you decompose each into until you reach the very the very end. And at one of the elements of the profit tree or these trees in general is something known as MECE or MECE. Mhmm. I think stands for, like, mutually exclusive, collectively exhausting. So the idea is that each element is exclusive by itself, and then collectively, they exhaust everything. So just wanted to kind of paint the a fuller picture Mhmm. Around the trees. Then to come back to your question about whether, you know, do they replace dashboards or, do they replace the data team, etcetera? I don't think so. I think dashboard the only problem I have with dashboards is that there's just too many of them the companies build. It's too easy to build, so everybody wants a dashboard when in reality, what they need is just, an an export of some data into Excel that they can use for something. In fact in fact, there's another concept known as the dashboard tree where it's sort of like this gold tree, but the the dashboard tree contains metric trees inside. Mhmm. Yeah. The idea is you only have maybe ten or fifteen, not more than twenty dashboards for the whole company. Each dashboard represents the l l each dashboard represents a tree, and then it's highly curated so that when when a leader is looking at it, they can sort of say, oh, okay. So the problem, let's say, to do diagnostics, it it appears to be this particular branch. And then someone in the data team can go and look at the metrics tree and decompose it further and figure out where the problem occurred. Because in in in in my experience, the lead leadership doesn't care about the details of the metrics tree, so somebody has to care. And that's where the data team comes in. And and and in in obvious experience, the metrics tree and then the dashboard tree sort of become, like, the the source of truth. Right? So you and you as a data team, it your goals to ensure the accuracy of of this. And so I think this answers one of the questions that I saw, Pablo, which is, like, who owned the metrics tree? One hundred percent with the data team. And I I sort of I'm I'm I'm fond of saying that, like, data teams need to collaborate with finance. Because finance is thinking about this type of stuff, but they just don't have the full picture of the business. They they might have some very, you know, high level numbers of revenue and and income, and here's that. But oftentimes, finance people and and FPNA people, finance planning and analysis, They've just they just don't have the act the access that a data team has to the, like, all the data in in the business. And so, like, if you collaborate with them, you you make yourself a very powerful ally in in the business. So who should own them? Yeah. It's gotta be the the data team. Do they remove the need for dashboards? No. They don't, but they do reduce the the dashboard problem. And if if once you add so there's another piece to this, which is the the weekly review or the the core the monthly review of of this metric. When you add that piece to it where everybody is looking into the in on the on the dashboard tree and and the metrics trees, and they're looking at the same exact aspect of reality, then you like, everybody then sort of gets synchronized around the same thing, and there's no need for additional questions. There's no need for additional dashboards. It's sort of like it reduces a lot of these questions. Right? Yep. And we can get into the specifics of, like, why are there so so many questions? Because I I mean, I've I've done a lot of, like, thinking around that since I was the one getting all those questions. Yep. But, I'll I'll I'll pause there and and Yeah. I had I had, a few thoughts in you going through that. I think, yeah, there's I kind of picked up on a few more patterns as you were going through some of the other tree examples Mhmm. That I think would might be good to come across and summarize in terms of, you know, deciding what a tree is and what it isn't a metric tree specifically, I think. Yeah. Seems like all these trees obviously have this concept of hierarchy information kind of laid out in this facial structure. I think there's also a a diagnostic component to it, and, therefore, I think there's also a kind of action oriented kind of component to it. So, like, you know, you should be able to to do something with it. And I think to Nitesh, a part of the question, at least that and we're gonna cover in some of the the later sessions in this master class of kind of how to choose metrics and how to have that process because that can be really messy. But I think a good rule of thumb is, like, it should be something that's actionable. Like, you can't have a Right. The node in this tree that's it's kind of abstract and, like, are the concept? Yeah. I mean, you can measure pretty much anything with with data these days. And a lot of the question that becomes what should you measure. Right? And Abhi and I, mostly Abhi, created this Soma metrics, which is like an open source collection of metrics specifically for SaaS business, but a lot of them apply to other businesses as well. And these because the the idea that I had that he and I connected on was, hey. A lot of this data stuff is could be standardized. Like, a lot of this data stuff is done ad hoc where somebody wants to measure something, and then they put the request onto the data team. And and the the data team is basically, like, an order taker, like a like an IT help desk. I I sometimes like like to call it, like, the data help desk because it's it's unfortunate, but that's that's how it has been cast, I guess, in a lot of organizations. But the data team can take a more proactive role here where they can say, hey. Here's here's the metrics that we should use. Like, you can go to, like, the GitHub Soma page and get all the metrics and say, here's the ones that I think we should be measuring in in our business. And then you build the tree, and then you sort of basically become more proactive, and you help to answer a lot of the questions. Did I did I capture did did I answer your question, or was was that going your whole a little different direction? No. No. It's good. Yeah. I think yeah. We've covered off, I think, where some of the origin points of of data trees that or meta trees. I think we've covered kind of how people can expect to use them in the context of of the rest of, like, dashboards and how it relates to the the data team. So you know, but that reminds me because you've mentioned this a couple of times, and I don't think I have addressed it. So the purpose of the metrics tree or one of the purposes of the metrics tree, which they're perfect for, is what I like to call debugging the business. You call it diagnosing the business. Obviously, sometimes call it diagnosing the patient. Right? Because you're like, here's a business that's not growing as fast as the owners or the CEO, whomever wants it to grow, or the business is potentially, you know, shrinking as opposed to growing. And you want to diagnose why. You want to figure out what's going on. And a lot of the times, you just have these high grain metrics such as revenue or, you know, how much money you spend on on marketing. And a tree decomposes a lot of these things into elements that you can not only measure, but you can also look at and see how they trend over time. So you could say, oh, hey. By the way, this marketing campaign that we were spending x number of dollars per month, it has started dipping in performance, and it's sort of taking with it a lot of our a lot of the rest of of the metric. You know? Because this thing is down twenty percent. Revenue is down twenty percent or more. And so now you know, but why do you know? Because you have this whole path built out in in the tree. You have the dependencies of all the different elements. Right? And so diagnosing the business is or debugging the business is sort of the primary use case. But things don't stop there because now you also wanna figure out how do I grow the business. And you might wanna say, for example, when I was spoke speaking to a CFO, a few couple of years back, they were asking me, hey. I have a hundred thousand dollars to invest in marketing this year. Where do I put it? I want to grow my subscriber base to, let's say, a hundred thousand people or fifty thousand people. Right now, I'm at twenty thousand, and I and my budget is a hundred thousand. Solve the problem. How would how would you solve something like that? Right? And a lot of the times, it's the finance people that are asking this question. Right? They they they wanna know, I wanna grow this business side. Or let's say you raised around. You raised five million. Right? Now you wanna know how do you deploy it? How do you best deploy this money to fuel growth? Maybe the CEO is open minded and is asking this question as opposed to saying let's hire more headcount in sales or let's hire more headcount in in in marketing. You as a data person can say, hey. Our our sales numbers are actually doing really, really well, and our capacity over there is being underutilized. So I don't think we should invest in sales. We should invest in marketing, particularly this marketing channel because we've run a few experiments. We've seen very good response. We just need more fuel to to to that fire. Right? I think we think that, like, there's a fire there. There's there's a potential growth opportunity. So we've run some like, okay. Let's if we don't know, we run some experiment. But if we do know, now is the time to fuel that that growth. And you can also sort of fuel that growth in stages, and you can sort of see, okay. Is it is it working? Is it working? Is it because a lot of these things, all, I think it's a logarithmic curve. So you kinda, like, grow to a point, then you hit plateau. Yep. You hit the plateau. It's not just it's not like a linear or exponential, which is, like, the opposite, but it's more like you grow, you grow, you grow, and then you kind of, like, hit some some saturation point. And at that point, you might wanna, like, switch tactics. So you can't just take all the money and dump it in one place and expect it to kinda give you this, like, linear linear growth. So that's the these are sort of the the two use cases. You have the the diagnosing element, but then you also have this, like, growth side, which is find me the levers. Yeah. Run a simulation, and and there was an article that I read from from Duolingo where they ran simulations to figure out how to increase their DAU, the daily active users. And they didn't have past data, so they ran some simulations, and they they they kind of, you know, use data science, etcetera, to kind of figure out, okay. This is exactly what we need to do. And then they just said, okay. Yeah. This is this is what we should do, and they did it, and it actually gave them the so so that's the that's sort of the other use case, which is very rarely talked about, which is the, you know, can I use the tree to find levers to influence these key, let's say, leaf notch? Right? Yeah. Or which one of which ones of these nodes should I be targeting that would give me the most, say, bang for for for my for my dollar? So that's sort of that's the the other aspect of it. Yeah. I completely agree. That's really well said. Those two, yeah, from a diagnostic perspective and then from a growth perspective. And I'm curious. There's one other one data leader I spoke to who kind of speaks to this objective of a data team as a as a connecting force. Like, it connects the understanding of the business, to everyone to make sure everybody has the same understanding of what the business is, how it's working, and also their contribution to it. I felt like that was such an understated or, like, you know, something we forget that a data team has is in such a position to do. And I feel like when I first came upon upon Metrcrees, it had a similar thought to you, I think, which is like, oh, if I had a had this as an analyst, it would be great. But, also, if I had this just in my previous job, I might have known what I was supposed to be doing. Like, I might have been able to connect this vague general objective that was three levels above me to what I'm doing today. And I think that's such a Absolutely. Kind of a it's abstract, I guess, but it feels kind of really important to get that right. No. You make a very good point because when I was a business analyst, I was sort of the nexus of a lot of departments. Like, I was talking to sales. I was talking to marketing. I was talking to operations to finance, And they were all asking for different, let's say, slices or cuts of the of of the data based on their own department or the thing that they're mostly paying paying attention to. And their thinking is very siloed because they're just focused on they got blinders on. They're like, I need to improve my ROI. Let's say I'm a CMO or VP of marketing. I gotta improve my ROI. I gotta improve my CAC, my my my my customer acquisition cost, etcetera, etcetera. But they are just focused on that one thing that you, as a data person, you get to see that this CAC connects all the way to revenue like this. So you could basically tell the the marketing department to say, hey. If you only reduce if you can, reduce CAC by x percent, you can increase your revenue by y percent. You can give them that equation, if you will. Yep. So I that is critical sort of a a skill or something that I don't think a lot of data teams get to see because a lot of companies now follow the dispersed model of of data where they put analysts in all the different departments and everybody becomes, like, narrow focused on their particular area of expertise. But I think there is value to integrating the the different views. And then another thing that that I that I wanna point out, which is another one of Abhi's things, is that when it comes to these dashboards that that you create these the the dashboard tree and the metrics tree, you don't want to provide a dynamic view. A lot of the a lot of the stuff that you you've been taught as a as a data analyst or whatever is, like, provide as many places, buttons, chart, etcetera, as possible so people can look at things from multiple perspectives. You don't want that because then everybody's is looking at the different slice of reality. And you're saying, you know, we're we're growing on this segment by y percent, and then somebody's saying we're shrinking in this other segment by y percent, by x percent. And so people then are just, like, at at odds with each other as opposed to you curating the view to to, like, for for everybody. So Abi prefers these, static static views. So he's like, the data team should curate the most important segments and slices and, like, by channel, for example, or by region and only provide those. But, like, the data team takes even a more crucial, more important role as the, like, the the curator of of this of this stuff. Like, you you're not just a service provider, but you actually provide a critical role to the company to sort of weed out the noise and point everybody towards the signal. At least that's what I want to get data beams to do with with a lot of my writing, a lot of my thinking about, metric trees. Yeah. I think that's a really good point. I think it's helpful to to think about it as you know, if you do want this to be a good diagnostic tool and to be used by so many different parts of the business, it does have to be consistent. It has to be trusted. And then you find a different way to help people, you know, well, why did that go down? Okay. Well, then let's separately go explore that and figure that out. But this isn't the place where doing that kind of interrogation and filtering that's is this is this is the single source of truth, so this is gonna stay as it is. I didn't say that. Yeah. That's a very good point. Cool. I wanted to make sure we had some time for questions. So I'm gonna ask you one more question. Okay. Even while I do that, if anybody else has some questions they wanna add to the q and a, now is a good time. And, yeah, the one thing I was gonna ask is, what is one thing about metrics that you wish you had known sooner? The fact that they exist? Yeah. Yeah. To to be honest, once I once I saw the, like, the tree concept itself, right, the company that I was working for when I was a business analyst, they they didn't make, like, revenue numbers available, but they did have an well, like, a North Star metric, which was, you know, number of bookings, let's say. And I'd I would just like, people would I I would go to into the president's office, and I would present because they would do the quarterly update, and they were trying to, like, put together all all all these different charts and they're trying to create a narrative. Right? Like, you're you you have all of these different elements, you know, marketing and sales and this and that and the other. And the the tree itself, the idea of this, like, graphical representation of the business with the hierarchy and the dependencies and the different levels and the and and the and the different steps that would have saved me a lot of turmoil in, like, answering this question. Because, hey. If I had the if I had the tree that mapped, you know, all the way from bookings down to marketing efforts, down to sales efforts, down to operations efforts. I could then even come up with levers because they were always looking to grow, but they couldn't figure out, you know and a lot of the experiments were done randomly. At Yeah. Sometimes they would run one experiment and then just change it halfway through before you had collected enough enough data. I know a lot of people get frustrated with that one. So I just wish that that that I knew that that I could do this. Right? I just wish that I knew that this sort of thing was possible, that I could then influence the business. I find myself that I like the business side quite a bit. I I've always stood between when it comes to the the business and, let's say, the tech side. I've never been hardcore techie, and I've never been, like, a hardcore business person. Always sat in in the middle. And I think, being a business analyst with a pool like a metrics tree would have given me so much more standing, probably, you know, more promotions, more influence within the org. So, yeah, I just I wish I had known about them sooner. Yep. And and and then the, like, the the diagnostic part is, I think, was is the second point of that. So I have spent hours, if not days and days of time to figure out why this one thing went down in the past, you know, x period. Mhmm. Marketing would come in and say, hey. We've spent this much money here. This thing is down as of compared to some other period by x percent. Why? What happened? And having to do that analysis over and over again from scratch, very frustrating. You know? Yeah. I I would save my SQL queries for the next time, but then you would go in, you're like, what did I run first? And every time it was something else. If I'd had the the tree, you'd be like, oh, boom. Boom. Boom. Okay. It's down down to this branch. It's it's over here. And I could diagnose these problems or they're basically, the moment that something started to go amiss, I would be able to alert the team, be more proactive, and be more valued in in the in in in the company. So, yeah, take against that. That's good. Yeah. I think it's also a good way to to sense check some of those questions that you get if, like, oh, they're asking about this thing that is, you know, clearly in this tree of information. Is such an irrelevant point to what what the objective is. It's been like, oh, actually, do you wanna be asking about this? Like, maybe this is Right. What we're saying. Yeah. I think it's good to have to check there as well. Okay. Great. We've got some we've got some questions. You ready to dive in? Okay. I'm gonna I'm gonna read them off. Natasha, started us off. I'm very curious to understand how you'd recommend breaking down and building a metric tree given all metrics are not equal. I remember reading about Meesee, which you already mentioned, but I'd love to know if you have a recommended framework for doing this. I don't have a framework. I have I have sort of a methodology. I the I don't know if that's like this the same thing, but it's more like a rough guide. And the rough guide is start at the top. Start at the top, which is the the goal. And a lot of the times, let's say for SaaS companies, that goal is recurring revenue. Sometimes it's like new bookings, but let's say recurring revenue. It's a lot easier to work your way downwards because you can at at any one level, you can keep going until you reach the very end where you say, okay. Here's, like, money that I put into this one campaign and outcome leads. I can't go any further. So this is my leaf node, but then I have everything built up. So work backwards from from the goal is is my recommendation. Now there could be, like, a massive sort of effort. So the dashboard tree has much more, like, fixed elements, and people can can Google that. And I think you can go to Abby's, article. So at the top, you might have, like, these metrics, but then down on one side, you might have just sales. And then let's say that, you can build a metrics tree just about sales. And let's say that the key, metric at at the top of sales is sales qualified leads or or something like that. It could be revenue if if it's if it's a CRO, but, like, everybody kinda cares about, let's say, sales qualified lead. You can work start start there and work your way down to, you know, marketing spend and, like, agent or account executive numbers, etcetera. So, like, you you can eat a lot of that stuff in in into the, but you can never work, like, from the bottom to the top. You always have to work downwards from and like I said, you can take any any one goal that you that care about. Marketing could maybe just care about MQLs. And MQLs fits into another tree, but let's say only they only care about MQL. So they could build just that tree that says, hey. I I'm gonna influence MQL. And you as a data team might know that, you know, if you influence MQLs by this much, you influence revenue by this much. And in marketing marketing, let's say that they they know that, and then they just say, okay. I'm gonna focus on on just that one. So we're going back. I think, Nitesh, one thing I'd add is on next Tuesday, the session that we have planned with the guys from Bumble, Clio, and Mubi. So they have they've each done this in a slightly different way, and some of them do it, like, Ergus said, like, by department. And then some do it from starting from the very top and working their way down, and each of them has kind of a different way that they've done that. So I recommend we'll definitely cover that on Tuesday. You can. Excuse me. And I would just say it's always very iterative as well. Yes. Sorry. Good. It's cough attack. Next question is from Angelita. She asked who should own the metric tree asset and how to keep it up to date in a noncentralized environment. I think you've covered this a bit. Did you have anything else you wanna add? Yeah. So a lot of this stuff becomes murky because tools for this don't exist at the moment, but the assets don't I I mean so the data team is already in charge of, let's say, the the DBT models or some kind of, like like, the data models and the data and the platform. They're in charge of many of them are in charge of ETLs. That could be data engineering team separate. And then they're in charge of the dashboards. So I think it should be I mean, it's different for for every company. Right? But in my opinion, and I think Adi's opinion, it's like the data team should own this one hundred percent and sort of be responsible for it. In if you have read Amazon's this this book, Working Backward, that has a chapter on analytics, Amazon does something they call the weekly business review or the WBR, and has read quite a bit about that. If they believe they sort of they put finance as the team in charge of the metric as someone who has, like, no like like Switzerland. Right? They have no bias. They have no they they didn't go one way or another way. So they are in charge of, metric definitions and things like that. So, I mean, it's it's different for every company. You can, see what other people have done. I think the upcoming, like, call that you have or the upcoming workshop that you have, I think, would be very useful because people wanna see examples and then Yep. From those examples to their own, things. So it's like yeah. I mean, those are guidelines. They're not rules or laws of of any cut. Yeah. I think that's a good point. I think, yeah, seeing a few examples of how other people have done it and, yeah, some people kind of go the finance route. There'll be examples of that next week and some other flavors as well. So, yeah, also good ones coming next week. Mhmm. Okay. Oh, he's got quite a few questions. I hope you've got time. So the next one is from anonymous. Do you have any recommendations on how best to get buy in from business stakeholders? I'll also preface this question, and this is a big thing that we're gonna cover on Tuesday. But if you've got anything to add, Erickus. Yeah. This is the question. Right? Because I have seen that without some kind of leadership buy in, this is impossible to to sort of do in the grassroots way. I would say if if I could just summarize it in in one, at least rule of thumb is, like, find yourself an ally, someone who's interested in this sort of stuff. Ideally, someone in the c suite, like somebody in the executive board or someone who has some measure of influence slash, you know, just talk about these soft things like power, etcetera, in an in an org. But finding yourself someone like that who will support your effort and sort of take your please onto the executive board is like, if you can get them bought in, then they can sort of get everybody else bought in. But other than that, you have to pitch. You have to pitch the benefits of something like this, who the executive board. And you yeah. It's like it's it's one of those things that is like, yeah. You have to get buy in somehow and and buy in is like, hey. By the way, if I do this, right, if we do it this way, then we will reduce cost on our data infrastructure. We will reduce cost of, like, needing to hire more analysts because we have a lot of questions. The and we will potentially apply resources better. We're we're we're actually we can show result to, let's say, the investors. Right? If it's if it's a start up or to their their shareholders if it's a whole company. I think one thing also to add to is to keep in mind when you're doing this process is, like, thinking about it. And, a couple of business leaders I've spoken to talk about this kind of mental gymnastics that you have to go through to just maintain in your head that mental model of what's happening. And I think that's really draining and exhausting, and they never feel like they're doing a very good job. So I think there's always this kind of need for something like this to just remove that, yeah, that gymnastics that they're having to do to keep track of everything because they're just getting pinged with numbers all over the place, and they're like Yeah. I don't know how that affects what I'm doing. So Inducing complexity, reducing wise. Yeah. Like, there is a big Mhmm. Need there that you can meet. And I think if you find a way to to meet that anxiety that's there, then they're gonna take it out of your hand as soon as possible. Yes. There's another question about sponsorship that we covered. Just go ahead and do these, make sure they're not asking repeats. Okay. Another anonymous question. In a decentralized setup where each business unit creates its own driver metric tree for their NorthStar metrics, how can we assure a standardized approach is followed across all units rather than having each unit build a tree based on their individual understanding? That comes down to, like, org politics, like finding finding someone who is willing to kind of unify all of those pieces. Oftentimes, that's finance. Right? So, like, you put finance in charge of making sure that the metric definitions are the same across the board, and you then sort of mandate that from the top. I don't think I've seen I mean, unless you can persuade the the CEO. Right? But you still have to persuade the CEO. It's like, what what I have worked with in the past is working directly with the leaders, the metric definitions and the the document of, like, here's what this thing means. Often, this could be in the tree itself, and you can sort of hover it. You can say, okay. This is the definition, and this is and click on it, and you can see the metric. But I I do need to drop, and I'm I'm getting Okay. Into a a meeting. Okay. No worries. I'll wrap up here. Thank you, Eruditus. I appreciate it. Bye. Sorry for the abrupt ending there, but I'll do my best to to answer these. And I'll also send them over to Ergus as well and include them in the notes, his responses to that. So I think I think I'll just go ahead and do that. I'll end it there. After this, I will send a recording out, as well as some notes, including all the references or just reference quite a few books and concepts and things like that. So make sure you have all those materials as well as the the answers to these questions. I'll be on for a few more minutes if you've got any questions about anything. But, otherwise, hopefully, see you guys on Thursday. We'll be doing, building a metric tree live where we'll be touching on some of these questions in terms of, you know, do metrics need to add up to a hundred percent? Do they need to be, exhaustive? All those kinds of things. How do you approach that? Yeah. Thank you everyone for coming.