MVP thinking

Airbnb started as a simple site in 2007 when two people were struggling to pay the rent of their accommodation in San Francisco. As a solution, they thought of renting the top floor of their apartment to the visitors. An ad about renting an air bed on a basic web page was placed. It consisted of their housing pictures and soon they had three guests. This simple solution later transformed into a company now valued at billions of dollars with millions of listings.

MVP thinking emphasizes iterative development, where a product evolves step by step, using feedback to refine and improve it after each phase.

The power of this process is that it allows us to continuously learn and evolve. Our learning is not limited to customer feedback. The iterative nature of MVP thinking also enables us to assess the technical aspects of our software. Through this process, we can identify any operational issues, detect bugs, and ensure that our code remains clear and maintainable.

Now, one might wonder, why not set a clear, extensive plan from the get-go and simply follow it? The truth is, even with the best plans, the path to our objective is rarely straightforward. By focusing on small, incremental steps, we allow ourselves the flexibility to adjust our direction based on real-time feedback and challenges. It’s not about having all the answers from the start, but about being able to learn, adapt, and refine our strategy as we move forward.

Here’s where many people get confused: iterative development isn’t the same as incremental development. At first glance, the two seem synonymous. Incremental development is akin to writing a novel chapter by chapter, each one building upon the previous. Once written, a chapter remains static. When working iteratively, a chapter may undergo several edits due to feedback from early test readers, detected plot inconsistencies, adjustments in the story’s ambiance, or even to align with market trends, like a publisher’s request for spicier scenes.

This begs the question: does MVP thinking imply that we should skip research and planning altogether? Absolutely not. Striking a balance between research and development is crucial. The balancing act comes in determining when it’s more efficient to learn by researching versus by developing. It’s about asking: “Will more research significantly reduce uncertainties?” versus “Will diving into development and getting real-world feedback provide clearer insights?”

What it feels like

Best case

  • Rapid iterations: Releases happen frequently, and the product evolves incrementally based on data and feedback.
  • Embracing feedback loops: There’s a strong emphasis on collecting and acting upon input from users and stakeholders.
  • Data-driven decisions: Changes and improvements are guided by metrics and real user behavior rather than assumptions. Comfortable with ‘imperfect’ releases:** The initial offering may not be polished, but it’s functional and designed to gather insights.
  • Pivots in direction: The plan is adaptable, and the team is willing to shift direction if the data or feedback indicates it’s necessary.

Worst case

  • Long development cycles: Significant time is spent between releases or before the initial launch.
  • “Big bang” releases: The mindset focuses on launching a complete product with all features in one go.
  • Assumption-based decision-making: Decisions are made without validation by data or user testing.
  • Fear of failure: Products are delayed or polished endlessly due to the desire for a ‘perfect’ launch.
  • Perfectionism: Products are delayed or polished endlessly before release due to the desire for a ‘perfect’ launch.