Since its publishing in 2011, Eric Ries’s bestselling book The Lean Startup (along with its principles, like the Build-Measure-Learn feedback loop) has ushered in an entrepreneurial revolution. We certainly felt its impact. Our company, SGW Designworks, was one of many featured in the book, a mention which understandably gave our business a boost in its formative years.
Eric Ries’s book was nothing short of groundbreaking for many startups. But while we may frequently hear about the Lean Startup’s impact on newly minted companies, its principles have been invaluable to SGW as we evolved. We’re now an established product development firm — and Lean Startup methodology, particularly the Build-Measure-Learn feedback loop, continues to guide our processes today.
The Build-Measure-Learn Loop: Beyond the Startup
The Build-Measure-Learn feedback loop lies at the core of the Lean Startup model. In his book, Ries explains this loop as follows: “The fundamental activity of a startup is to turn ideas into products, measure how customers respond, and then learn whether to pivot or persevere.”
Moving through — and accelerating — this feedback loop is key to successful development processes. But this cycle is also an important one for grown-up companies like ours, companies that design and develop products for our clients.
Continue reading for a refresher of the Build-Measure-Learn feedback loop, and to see how we’ve modified this loop to work for us and our clients, as well as lessons we’ve learned along the way.
Build — With a Minimum Viable Product (MVP)
When entering the Build phase, developers should have a minimum viable product (MVP). A MVP doesn’t follow the traditional product development trajectory, which typically involves a lengthy process and strives for perfection. On the other hand, a MVP is a version of a product that lacks many features but allows for a full turn of the Build-Measure-Learn loop with minimal effort and development time. Ries’s advice when building a minimum viable product: “Remove any feature, process, or effort that does not contribute directly to the learning you seek.”
Additionally, a MVP is designed to do more than answer technical questions related to product design — its goal is to begin (not end) the learning process. It’s not enough to build a prototype that we as engineers and designers will evaluate for internal quality, either. We (and our clients) will need to test our assumptions, based on reactions from potential customers.
MVPs — In Software vs. Hardware
While the concept of a MVP works well in a software development setting, this term has, at times, created confusion for our clients and complicated our approach as hardware developers. So, to prevent contention and conflict, we’ve moved away from using the term “MVP,” and here’s why: In software development, a first salable product is built, launched, and validated. Users provide input and developers can send a patch to address problems. However, this usually isn’t possible in the world of hardware. A minimum viable product typically happens earlier in a project for us. Before launching a product, we’re constantly looking for things we can test. In our case, the entire Build-Measure-Learn feedback loop generally happens before clients are accepting payment for said product.
Measure
The Measure phase presents a significant challenge for us as product developers: it’s at this time we must quantify the performance of the MVP, or prototype. Remember: a prototype exists to test specific things. When we measure, we proactively and quantitatively evaluate how the feature in question performed. The results then indicate if an iteration is required on that feature or not.
Learn and Pivot (or Persevere)
When we complete the Build-Measure-Learn loop, we’re able to gauge the direction and degree of our progress — which helps us determine whether or not we’re getting closer to our end goals for the product. These goals can be related to price, function, durability, and market fit, among many other things. We can then use our learnings to determine whether to pivot our original approach or persevere. If it’s necessary to pivot, Lean Startup methodology empowers us to do so sooner, which saves our clients time and money.
(Note: the Build-Measure-Learn feedback loop is typically a continuous process. Rather than stopping after one MVP, we use what we learn to immediately work on the next iteration.)
Client Lesson #1: The Build-Measure-Learn Loop Requires Discipline
Recently, we completed a consumer product for a client who is a new entrepreneur. They didn’t know much about the Build-Measure-Learn feedback loop and initially wanted us to learn what we could during the development process, then launch and hope for the best. However, thanks to our experience successfully implementing Lean Startup principles (and to having an open-minded client), we were able to move forward with this proven methodology.
In the beginning, the product seemed straightforward and relatively easy to build (it was mechanically simple and didn’t require any electronic work). But we still encountered a number of obstacles — and important decisions that had to be made — along the way. (This was no surprise to us as product developers, as we know to expect the unexpected.)
For starters, this product had to be collapsible — without adding too much complexity or cost. After some deliberation, we settled on using a living hinge, then created and tested a series of prototypes with a small user group to determine which version appeared most viable. And, in keeping with the disciplined thinking required to follow Lean Startup principles, every one of these prototypes needed to exist for a reason. When building, we made sure to always have in mind what we wanted to test — rather than creating the prototype and hoping to learn something along the way.
After narrowing down which prototypes worked best, we completed another progression through the Build-Measure-Learn feedback loop and gained more user input from a larger group. (Each of these loops may take anywhere from a day to a few weeks or months. The timing required for each loop depends on a number of factors, including the availability of parts [especially when working in firmware or electronics], the availability of people to test the product, etc.) Completing these feedback loops led to the final design of the product — and unexpected learnings. For instance, we were able to identify a potential new, secondary market for this product, which was a win for us and for our client.
The lesson: Lack of discipline is a major pitfall for product developers. We must have a test in mind and be able to capture unexpected information. Even seemingly simple aspects of a project need forethought and a lot of work to get right.
Client Lesson #2: In the Defense Industry, Norms Matter More Than Size
When working with aerospace or defense clients, we find they often aren’t equipped for rapid development cycles we’d normally complete with smaller clients. Recently, we’ve been working on a project for a defense contractor in which a level of bureaucracy 1) required us to plan cycles ahead of time and explain how these cycles will work and 2) made it impossible for us to gain access to end-users.
Working within such parameters, we may only be able to complete one Build-Measure-Learn feedback loop. That was the case for this project — even though we couldn’t do the type of cycles we would’ve liked to (with open and transparent testing/user interactions), we were able to get it done with almost entirely internal cycles. Instead of external user feedback from real product testing in the field, we set up simulations of how we believe the product would be used and generated results.
The risk here is that our assumptions around how the product may be used could be wrong. Additionally, defense-related projects also require superior engineering capabilities, and the red tape accompanying such work can make or break a smaller company that may be financially strapped.
The lesson: When full cycles are just not possible, partial or modified cycles can still produce useful results and lead to successful products.
Client Lesson #3: Testing — A Must for Any Project
A while back, a client hired us to develop an IoT version of a consumer product. This project required us to develop an app — which made it all the more important for us to get specific feedback from potential end-users.
We needed detailed input on features and user flow — everything from the device itself and how people were powering it on, using it, and charging it, to how smoothly the setup and calibration process worked. This data is necessary for helping product developers effectively determine whether to “pivot or persevere.”
While we received extremely generic feedback from the client, we didn’t get the detailed input we needed from their group of potential users. This resulted in an incomplete cycle through the Build-Measure-Learn feedback loop, and the project itself also remained incomplete.
The lesson: To effectively test a product and to capture real data, it’s critical to get units in the hands of potential users. If you’re not willing or able to perform the testing for which a prototype was designed, you might as well not build the prototype at all (or begin the project, for that matter).
Recommended Reading
In the past ten years, we’ve learned that even if one of our clients doesn’t buy into Lean Startup methodology, it’s helpful if they’re on board with this approach — because these principles still guide us when it comes to the development process. If you’re a leader or development professional in an established business who is embarking on building a new product, or you’d like to engage SGW on a project, we recommend reading Eric Ries’s book (if you haven’t already).
