How to Implement a Customer-First Strategy and Structure with Dashlane's CPO

Please welcome to the stage Donald Hasson, CPO at Dashlane. Alright, welcome everybody to this afternoon session of the SASTR Europa conference, um, where we're gonna talk about how to build a customer-first strategy and structure for your business. My name is Donald Hasson. I'm the CPO of Dashlane. And my goal over the next 30 minutes is to boil down a couple of decades of experience into actionable advice that you can apply regardless of whatever stage company you may be at. So before we dive in, a little bit about, a little bit about me. So as I mentioned, I've been doing this for a long time. I've always gravitated towards product roles because of my obsession for solving customer problems. And this is really embodied by a story that I want to quickly tell. So a while back, we brought in a new CPO at one of the companies I was at who I reported into. And I worked with him for a few months. And after a little while, we sat down and had some drinks, and he gave me some advice. He said, Donald, you're really good with customers. The sales team really loves you, and the deals that you're a part of, they always seem to go really well. Have you ever thought about going into a sales role? And I thought, not really. I like doing the product thing, so I blew it off. So about a year goes by, and we sit down again having some drinks. He says the same thing. Donald, you're great with customers. You ever thought about going to sales? So again, I was flattered, but this isn't my thing. I wanted to do product. So another year or so goes by, same thing. Hey Donald, you're great with customers. You ever thought about going to sales? About the third time, I started to ask myself, does this guy think that I would be good in sales, or does he just think that I suck as a product manager? And I like to think that it's the former. We went on to do some great things at that company, but it really embodies what I think about the role of the customer and how central the customer needs to be in all of our development processes and building out product strategy. So as I said, I've been doing product for a long time at a variety of roles, either product-like or more technical or pure product management at companies ranging from global multinationals to small startups, building products ranging from navigation systems, from military aircraft all the way to SaaS-based password managers, like where I am with Dashlane. And some of those stops along the way have been at companies that are private equity owned, which has sometimes a bad connotation, certainly in the startup realm. But one of the things that I learned from it, when you're being imposed with hitting 45% EBITDA margins while still growing at above market rate, is it forces you to get really good at working with a very limited amount of resources, exactly what startups have to do anyway. And so some of the things that we're gonna talk about today really represent some of the things that we've learned on how to really optimize the best results that we can for the business at whatever stage that we're at. So as I mentioned, I'm Chief Product Officer of Dashlane. Dashlane has about 15 years experience really serving about 20 million customers and 22,000 businesses around the world with a product that end users love and businesses can depend on. And some of the things that we're gonna talk about today represent how we think about solving these really hard problems for our customers in a way that ultimately meets their needs and serves the growth and needs of our, our business. For example, how do we build a product that end users choose to adopt because they love it so much while simultaneously improving the security of our organization? And this is a problem that is no more pronounced and critical than it is today. So we'll talk through that as we go through the presentation a bit more. Getting— building out a customer-first strategy, there are a lot of things that can get in the way of making this harder to do, but it really comes down to 4 big problem areas that culminate into being blockers to being great at being customer-first. Now, the first thing is how do we corral this massive amount of market research and customer data and insights and feedback that's coming in a way that we can actually do something about it. A lot of times what companies will do is they'll put up on their website feedback@companyname.com. You get a million emails in, you can't do anything about it, and you become known as a black hole, and then people just stop sending things into you. So that's not a good solution. The next thing is becoming this sort of feature factory where we're building things that we don't really understand exactly why we're building it. We may be checking some boxes, we may be doing on gut feel, but it's not tying back to the customer problem or trying to achieve a specific, specific outcome. So that doesn't really help us that much either. The next is a lack of research. Now, research can feel like a very heavy thing. It doesn't have to be. We're talking about validating that we're building the right thing and not sticking our head in the sand and hoping that the features that we've just built actually meet the market needs. We're doing some basic validation to make sure that we're solving for something. We're solving for as much of the market that we're trying to serve as possible. And the last is a very common challenge around shipping and forgetting. Now there's really two parts of this. The first is back to, we talked about, about the feature factory. Sometimes we don't even have real goals for what we're trying to build. So we put together this time and effort around a feature. We don't really understand what the outcomes are we're trying to achieve. That's really a non-starter. You need to have some idea of what this feature is trying to do for both your customers and your broader business. Secondly is when we ship it, we need to have some clue as to what we're looking for in terms of measurement to, to decide and, and to see if this thing has achieved the results or if we need to iterate on it. And we'll talk more about that in a bit. Now, this is critical because I wanna walk through a very quick scenario. When we're making these decisions, these are big levers that we're pulling. We're talking about potentially millions of dollars of development resources that we're deciding where to put those resources. So scenario is we have feature A, could be a product, could be a feature, doesn't matter. The feature A costs us about $1 million to build, all right? We build the feature, we get it into market, and for whatever reason, we've missed the mark and we didn't get any incremental ARR from this feature. Now the scenario, the second part of the scenario is we could have built feature B. Let's just assume for sake of discussion, it costs also $1 million to build the feature. But when we get into market, we've generated $5 million in ARR. So what happens is if we made the wrong choice and we built Feature A, it didn't just cost us $1 million, it actually cost us $5 million in opportunity cost. That's really the more important piece. So between A and B, it both cost $1 million, but B would've driven $5 million. We don't choose B, we choose A. That's a $5 million swing in terms of opportunity cost. So yes, the things that we're talking about are critical that we get right and we learn ways to de-risk the things that we're building at every step along the way. Just like most business challenges, how you become more customer-centric really comes down to a combination of people, process, and tools. Throughout the presentation, we're gonna touch on each of, each of these three areas and, and touch on some maturity models that highlight how you can apply some of the initiatives within each of these three categories. So a sort of opportunity to see where you fit in that maturity model, and we'll categorize them into these three areas. Before we get too far into it, to give the most practical advice possible and to align where you all are thinking about where you are in your business at your particular stage, we need to understand where you are. And so it may be that you are a respectable early-stage company, and because of your funding limits, you're working in a bit of a broom closet of a break room, and your caffeine supply is coming from a good old Mr. Coffee. Or maybe you've made the leap to the next stage of $5 to $10 million in ARR, and you're starting to get a bit more versatility in your coffee choices. You've made the leap out of the broom closet of a break room into a decent kitchen, and now you got a Keurig machine that's supplying your caffeine and giving you a bit more taste and flavor and advancing what you're trying to get from your coffee. Or you may have graduated to that envious position of double-digit ARR. You may be knocking on the door of that powerful milestone of $20 million. Now you've earned the right to step up your coffee game, and you can get an automated espresso machine and which requires little more than a water line and the ability to push a button to get some fantastic tasting coffee. So those are the sort of 3 stages. And we set up the presentation to align with each of those 3 things. So choose your own adventure about where you are, where you're trying to go, and you can start to map out some of the advice that we're giving that aligns to where you are in your growth journey. Good. Does everybody have in their minds at least what the coffee machine should be? Regardless of what it actually is, roll with me for sake of discussion. We'll use this throughout the presentation. A customer-centric strategy really starts with people, and there's a reason for that. A couple reasons. The first is your people are generally your most expensive asset at most SaaS companies. And so we've gotta really optimize the work they're doing and the time that they're putting into building what we're trying to build. And the second thing is that people are much more flexible than process and tools. and we don't want to go heavy-handed in a process and tooling right away. We can lean on our people to do some more experimentation, help us build out what things are gonna look like and how flexible they need to be. As we progress over time, we'll start to layer on the tooling and processes that we talked about. So before we dig into the specific structure, there's a couple of pieces of this that fundamentals that I wanna reinforce. The first is when you're building a customer-centric structure and strategy, You've gotta be bringing on people that are insatiably curious. Now, this is hard to teach. You can optimize a bit for it, but you really need to hire for that. Insatiable curiosity about your customers and their problems, curiosity about your business and the goals that you've set, curiosity about the market and the competition. Curiosity is core to what we're trying to do when we're trying to think about what we want to build and the order we wanna build it in. Curiosity, by the way, breeds empathy. Empathy is truly understanding your customers, being in their shoes, understanding the goals, what motivates them, what drives them. This not only helps us choose one of the most important problems that we wanna solve, but also how to solve it. So we have a much higher likelihood of when we put something in market, it's gonna hit the mark. And the second thing is you wanna be really careful, as we just alluded to, trying to over-framework your way out of relationships and collaboration internally. So you still wanna lean on your people being still central and core to no matter what we're doing. If you try to build so much process and tooling around things, you're gonna over-engineer something and waste time. And certainly at the stages of growth that we're talking about, things are gonna change too fast. You can't do that. Yes, we wanna optimize process and tools. We'll talk about that, but you don't wanna try to over-engineer your way out of depending on people to build good relationships. So let's talk about the, the team structure. It starts with what we call the triad of the course, made up of product manager, product designer, and either some sort of engineering manager or a tech lead, the sort of threesome of the group that we're trying to think through that's trying to think through what to build and, and how to build. The PM is responsible for determining what's a viable solution, what's gonna drive business results, what's gonna help meet the needs of the customer. The product designer is helping to make sure that this thing is usable, that we can get, the customer gets the value out of the solution that we intended them to get. And the engineering manager or the tech lead is making sure that it's feasible. Can we build this thing at all? Can we build it within the right timeframe and the cost that we would expect to make sure this is actually feasible? Solution. Now the next outer ring just outside of the triad is made up of a few roles that have, they have a couple different purposes. One is to provide input into the prioritization process. Research or data analytics help with prioritization as we talked about. And of course you have the, the development team, the team that's responsible for actually building the feature that we want to build. And then the outer circle is that group of stakeholders who has a couple of different roles. One is that they are gonna bring some influence in terms of the prioritization of things that we're gonna go build. And we'll talk about this a bit later, but at earlier stage companies, it's okay if that outer ring of executives and key stakeholders is heavily influential in the process when you're a certain size company. And that will decrease over time, but there's always gonna be some influence that comes from that group. Secondly, and more importantly, and this hap— this is true no matter where you are in the growth stage, these, this is a group of people that needs to be intimately aware of what you're building, why you're building it, when things are coming out. So they can help amplify the value that you're creating so we can then get into market and capture that value in some form of ARR. Now, this is a scalable structure. The likelihood is no matter what stage you're at, you will have someone doing some parts of all of these roles. Now, that might mean that you have one person wearing 3, 4, 5 hats, and that's okay. So PM might be doing data analytics or doing some research, or maybe you haven't hired a designer yet, so you have the PMs doing that role. As well. That is okay for the growth stage you're at, but the key is it has to be crystal clear to everyone involved, your key stakeholders, about who's doing what and why they're doing, and to the depth that we expect them to be doing that role. And then of course, as you grow, we'll add more specialization, which we'll talk about in just a second. So what I wanna show here are examples of specializations that you can consider adding as you go through your growth journey. This is not intended to be an exhaustive list, to be clear, Just samples of ways to think about the roles that you're bringing on, why you should bring them on, and when. So if you're at Mr. Coffee stage, if you reach the sort of $1 million to $5 million mark, you should really be thinking about bringing on someone whose job is to be filling that product management role. Certainly you're going to probably have someone that's acting in sales role, if not a few people, and in support. Now, the key is, as I mentioned, product manager might be doing 3 or 4 jobs. The same is true for customer support. And sales, you might have customer support answering calls, doing implementations, writing documentation, et cetera. And again, that's okay, as long as everybody's clear about what those roles are, why we have it structured that way. Now, the Keurig stage, we've got a bit more versatility in our coffee, and it's time to bring a bit more versatility in our specialization. One example is we have our product managers that may have been doing a lot of market research and may be overburdened by it because for whatever reason, it's your stage company and your industry, there's a lot, a lot of changes happening. and you've decided it's time to bring on someone in a full-time research role, or it could be someone that's already there doing some research, and we've just made a conscious choice to carve out half their time to do research and half their time to do whatever existing job they were doing before. Another good example of this, a really powerful example, is product marketing. Now product marketing as a role could be filled by someone, say, in PM working across the aisle with someone in marketing or in sales, and you can fill that role. But the challenge is that we're trying to maximize the value of the things that we create. We're gonna try, try to tie it back to what does the customer really need to hear from us to understand what we've built? And product marketing is uniquely suited to fill that gap between what the product and engineering teams are doing and what sales and marketing CX need to be able to enable them to and empower them to go take this message back out to market again, to maximize the results, the value of the thing that you've built. Now you've upgraded to an espresso machine. You've got a well-oiled coffee-making contraption and you're living large. And now it's time to start expecting the same thing from your product development process. And so this is where we start to think about how we can optimize the overall processes that we put in place with a role that we call product operations. Now, this is a relatively new role in our field, but it's becoming increasingly important As we expect so much out of our product development process because we don't wanna make that $5 million mistake that I was talking about earlier. So someone that can step in to fill that role, again, it could be a part-time role, could be a PM that is leaning a bit more operationally, really like that stuff. They can step in and do this sort of a part-time for a period of time. And as you grow, you can start thinking about bringing on a full-time role. Regardless of the stage, the key takeaway is that these roles should be very clear, as I mentioned before, Everybody should understand what we're doing and why we're doing it. So there's no ambiguity. And you understand that when we need to add on a new role, everybody's clear about why that is and what the right time for that is. We've got a good foundation on our people side. We understand the right skill set are in the right roles and everybody knows who they are and what they're doing. Now it's time to start thinking about bringing on some good processes, right size and right place for your company to be able to be optimized, to optimize how those people are working. Now, the first thing I wanna talk about here before we get into the specific process is what we're building is we're trying to, we're trying to build out a process that will make sure that we're thinking hard about how we build for solving problems, solving broader market problems. This is a huge challenge for, certainly for companies of any sort of earlier stage where we're building based on projects, project backlog, we're maybe checking some boxes, maybe trying to catch up to a competition or something that we've heard recently from a customer, but we don't really all the way understand. It's just been a mandated thing. We wanna build processes that are incentivizing us to think about things in a broader context. That's how we get real growth, right? We don't solve, we don't get growth from solving for 1 or 2 or 5 customers. We get real growth from solving for 20 or 50 or 75%. Of the market. That's what we're trying to achieve. So it starts with prioritization, and there are a lot of ways to do this. An early-stage company may have a decently formatted spreadsheet, list of features. We rank them, we say score is 1 for high and 10 for low, and we have that rank order and we know what we want to build. Even at an early stage, I would encourage companies to think about it from the standpoint of a prioritization framework, like for example, RICE, which has been around for— raise your hands, have you ever heard of RICE? Scoring, RICE framework? Okay, I thought that was pretty, okay, good. Let me explain why this is so important. It could feel overly complex, and to be fair, it's not. It's some basic drivers, reach, impact, confidence, and effort. And these drivers are super important to drive critical thinking for not just the people that are making the prioritization decisions, but those that are hearing about it. So what this does is rather than say, ah, I think this is an important feature, it's super valuable, and 3 customers told me about it last week, Now we can go through and we can say, why is it that we think the reach is so high or gonna be so high on this feature? What are the things that's gonna make it so high? Why do we think the impact is gonna be high or low or whatever it may be? Now we're starting to ask some really critical questions that will help us understand the true priority and help us start to think about the goals that we have. What are the outcomes we're expecting for this feature? So regardless of how you do that, you're gonna come out of there with a prioritized list of things that we're gonna do and the list of things we're not gonna do. And why we're gonna do those higher priority things. Now we get into the build stage. And so what we call this is a tri-track model because it's based on the notion that we can run these 3 steps somewhat in parallel, which is based on the notion that we don't have to have perfect information to go to the next step. So we start out with a PM doing problem validation. Now this is really important because you're at the very early stages. The problems we choose to solve, we need to be really clear about what they are, why we should be solving them. So the PM does some varying degrees of light to really heavy validation on what this problem is, why it's important for us to solve it, why it's important now, our customer's gonna pay for it, those sorts of things. The next is the product designer gets, sees that we're far enough along in that process, picks the baton up and starts to think about what the solution should look like. Also starting to build some mockups and user flows and things like that and starting to do some light validation, ideally with customers, but it could be with some internal stakeholders who are customer-facing, just to start bouncing ideas off and see if we're on the right track. And then at some point along the way, the development team starts to pick up some technical spikes to see how feasible is this. Are we in the ballpark of this being solvable? Then of course at some point they start the build process. Now there's a couple of really important things here. First, the trick to getting this right is that the triad and with, in conjunction with some of the other support supporting roles, needs to get really good at constantly asking yourself the question of, can we make this smaller? So there, and the reason this is important is a lot of people will think about this in terms of what's the MVP? I don't like talking about MVPs because they don't mean, it doesn't mean anything. We all have our different definitions. We can't really decide what that means. It ends up stirring up more controversies than helpful. The way I think about this is I use a quote from Reid Hoffman quote from a while ago to articulate why this is important. He said, "If you ship something and you're not embarrassed, then you shipped it too late." Now, embarrassed is a little bit of a harsh term in this case, and it can be construed in different ways. So I say, if you've shipped something and you're not uncomfortable, then you've waited too late. And what does that mean? If you have this problem and somebody says to solve it is 100%, and you look at this thing and like 100% is, let's say it's 6 months worth of development. Instead of trying to do the 100%, start by building 10 or 20% of it. And of course when you ship it, you're gonna be uncomfortable 'cause it's not really done yet, but it's meeting the initial sort of entry-level needs to try to start solving this problem. Now to be clear, caveat, we're not talking about quality sticks, we're not compromising there. It's whatever the needs of your customers are. We're talking about the feature set, the capability that we ship to market to get something out that can we can test and start getting signals as to whether or not this is a truly valuable problem for us to solve. The second thing is running in parallel like this is a fantastic way to de-risk the solution. We get something in market much faster and we get the feedback back much faster as well. However, what it means is the triad and supporting stakeholders need to be in really good sync and build really good collaboration to make sure things don't fall through the cracks. The last stage is measurement. We've I already alluded this to some extent. This essentially is to say we've got a set of goals that we put in place, maybe some very basic things. Doesn't have to be heavy. Again, it could be 1 or 2 KPIs. It could be we expect the usage to be 30% from our customer base or something like that. Having something will let you, give you some guidance as to how close you are to hitting the mark. So we ship the feature, we look at our KPI, whatever it is that we're using, When we say we're getting good feedback, but the feedback is, "Okay, you're in the ballpark, but you need way more." That's perfect. Now we go to work iterating on that feature. It might take us 3, 4, 10 iterations to get it to really where we want it to be. The worst thing you can do is spend 6 months on something, you ship it to market, and it's crickets. You don't get bad or good feedback. That's when you know you have miserably failed. That's the reason why we work so hard to get really tight, small increments. So what the measurement Phase is gonna do is tell us, are we on the right track or not? Can we keep iterating? If we're way off, we need to think about pulling the feature. We need to think about cutting our losses early enough so we don't waste any more time, as hard as that may be. And by the way, I'm sure most of you are well aware of this. Another way to really mitigate this risk even further is through beta. We get a beta of that initial release out there, we test the feedback, and it's much easier to pull a beta than it is a GA feature. This is the, that was the sort of continuous development process, but you still need to have some steps and milestones along the way, some check-ins to make sure that you are on track for hitting your broader goals. And if you are at, say for example, the Mr. Coffee stage as we talked about, you may have a very basic prioritization framework as a spreadsheet with a list of features and you're doing some check-ins with your executive team or stakeholders, let's say every 2 to 4 weeks, right? Just to have a good check-in, Everybody's aligned regardless of how you got to priorities. You're super clear that this is the stuff we're going to build. This is what's going to be built later. And these are the reasons why we prioritize it the way we are and the goals we're expecting. Now, once you advance to the Keurig versatility and variety, you're going to have to start thinking a little bit further ahead on your roadmaps. So instead of doing something on a monthly basis, you're going to start thinking about doing what we call quarterly planning, where we're bringing a bit more rigorous prioritized list that the team's spending time doing capacity planning, dependency mapping, and hopefully looking back on what you achieved the previous quarter and applying those learnings to quarters coming forward. And then the outcome of this may be a 3 to 6 or maybe even 9-month roadmap to give you some sense of where you're going. Now, once you advance to that glorious automated espresso machine, you're pushing buttons, getting great coffee, it's time to start thinking much further ahead. You're starting to get get more advanced in your quarterly planning process. You may want to introduce a yearly alignment session. Now, I understand that for most startups, thinking a year ahead maybe seems like a waste of time. Yes, things will change, but the goal is to get really good alignment about what— how you're thinking about the product direction, where you're trying to go as a company. That really sets the tone for everything that you do going forward. And keep in mind, as you grow as a company, the communication challenges and collaboration challenges become bigger, right? So you have to come up with new ways to solve for those things. At first, you may have been working right next to the salesperson and you lean over and tell 'em, this is how it's going and this is the feature and explain it. They get on the call and they sell it and you're good. But when you get to a place where you got a marketing team that's maybe on the other side of the building or in a different office or a different part of the country, we've gotta really start to enable enable them, as we talked about with product marketing, to really amplify the things that we're building, really maximize the value, get it in terms of what the customer needs. Doing things like preparing for webinars and all the PR that comes from great things that we build, we need to really empower them much further out so they can get a head start of what we're trying to do. The last thing I'll point out in this is this quarterly planning events are a really big staple for how I make sure we're maintaining that customer centrality that we talked about. But they don't have to be big. They don't have to be heavy events. Can be the core group of product and engineering folks who are spending some time preparing. You get that kind of core group with some stakeholders involved for a few days of alignment sessions. And the result of that is you read out to the broader organization your updated roadmap, why it is and what your goals are, and everybody's in really good alignment with how you're trying to carry the company forward. All right, the next thing you wanna do is talk about tools. Now tools, no matter what stage of company you're at or how basic the tools may be, they're a really good way to help ensure that your teams are able to easily follow the processes that we just talked about, that we put in place to make sure we're optimizing the business. We don't want this to be a heavy thing. This is gonna be reducing the burden on these teams to help us implement these processes. Now the first thing is we said that Mr. Coffee Stage, probably you need to have some good prioritization frameworks as we talked about. It could be something as basic as taking feedback from emails, as we talked about earlier, or from Slack. PM drops that into a spreadsheet, does some basic prioritization, does the check-ins on the monthly basis that we talked about. The moment you get to the Keurig stage, you will definitely be starting to get far more feedback in terms of volume and the sources and the variety of feedback. And what will happen is if you're not careful, you, the people that are charged with maintaining that feedback and managing all that will get massively overburdened and they either won't keep up and we turn into that black hole of feature requests that we talked about earlier, or they're so burdened they don't, and we ask like, why aren't you doing your real job? The reason is that we've totally buried them. So at this stage, we need to start thinking about bringing a tool that's more designed for managing this at some scale. Now, some companies can do this fairly well with a dev-oriented tool like a Jira or GitLab, for example. My suggestion is, and what I've seen to work very well, is at this stage, start to think about a modern road mapping tool that's purpose-built for what we're trying to do here. It's not gonna add that much in terms of time or effort or even cost because the limited number of people that may be using it, there's few only licensing and all that great stuff, but it's really purpose-built for what we're gonna do and set you up for some of the later stages that we're gonna talk about. Now, at the advanced espresso machine, you are getting in an incredible amount of feature requests and data from a variety of different sources, from partners to analysts to internal, to looking at your competition. It becomes quickly overwhelming that even with some good tools, you're still not gonna solve for the scale challenges. So you wanna start thinking about some ways of building in some smart integrations, maybe some very basic things to start with, and you can add onto them over time. And another thing is, and this is Jason M. Lemkin, This can apply to any stage, but what we're learning, and to be honest, at the beginning I was fairly skeptical about how well, uh, AI was going to advance what we did as quickly as it did. And it turns out it is making our job so much easier. Take massive amounts of data from a variety of different sources and proactively pull that in a way we can start to see real trends and real understanding the mindset of the customer and the problems that they're trying to solve in ways that we never could. In the past. So this is a view of how we are set up at Dashlane. To be clear, we're probably further along than maybe most of you are in our growth journey. This is really designed to show you what are things to be thinking through, what you should be trying to get to in, in the direction of why, as you're growing. So we'll start with, as we said, product board is a road mapping tool that we've chosen. There are many alternatives, but it is our source of truth. Goals. And we reinforce this over and over again. What we're gonna build and why we're building it, how it aligns to our goals, is all captured in Product Board. Now, of course, we integrate with GitLab in our case, and so we're sending data out from a development standpoint, but this is where things start. Now, on the input side, I'm not gonna go through all these, but a couple examples. We still take input from Slack, our internal stakeholders. We want to empower them to share feedback with us in the easiest way possible. And a lot of time for them, that's through Slack. The difference is I don't have a product manager responding to every single Slack message. That goes directly into Productboard, categorized and routed to the right people, drastically reduces the burden on our product management and design team. So again, other sources of data, of customer data we get that's super powerful, provides a lot of context. The one I wanna call out because it's really exciting and something very new for us is we built some AI tools in Gong. Gong is, as many of you probably know, the tool that our sales team uses to record prospect calls, CX uses to record customer calls. And what the AI is doing is listening for some sort of customer sentiment to say that there is a problem that they have that we're not solving. There's a feature that we're missing. There's something they don't like about the product. And we're keying off of that. And the moment we hear that, we send that over to Product Board as a feature request with all the context that we need. Now we're being incredibly proactive about what we're looking for and how we get that data. Before, I personally listened to a lot of gong calls. That's great, but even my broader team is not gonna scale in a way that AI's gonna scale to pull this data in. So in closing, I wanna cover a few key takeaways, things that you can use as early as next week to begin, next week to begin rolling out a right-size customer-facing or customer-centric strategy and structure for your business. Now, the first thing is we talk a lot about this prioritization framework, something that's going to incentivize your broader organization to prioritize objectively those problems we want to solve that are gonna have the highest impact for the broadest segment of the market who we're serving. Without that, again, you're guessing, there's a little bit feature factory work going in here, and so it's not gonna work. Prioritize everything you do. By the way, one thing is, practically speaking, things will jump the prioritization framework. You will— it's never gonna be perfect. And even if I have a perfect list of 1 to 20, I may not do number 1 for some other reason. This is directionally accurate is what we're trying to get. It gives you a stronger sense as to which are the right things that you're gonna do. Regardless of what it is, we should still put it through this framework so we can learn from from it. The second thing is on the people side. As we mentioned, we don't want to try to framework our way out of having good relationships and good collaboration. So we want to invite our people, external or other stakeholders to the prioritization events, the planning events that we talked about. We don't want to try to just build out processes and tools that don't require any people input at all. We're losing far too much context. And certainly if we're trying to build our way out of talking to customers, which no matter what we do and what I told you today, that still is a super critical part of what we're trying to do to make sure we gain, gain feedback and context about what we're trying to solve for. Now, that being said, we do need tools and processes that allow us to link these critical market problems back to the features that we're trying to build. We can't solve it all just by talking with internal stakeholders or even talking to customers. We'll spend our entire weeks doing doing either meetings or calls or just responding to Slack, and that definitely won't scale. So you need to have a good balance between the two. The last thing I'll say is, as I mentioned many times, it's super important that we're matching the people, process, and tools to where we are in our growth stage. Just like the coffee machine in your break room needs to match what type of company that you are, so too should your process and tools match what stage company you're at. Now here's the important part, and I've mentioned this a couple of times, I cannot reiterate this enough. It's super important that we're clear with all of our key stakeholders what we're doing and why we're doing it and who should be responsible for these things multiple times in multiple ways to the point where they almost get sick of hearing it because everybody needs to be in really good alignment. I'll close by saying it this way. If you get to the point where you've shared this out enough times with enough people in enough ways ways where they can play it back to you what it is that we're doing. By the way, we're depending on them to be a part of these processes. If they're playing it back to you, that's when you know you've achieved the alignment that you need to be successful. Thank you, everybody. Appreciate it.