The Lean Startup approach is built on the loop: Build, Measure, Learn. While some might say it’s just launching incomplete products to see what works, it’s been a successful model across the Agile world at large. While I embrace iterative feedback and agree that the framework is infinitely better than its Waterfall predecessor, I’d argue that the way most companies implement Build, Measure, Learn misses the mark. Here’s why: you should never start putting resources into building something before you have done any research.
Let me be clear. I’m not suggesting that we revert to the old days of huge, up-front “Discovery Phases” that include massive amounts of research, requirements definition, and non-collaborative design work. Rather, I am an enthusiastic champion of incorporating constant research and learning cycles into the development process.
As it stands, many companies approach Build, Measure, and Learn more like fire, ready, and aim. Hopefully, you can see how that might not be a strategy for success.
The Lean Startup methodology calls for your first step to be building a minimum viable product, or MVP, so that you can start collecting data. Eric Ries, father of the Lean Startup methodology, defines the MVP as, “that version of a new product which allows a team to collect the maximum amount of validated learning with the least effort.” While launching a working product is critical to the process, the primary Lean Startup outcome is learning.
In practice, this often means that a team launches into building some sort of prototype to show people to collect feedback. To avoid wasting too much time prototyping, we often hear the advice to create a landing page or video to describe the product idea to gauge potential customer engagement. In that case, you assume that customers will be interested enough in the product/service/feature that they sign up and you monitor that engagement.
However, there is an awful lot of information about the users and their needs that you can investigate far before you build even the simplest prototype or landing page. You can learn before you start building.
Make your first step conducting potential user interviews. That’s right – talk to people. Before you build anything, you can quickly verify that people have an existing problem and that your idea might be a good way to solve their issue. While you’re at it, you can investigate any assumptions you might have about those types of users and identify open questions to explore later.
Investing just a small amount of time in researching initial assumptions helps verify your idea and guides an MVP that is infinitely closer to what your customers will ultimately want and need.
Let’s take an example. A client recently came to us with an idea for a browser plugin. He had already built a version of the plugin but wasn’t getting the traction he needed. He assumed usability problems were the culprit. He put us in touch with prospective customers, and we spent a few days interviewing them to understand their goals.
As it turns out, his product did have usability issues, but that wasn’t the main reason he hadn’t gotten traction. It turned out the bigger opportunity was expanding the target market and product offering to provide even more ways to interact with his brand.
It didn’t matter how well-executed the original solution was or whether he had spent two days or two months building it; no matter how short the Build phase, that time spent could be even more successful if there was an initial investment in the Learn phase.
Yes, iterative loops of building, measuring, and learning are vast improvements from the days of throwing designs over the wall to a development team, but the Build, Measure, Learn Loop is flawed as well. Simply flipping the existing Build, Measure, Learn loop, to begin with a brief Learn phase can provide validated insights to ensure that you’re building the right thing for the right people.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
