The End of Velocity: Product Strategy When Speed is a Commodity | Krasi Bozhinkova

Productized Podcast: Okay, so our next talk by Krassi Bojinkova. And super excited for this talk. First of because I looked at Krassi's slides and I said to her, wow, I really love the clarity in your slides. And I asked you just how do you come up with this clarity? And her answer was running, ⁓ running helps her her mind. just, you know, as a moment reflection, was thinking, This is even a moment where we can think about when do we take that moment, time to be able to clear our minds, to be able to create clarity, right? Just to think about. But I'm excited to introduce Krasi. She is ⁓ a fractional and she will talking about how AI today makes speed a commodity. And so how do we adapt our product strategy ⁓ when speed in is a commodity? So let's welcome Krásy por Ženková. Last week, I met a friend who is a PO and he was visually excited. So I was very curious. I asked him, what is going on? And he told me, you know, we had this feature plan for Qt 3, but now thanks to AI, we build it over the weekend. And I asked, so did customers request it? And he confidently answered me, no. But now that we have it, we can test it. And in that moment, I actually didn't feel first excitement. I felt concern. because had removed and collapsed the price of building, but have we really changed the question we're asking? ⁓ why are we still talking about can we build it ⁓ the harder question that we have to answer is what do we need to build? But before I talk about it, let's see a show of hands. Who actually thinks that building over the weekend is great? I'm one. Keep your up if you agree me. I have two more questions. So who thinks and who had built something over the weekend that worked perfectly? No one? come on. I know you did it. Okay, so who had built something over the weekend that worked perfectly and no one cared? Well, I'm one for sure. And that's I was concerned. Not because building is bad, ⁓ but because have really replaced One of the biggest constraints in product when engineering used to say it would take six months or three months. And now we might as well about building over the weekend. And think that this is really a dangerous situation to be. So hello Lisbon, I'm super excited to be this morning with you today and talk about judgment and talk about what does it take to build when speed is no longer differentiation. So a little bit history about me. Before AI and before SaaS services, I actually used to work in space communication. But before you ask me the question, I wasn't part of the SpaceX team. Otherwise, I would have been buying you drinks after the successful IPO tonight. But jokes aside, in my experience in the space communication taught me a really important lesson, because we didn't really have the luxury of building something on Friday. only throw it back on Monday because it didn't work. satellites, ⁓ really expensive, over 200 million up in the sky, and then you have to think about your customer needs almost two years ahead of time to plan your product. ⁓ about that. In such a hard environment, what learned the hard way also through a lot of mistakes and lessons was ⁓ actually how make decisions when data was not always available. ⁓ And more ⁓ how to not be reckless when a lot is at stake. I understand why building is so interesting and why are we fixated with it. ⁓ Because building immediate, we're in control, and it is ⁓ We see it away. But at the same time, it is so difficult to actually build something that matters. And I often ask so why is that? Why is what matters so hard? And I reached this conclusion that what matters resides in the most messy space. Think about values, about beliefs, think about customer needs, think about trust, think about time. And I would even say that if with what we built, we don't move any of these components, ⁓ we didn't build value. What we build is inventory. ⁓ We've the roadmaps, we exhausted ourselves, ⁓ and confuse the hell out of our customers. So this environment, I often ask myself, how did velocity become such a misleading metric and what really is going on? So I actually thought really hard about this question, reflecting on this and the marginal cost of building pretty much getting to zero. And I asked myself, why are we actually not really seeing the impact in the numbers? And what I mean by that is think about the growth rate. and not only in software services, but actually across the board for infrastructure as well. The growth is going down, and the growth is going down consistently for the last five or six years. At the same time, despite all the tools, despite the efficiency, despite how we collaborate, actually, I would even make a claim that we've become less effective acquiring new customers because the cost of Acquiring new customers is skyrocketing. It used to be below $2. Now we are reaching almost $3 for every one new dollar of revenue. And then, paired to that is the payback period. It used to be a gold standard in software services that will recover this cost of acquiring growth within 12 months. But now, as of 2026, we are looking at 20-plus months. And then you may wonder, what really is going on and why has it become so difficult to build in this environment? There are obviously valid reasons and of course compression, competitiveness, disruption, they all play a role. But also there are these fundamental changes that almost overnight seems to be erasing whole product categories that turn into features. We also see customers' demand shifting so rapidly, even before our capabilities to deliver what they want. And lastly, if you think about the user journey, well, these days, customers interact with your product long before they actually touch it with AI, thanks AI and all the other LLM models. So in harsh environment, it is only natural for us to ⁓ build more test more, more. But the real challenge and the fear that I have when I hear, sure, we'll build it over the weekend, is ⁓ think that many teams actually consider speed a strategy. But from my perspective and from everything that I've seen in my career, ⁓ only had concluded that speed ⁓ never strategy, speed is an amplifier. If you have a good signal, great luck to you. If you have chaos and weak assumptions, well, things are not going to go too well. And talk about what happens in this environment. Who actually from the audience knows Humane? Okay, I'm surprised. I thought would see more hands because, believe it not, Humane built their AI PIM product, came with a big promise that we are all going to go through life in a much better way We replace the smartphone with this smart AI sitting on our shoulder ⁓ instead staring on the screen on our hand we will just talk to it and get guidance and Yeah, be happy, ⁓ but it really really work like that Despite despite the fact that they had ex-apple executive leading team they had sleek design they had investors they had press you'd argue all great ingredients, but the one thing that they underestimated is what happens when you ship fast without reliability. And obviously, they broke the core promise so badly that 30 % of users actually return the devices. complained fiercely about the battery life, the really crappy accuracy, ⁓ also how long will it take to get even these answers? to a point that users start demanding whole music. Think about that. And obviously, when you have all of those wrong ingredients at the table, speed is never going to help you. Speed is only going to lead to very efficient failure. So as of 2025, I have said news, they closed shop, so you're no longer able to get to that. Speed is also really detrimental when you go fast. but without direction. And here I want to talk about ChatGtp Store. When Store launched in 2024, there was so much excitement from builders thinking, oh my god, now that I can put this custom LLM, I'm going to make all this money, I'm going to commercialize and really be successful and quit my career and have a better life. But it didn't really work like that because the thing about Chatchat EP store was that it was ⁓ of a fleet market than the traditional place ⁓ customers came, they were really confused and overwhelmed with they saw, ⁓ quite looking models out there, no clear pricing differentiation, and they left, which puts developers in a really weak and challenging situation because they wasted so much effort ⁓ building something. which gave them no clear monetization, no clear analytics, no ability to control or access, and led to a ⁓ lot of wasted effort, both for the team at OpenAI, but also ⁓ the customers this example. So, speed without direction, wasted effort. My third example that wanna talk about speed can actually hurt you, comes from Duolingo. Duolingo did a lot of great things over the years, ⁓ their product and the cool green owl. ⁓ the one thing that they underestimated is what happens when you rush to the market with your AI first strategy, only to find out the hard way that actually your users never translated AI first equals innovation or better product experience. ⁓ immediately heard cost savings, cost first, which perception really hurt not only the because users were ⁓ so adamant the experience that they started cancelling the service, being very on social media. In fact, the share price dropped with more than 20 in a single day because this perception of overall company strategy actually had immediate impact on product itself. customers had this conviction of what this is before they even touched it. So really be careful when you rush something with market because perception is a very dangerous road and could lead to not just internal chaos but like in this example external chaos. And lastly I want to talk about what happens and I specifically recognize also this pattern in the work that I do ⁓ when you as a company or team, have the capability, but you actually didn't gain the user trust. And I want to pause here for a minute let you reflect on this, because this is really an important one. And the story here that I want to share is about Snapchat. Maybe there are users of you in the audience here who used it and recall what happened when Snapchat introduced their My AI in actually most prime estate of the app. And users obviously ⁓ confused. So why was this feature even there? They didn't ask for it. They couldn't control it. They couldn't remove it. And it super frustrating. So the fact that you have a capability doesn't mean that you have the user trust ⁓ or their So it could be a really expensive gamble. So when I at these different stories, what I see here is actually ⁓ a paradigm that removed execution as a bottleneck on one side, but now we've been introduced a new bottleneck, which in my opinion is all about judgment, which also puts a different question, much harder question that we together have to work to answer. How quickly can we earn user trust, prove the value, and then turn this learning into growth? So I obviously didn't just come with bad news. to scare you, I came also with good news because not against speed, but I'm against reckless speed. And there are really great examples of products ⁓ look speed differently that we all can learn from and benefit and take these practices in what we do as well. ⁓ Because great teams, actually ⁓ trust earlier in the user flow. They also sharpen significantly the aha moment when the value is delivered. They are the ones that recognize early the new behavior they can scale discovery into production. And also they usage into really learning ⁓ but codified throughout whole organization. So let's look at who are the heroes in my story. The first one is framework. Maybe you know it, maybe you don't. But Framework in really tough marketplace where is a lot of compression ⁓ and to do something slick, ⁓ something that users have to replace every couple of years. But that's really their conviction because when Framework thinks about what do they to build, they never start with the feature, but they start with the trust promise, which in their instance is modular computing. So they are all about ownership, but ownership specifically that lasts, meaning that they provide certain level of control, upgradability, reusability, everything that needs actually do good care of their So, in that example, speed is used actually to reconfirm your focus or co-promise that case and then align everything that you do into this. The second example that I really, really like and admire the work that Remarkable is doing from the standpoint of what do you do when actually the biggest risk is not being slow to market, but the biggest risk is breaking something that your users love. And in this story, Remarkable is really withstanding the pressure of putting AI into the product, doing notifications, collaboration, apps, you name it. They simply said no. when we think about why is that, it comes from this point that for they wanted to protect the aha moment that was most valuable to their users, which means we can think clearly here. So again, speed, speed used really to decide what not to do, which is equally a very important ⁓ decision that you have to do. My third example is about a hero, Miro, this instance that actually uses speed but differently in this instance to discover those interesting behaviors before they scale fast and turn them into products. And for those that work like me with Miro over years, ⁓ they clearly can the difference of what I call Miro 1.0 and now the AI innovation workspace 2.0. where things are really different. But then you may ask yourself, so why is that? Is it because Miro had the capability and they just can throw things into it? had they actually think really carefully ⁓ recognize where the value was suboptimal and they did something about it? And I personally believe that it's not the but it's the latter. And the team a lot of time rethinking actually how the value that we would all get in the old model workshops or collaboration actually be carried all the way through the workflow. So that through innovation, can happen you have multiple teams that come together through different workflows and different artifacts to actually look at customer insights, ⁓ still idiot, but now ⁓ and also be able align in real time. And what Miro did is they realized that what users really needed is not just to work together, but protect this workflow and integrate it seamlessly with AI. So did it because ⁓ this recognition of the new behaviors that are worth turning into products. And the last example that I would like to share with you is, of course, Lavable. But not so much from the amazing achievement that they had. growing from 1 million to 100 million in less than a year, but actually of something else, because when I look at Lavable, I don't see a company that is just prototyping, I see a company that is fully on learning. And let me explain why. you operate in such an emerging place where customer behaviors are not set in stone and ⁓ everyone is discovering... together with the product teams, how to work in this new environment, especially with the AI-first products. Lavaboo is doing remarkably well is turning these confusions or incidents or complaints into important product signals. And if rewind a little bit, ⁓ maybe of you have heard what happened in April, where there was this big incident. When somebody discovered that you actually share your app, you actually make public access to the source code, to the chat history, ⁓ to certain aspects that would have been providing ⁓ or revealing confidential information. the important thing that thought is really amazing was not only that allowable fixed which they did, and they were very open and transparent in their communication with users. But they also realized that there was this gap in the perception of what the product is supposed to do and actually what the product is doing. So the team discovered this mismatch, they immediately doubled down and changed the system in terms of defaults, in terms of UX, ⁓ in of docs to ensure that there is a seamless integration of the perception but also of the product reality. to this is a pure example, a perfect example of what learning should be and how can support growth. And when I at these four examples that I shared of my heroes in the stories today, I don't think that see teams that sit and think, what else can we build tomorrow? ⁓ I think that these teams speed. and think about velocity but in much more deliberate way because their first question is what do we need to protect? Like in the case of Remarkable, what do we have to prove? How do we learn before we actually scale? And we can take some of these learnings into our own practices of how we shape the product decisions on our side because let's be honest, the reality is really changing very fast. So we have to adapt. And we need to make decisions on the move. We don't have the luxury of waiting and feeling comfortable because we have all the question marks answered and all the data in our disposal. So in this very volatile environment, what happens is that very often we have to go back and keep asking, are we solving the right problem? Do we have even the right understanding what that is? How about the value? Is it still relevant of what are we providing or it has been outdated and we have to do something about it. And lastly, about learning. Are we able to actually be faster at learning than at building? Because I truly believe that that's where differentiation resides. So let's look at some of the practical approaches that you can also take into your own domain and start experimenting. So how can you think differently about the problem space? Obviously, a lot can't. can change with your users, with your opportunity. segment that used to be sexy, now the urgency had disappeared. The may be solving a visible request, but the urgency is somewhere else. And the model, it could be the one that is blocking adoption. So in this instance, if you actually think ⁓ about the denominator of what Flip is all about is getting back to the basics of the critical user need. that you need to understand at the intersection of what is urgent, necessary, but also impactful. And don't have to think very far to recognize examples, like for instance Slack. There used to be a platform all about communication and messaging, but this became a commodity. So now Slack considered pretty much the operating fabric of the company because it's all about coordination and it's not about messaging anymore. also times where the value would have shifted. And then you have to really be honest with yourself and that perhaps the benefits that you provide are kind of diluted so much friction. And ⁓ like the case of Miro, you have to update not only your core value proposition, but also add new capabilities to it ⁓ so you can build a more engaging user journey. And that's when you have to do the hard decision of pivoting. It is not easy, but it at the right point in time can actually make your break your ⁓ and ultimately success. And lastly, when I think about hack, I always stop myself to say this is not just about prototyping. ⁓ Prototyping one way of learning, but we have to ⁓ discover proof also other ways ⁓ and forget about the business, the economics. not forget about the user behavior and the trust that we can test not just with prototypes, but we can with proofs of ⁓ commits, ⁓ paid services, of budgets clients or users are willing to allocate for us. think about hack as your really ⁓ approach to uncertainty and risk so that you still can make confident decisions without the business. So can apply it, obviously, on your journey or use these techniques on your growth loops, ⁓ your ⁓ is appropriate for. And ⁓ when reflect back and think about what can we possibly do when we go to our desks on Monday or our teams, and I myself that probably the hardest question to ask and answer is ⁓ no longer where we move fast? What do we build fast? But actually, be really deliberate of how we use speed so that we can focus better, we can when we need to, we can protect what ⁓ brings value to our users, ⁓ ultimately, we can learn so that when anything is possible, we actually build what truly matters. Thank you.