Welcome to Innovation Pulse, your quick no-nonsense update covering the latest in startups and entrepreneurship news. Open AI shifts focus to integration layers amidst fierce competition. Cloud Kitchens aims to revolutionise food delivery with AI-driven processes and why Combinator witnesses a surge in AI-driven startups. After this, we'll dive deep into
transitioning from output to outcome in product development. Open AI initially dominated the AI landscape with ChatGPT, but the large language model industries has since become commoditised. Open AI's strategy now focuses on building a moat around the application and integration layers, rather than just the model itself. ChatGPT has evolved from a basic chatbot into a more sophisticated tool with features like web search and code interpretation, boasting over 400 million
weekly active users. Open AI has also introduced a Work with Apps feature in its macOS app, allowing seamless interaction with other applications, like assisting with code editing. Despite impressive features, competitors like Google and Microsoft pose significant challenges. Open AI's partnership with Microsoft is uncertain, as Microsoft explores other AI partnerships and develops its own AI assistants. Open AI aims to win the integration and API wars
by simplifying the creation of LLM and agentic applications. By providing a comprehensive API framework, Open AI seeks to lock developers into its ecosystem, making it difficult to switch platforms. This strategy aims to set the industry standard, but faces competition from Chinese AI labs and legal hurdles, with no clear winner yet.
Let's now switch to the transformative potential of AI. Cloud Kitchens, founded by billionaire Travis Kalanick, is revolutionising the food delivery industry by offering an innovative approach to meal fulfilment. Based in Los Angeles, the eight-year-old startup owns a growing real estate portfolio, utilised to establish kitchens that support food delivery services. Kalanick envisions a future where these kitchens evolve into AI-driven hubs, delivering AI-perfected meals
directly to consumers. Kalanick argues that relying on traditional platforms like Uber Eats or DoorDash limits restaurants as these platforms can alter terms unfavourably. By controlling the entire process from cooking to delivery, Cloud Kitchens aims to sidestep these issues. The company is exploring Atoms AI, where AI interacts with the physical world, suggesting a future of autonomous meal preparation and delivery. This approach contrasts with competitors like Wonder, led by Mark
Lor, which is also pursuing AI-driven meal planning. Lor envisions a comprehensive system that integrates dietary preferences and health data to customise meal recommendations. With significant funding and a transformative vision, Cloud Kitchens is poised to disrupt the traditional food industry, potentially redefining how meals are prepared and delivered. By Combinator, a renowned startup accelerator has witnessed unprecedented growth in its latest batch
of startups, largely driven by advancements in AI. According to Y Combinator CEO Gary Tan, the startups are experiencing a growth rate of 10% weekly, a first for early-stage ventures. This surge is fuelled by AI's ability to automate repetitive tasks and generate new code, enabling app developers to build software more efficiently with fewer resources.
Remarkably, AI writes 95% of the code for a quarter of these startups, allowing them to achieve significant revenue milestones, up to $10 million, with minimal teams. This shift reduces the need for large engineering teams and substantial capital, aligning with a renewed focus on profitability. The economic climate has opened opportunities for engineers who might not find roles in big tech companies, encouraging them to launch successful
startups. At Y Combinator's recent demo day, 80% of the presenting companies were AI-focused, demonstrating earlier commercial application and garnering real customer validation. Founded in 2005, Y Combinator invests $500,000 in exchange for equity and offers a robust network and support system, helping over 5,300 companies become valued at over $800 billion collectively. And now, pivot our discussion towards the main entrepreneurship topic.
All right, everybody, welcome to another episode of Product Thinking, where we break down the ideas that are shaping how products get built in today's world. I'm your host, Yakov. And I'm Jordan. Today, we're diving into something that sounds simple, but is deceptively hard to execute, moving from outputs to outcomes in product development. Exactly. This is one of those concepts that everyone nods along to in meetings, right?
Oh yeah, we should focus on outcomes, not outputs. But then you go back to your desk and you're staring at the same roadmap full of feature deadlines. It's the product world's equivalent of saying, you're going to the gym more. Everyone agrees it's a good idea, but actually doing it consistently, that's where it gets tricky. So let's break this down for our listeners. At its core, moving to the product model is about moving from outputs to outcomes. But what does that actually
mean? In the simplest terms, outputs are the things we build, the features, the updates, the new buttons and screens. Outcomes are the differences those things make, to customers, to the business, to our teams. Right. And that difference is really what matters, because we've all been part of projects where the team celebrated shipping something on time. But then, six months later, no one's using it. Or worse, people are using it. But it's not moving
the needle on anything that actually matters to the business. It's like throwing a party where everyone shows up, but nobody has fun. Perfect analogy. The article points out that while this concept is straightforward, implementing it is tough. Many companies try to move to outcomes, but end up spinning their wheels. Why do you think that is? I think the biggest reason, and the article calls us out as the number one mistake, is that companies try to layer outcome
thinking on top of their existing processes without actually changing how they work. Like slapping an outcomes sticker on the same old output machine. Exactly. For example, the article mentions how many companies tried to implement OKRs on top of their existing roadmap processes, and then wondered why nothing changed. It's because OKRs were designed for organizations already working in the product model. They're not magic. They're a tool that works within a
specific context. Right. And speaking of context, the article points out that moving to outcomes requires framing things differently. It's about giving teams clear problems to solve, helping them define how to measure success, and making sure they can track if they're actually solving those problems. Which sounds like common sense, but it represents a major cultural shift for a lot of companies. Let's talk about some of the examples they give of clear problems to solve.
I love these examples because they're so straightforward. Help customers solve issues without having to contact us. Reduce the subscriber churn rate. Connect job seekers with more suitable jobs. Notice how none of those say build feature X or launch product Y. Exactly. They're framed around the actual problem, not the presumed solution. And that's key. When you focus on the problem, teams have the freedom to find the best solution, not just implement something that was
decided months ago. And that brings us to another mistake, the article highlights, having vague or ambiguous problems. When your goal is something fuzzy like provide integrated platforms, how do you know if you've succeeded? You don't. And that's actually convenient when you're only measuring project completion. If your goal is just to ship something, anything, then who cares if the goal is clear? But when you start measuring outcomes,
clarity becomes non-negotiable. You can't measure success if you don't know what success looks like. The article makes a great point about how these problems exist at different levels of granularity or altitude. Some are specific enough for a single product team to tackle, while others need multiple teams or even cross functional collaboration. I like that altitude metaphor. It's like, are we talking about a problem at 30,000 feet or a ground
level? Exactly. And speaking of levels, let's talk about the distinction between product outcomes and business outcomes, which the article mentions. Right. This is important. Some people hear outcomes and immediately jump to revenue and profit, the top line business results. But those are usually the end result of many different outcomes stacking up. It's like a chain reaction or those domino setups where each piece knocks over the next. Product outcomes around user engagement or
customer satisfaction contribute to business outcomes like revenue growth. And this is where strategy becomes essential. A good product strategy connects those dots between what teams are working on and the ultimate business goals. This reminds me of another mistake the article identifies, not having an intentional product strategy. So many companies have business goals and product roadmaps, but nothing connecting the two. That strategic gap is where good intentions go to
die. You need that logical pathway from here's what the business needs to achieve to here are the specific problems each team should solve. And once you've identified those problems, you need to make sure you're measuring the right things, which is another common mistake. This is where people often get confused between outcomes and KPIs. Totally. The article makes a great distinction there. While outcomes are measured with KPIs, most KPIs aren't helpful
measures of outcomes. I love their car dashboard example, the gas gauge and tachometer are KPIs. But if you care about improving fuel efficiency, they don't actually tell you if you're solving that problem. And this leads to another pitfall, letting existing metrics dictate which problems you solve. Just because you already track certain numbers doesn't mean they're the right ones to focus on.
Right. Strong product leaders don't limit themselves to existing metrics. They identify the most important problems first, then figure out how to measure success, even if that means creating new KPIs, which brings us to another non-negotiable. Actually collecting the data you need, you can't manage what you don't measure. Absolutely. The article points out that many companies still treat analytics as a nice to have rather than essential infrastructure. But if you want to
focus on outcomes, you need to invest in telemetry. I think that's where a lot of organizations hit a wall. They want the benefits of outcome based work, but they're not willing to make the foundational investments in data collection and analysis. It's like wanting the benefits of exercise without actually going to the gym. There's your gym analogy again, but it's spot on. Now I wanted to touch on something interesting. The article mentions about Amazon. Oh yeah, the input versus output thing.
Exactly. Amazon emphasizes focusing on the inputs, like selection, price, and convenience, rather than the outputs. Orders, revenue, profit. But they're using outputs differently than how we've been discussing. Right. They're basically saying focus on the causes, not the effects, which is still aligned with outcome thinking. It's about understanding what drives the results you want. And I think that's a good segue to another important point from the article. Not everything
needs to be a problem to solve with an outcome. The keep the lights on work. Exactly. There's always going to be operational work that just needs to get done to keep things running. Not everything needs a grand strategic justification. I think that's actually reassuring for teams transitioning to this model. You don't have to force everything into an outcomes framework. Definitely. So to wrap things up, what do you think are the key takeaways for listeners who want to
make this shift in their organizations? First, recognize that moving to outcomes isn't just about changing what you measure. It's about changing how you work. It requires adopting the product model more broadly. Second, invest time in clearly defining the problems you're trying to solve before jumping to solutions or metrics. Third, be willing to define new metrics if your existing ones don't actually measure if you're solving those problems. And fourth, make sure
you're collecting the data you need to know if you're making progress. I doubt a fifth. Be patient. This is a significant change that touches everything from how you plan to how you measure success. It won't happen overnight. Great point. The article concludes by acknowledging that delivering outcomes is much harder than delivering outputs. It requires new competencies, new skills,
and a different approach to work. But the payoff is huge. Instead of just shipping features and hoping they make an impact, you're actually tracking and optimizing for the differences that matter. Listeners, we encourage you to consider where your organization falls on this spectrum. Are you still primarily focused on outputs or have you started to shift toward outcomes?
And if you're just beginning this journey, start small. Pick one team or one initiative where you can apply these principles and use that as a learning opportunity. Great advice. Well, that wraps up our discussion for today. Thanks for tuning into Product Thinking. That's a wrap for today's podcast as we explored how OpenAI and Cloud Kitchens are navigating competitive landscapes and the importance of shifting from outputs to outcomes in product development. Stay tuned for more updates.