Build, Measure, Learn

Estimated Time: 30 minutes

Build, Measure, Learn

image

When we think of successful products like Google Search, Facebook or Spotify, it's easy to forget their modest beginnings. The first version of Facebook, then called "The facebook" launched in 2004 and was restricted to students at Harvard. Its only feature was a profile page and the ability to friend someone. Many of the features we now associate with social networking, from photo sharing to News Feed or status updates, only came many years after the original launch.

Figuring out what should go in the first version of a product can be daunting.

Around 2008, Eric Reis proposed the "lean startup methodology." This approach helps startups use rapid experiments to validate their assumptions about their customers and markets. One of its key principles is the "Build, measure, learn" cycle.

How Build, Measure Learn works

  • Build: create a product or feature. The idea is to get something tangible to test as quickly as possible, even if it is not fully polished or complete
  • Measure: After building, the next step is to measure how well the product performs by gathering data on how users interact with the product, and getting feedback from users or customers
  • Learn: Use the data and feedback to make changes. This can involve making improvements, abandoning ideas that aren't working, or pivoting to a different product.

The "build, measure, learn" cycle is repeated continuously to build a product that meets the needs of users as effectively as possible.

The case for "Learn, Measure, Build" User-centric design starts with learning about users, before building and testing prototypes. By starting with learning, you can ensure that you are building and measuring the right things. That's why the design thinking process begins with empathizing with the user and defining the problem.

Moreover, the "learn, build, measure" sequence aligns more closely with the scientific method, which involves making observations, forming hypotheses, testing hypotheses, then analyzing results. This can help to make the process of product development more systematic and structured, and lead to more reliable and accurate results. That being said, there is no one "right" way to think about the "build, measure, learn" cycle, and the sequence of steps can vary depending on the specific needs and goals of a business or product.

The danger of big bang delivery

What's wrong with buiding out an entire product, then launching the final version? This approach, sometimes called "big bang delivery" might seem reasonable.

Using the big bang approach, all of the features of a software product are delivered to the user at once, rather than being released in stages. There are some potential advantages to big bang delivery, including:

  1. Reduced development time: by delivering everything at once, there is less time spent on development

  2. Reduced costs: reduce costs by eliminating the need for multiple releases, which can involve additional development and testing

  3. Improved user experience: by delivering everything that the user needs all at once, there is less waiting and fewer interruptions to the user's workflow.

🛑🛑🛑🛑🛑

While the benefits above are theoretically nice, they rarely materialize in real life. Lean methodology is hugely popular because most of the time, there are major drawbacks to big bang delivery, including:

  • Deployment risk: the larger the feature set beging delivered, the greater the chance of encountering bugs or other issues that negatively impact the user's experience
  • Estimation/prediction risk: predicting how long it will take to build software is hard. It's also hard to figure out all the features/functionality users will need, which can lead to missed opportunities or an incomplete product
  • Concentrated risk: if everything is delivered at once, there is no opportunity to course correct or pivot

As a result, big bang delivery is not generally a good approach for software development. Instead, modern teams use iterative development and phased rollouts. They focus on first delivering a "minimum viable product" or MVP, i.e., a stripped-down version of a product that can be released to users to gather data and feedback as quickly as possible. It is not intended to be a fully-fledged product, but rather a means of testing and gathering data on the product's core value proposition.

In the next lesson, we'll explore one of the trickiest parts of lean software development: crafting the ideal MVP.