Despite some later critique, The Lean Startup by Eric Ries was a game changer for many entrepreneurs because it introduced key concepts for building adaptable (and therefore competitive) businesses. Interestingly, while many software teams have historically adopted Agile practices, few have fully embraced Lean thinking in their day-to-day work.
This article highlights key takeaways from The Lean Startup, from the perspective of cultivating adaptability in product development teams. As the author points out, startup-like environments do also exist within larger organizations, particularly where there are entrepreneurially minded managers and teams.
#1. Redefine Productivity
One powerful reminder from this book is the need for organizations to redefine productivity. Not as churning out code or features but proactively learning what is most valuable for customers.
This was a reminder that feature teams can be highly productive (and even efficient) but disconnected from what is most critical for business success. Creating useful products usually requires staying closely connected to customers, with frequent feedback loops.
The book suggests that Validated Learning is more important than Productivity. The author emphasizes that while taking the time to learn what to build may seem slower at first glance, it ultimately speeds up feature development. The reason being that this approach prevents wasted effort on features that don't deliver value. By validating ideas early, teams avoid costly rework and streamline subsequent development, ultimately accelerating the overall pace of feature delivery.
#2. Run more well-designed experiments
If teams and organizations embrace the need for Validated Learning as described above, the first step is to design strong experiments. These experiments typically begin with a simple hypothesis - either a value hypothesis or a growth hypothesis. A value hypothesis focuses on whether a specific customer problem exists and if customers actually desire a solution. A growth hypothesis focuses on whether a product or feature can drive customer acquisition or retention.
In addition, the goal of an experiment is to systematically validate assumptions and learn. Therefore, designing effective experiments requires clearly articulating the assumptions that need to be validated.
Finally, every experiment should include a clear plan for measuring success - and that plan should be part of the experiment design.
#3. Create simple MVP's to learn quickly, then invest!
Once an experiment is agreed upon, the next step is ideally to create the simplest possible solution (i.e., an MVP) to gather feedback and learn. Note that this often does not require any software development. The author recommends starting with simple visuals, videos or prototypes. As well as considering approaches like Design thinking, Lean UX or even the Wizard of Oz method.
Another important aspect of an MVP is identifying a small group of early adopters. By engaging directly with these customers and presenting them with a visual or something experiential, teams can gather feedback quickly. This input can then be used to refine the MVP and iterate upon it with regular feedback from customers.
It should be acknowledged that many teams have some PTSD when it comes to MVPs, as they are (by design) low quality and yet there is often pressure to launch unpolished solutions. The author challenges developers to simplify their MVPs and also to consider that quality means different things to customers and developers. An interesting example is shared in the book around a low quality solution for moving avatars around in a virtual world that turned out to be the preferred experience for their customers. The key insight is that an MVP is a prime opportunity to learn exactly where to focus time and energy to improve quality.
That being said, early adopters are generally more forgiving than other customers. So organizations considering this approach should not only focus on quick product/market fit learning but also remain deeply committed to investing in higher-quality solutions.
#4. Always measure - and adapt as needed
During an experiment or MVP, the Measure step is a chance to systematically track progress through learning milestones. It is essential that teams can clearly articulate the original hypothesis, the experiments conducted and the quantitative data gathered.
The goal of the Learn and Adapt step is to assess whether there has been meaningful progress toward validating the original hypothesis. At this stage, teams will derive learnings from any data collected and decide on next steps.
Based on the data, teams may face tough decisions, including the possibility of pivoting. It should be noted that pivoting is defined as keeping one foot in it's current position and twisting in a different direction. In practice, pivoting tends to be easier when teams have not invested too much time, which can make them susceptible to the sunk cost fallacy.
#5. Small batches are more efficient
Leveraging small batches is a core Lean principle. Lessons from manufacturing show that while large batches might instinctively seem more efficient, rework is common and in large batches that can have a significant impact. In contrast, single-piece flow has proven to be optimal for reducing waste and maximizing efficiency.
The same principle applies to software development teams. Focusing on one small feature at a time, releasing frequently and iterating based on customer feedback is far more efficient than spending weeks or months developing a feature that might not meet customer needs or require extensive rework. Especially considering all the additional communication overhead that comes with that these days.