Lean Thinking

A while ago I posted an article on people that I think have something really valuable to say to product leaders.  One of those people I discussed was Eric Ries, author of the blog http://www.startuplessonslearned.com.  I also promised that I’d share a glossary to map the nomenclature and concepts he uses with the terminology I use in my writing and my work with product teams.

I held off a little on this because he has been working on a book which has just recently been published, called “The Lean Startup” and in this article I’d like to discuss the key concepts in the book and provide that mapping.

First, I have to say that I consider this one of the best new books on product in a very long time.  Since I read it I’ve been encouraging everyone I work with to buy the book.  Eric has a strong mind and is also a gifted writer, and the result is a powerful combination.

I think the book is relevant whether you’re new to product or experienced.  I have been working on technology products for about as long as anyone, and I added several techniques to my arsenal, and I’m pretty confident you will find real value in the book as well.

I also believe the majority of the material in the book is applicable to all technology product teams, and not just early stage startups.

One worry I had going into this book was that he might try to take the concepts of Lean Manufacturing and force fit them into a technology product innovation context, but he really doesn’t do this at all.  He takes some of the relevant principles from Lean Manufacturing and applies them where it makes sense.  His key premise is that Lean Manufacturing is about removing waste, and since one of the most egregious forms of waste is to build a product nobody wants, maybe we can apply some of the techniques to reduce the waste in creating products.

Using my nomenclature, I consider this a book primarily about product discovery.  I define product discovery as the process of coming up with the minimum viable product, and that’s at the heart of the book.  But more generally he’s trying to share techniques for building a sustainable business: “The goal of every startup experiment is to discover how to build a sustainable business around the company’s vision.”

Glossary of Concepts:

Many of the terms we each use are essentially the same: validated customer learning, customer/user testing, pivots and split testing are examples, but there are some places where he uses different nomenclature, and I highlight these here (term that Eric uses, term that I use):

• Build-Measure-Learn Feedback Loop = Product Discovery
• Minimum Viable Product (MVP) = MVP Test
• Innovation Accounting = Product Scorecards
• Cross-Functional Teams (small but secure, empowered and motivated) = Dedicated Product Teams
• Customer Archetype = Persona
• Value Capture = Monetization Strategy
• Small Batch = Incremental/Continuous Development and Deployment
• Large Batch = Big Bang/Waterfall
• Early Adopters = Earlyvangelists
• Portfolio Thinking = Portfolio Grooming
• Metrics = KPI’s (Key Performance Indicators)

There was one key term that the book uses differently than I do, and that’s the term “prototype.”  Eric associates the term prototype with the engineering perspective, where a prototype is mainly about assessing technical feasibility.  He tries to draw a distinction between an MVP Test and a feasibility or usability prototype here: “Unlike a prototype or concept test, an MVP (Test) is designed not just to answer product design or technical questions; its goal is to test fundamental business hypotheses.”

In my use, there are different forms of prototypes for testing different things – a feasibility prototype would address technical risks, a usability prototype would address interaction design issues, but the primary purpose of prototyping in product discovery (user prototype or live-data prototype) is intended to assess the value of the product.

His big point is that the most important thing is to assess whether or not the product can support the business – especially value and growth.  And he’s trying to point out that just because something’s usable or feasible doesn’t mean people will want to buy it or that you can build a business around it.  In my writing, when I use the term “prototype” that’s precisely what I’m focused on as well.

Great Discussions

The book ties to cover quite a broad range of topics, some lightly and others more rigorously, but several of the discussions were especially noteworthy:

– Minimum Viable Product

Most of the book is about this concept of rapidly testing and iterating our way to coming up with something that will sustain a business.  The book shares quite a few good techniques for validating the market/demand, validating the solution, and validating the growth engine.

– Pivots

One question I get from so many teams is when to pivot and when to persevere (iterate), and the book talks about this explicitly as well as implicitly with good real-world examples throughout.  Also a very useful taxonomy of types of pivots.  Overall I’m hoping this book goes a long way to helping teams not only recognize a pivot opportunity, but embrace them.

– Growth

For many teams I meet, establishing strong value in the product is only half the battle, and they often struggle trying to get their growth engine working to the point that they can acquire new customers in a way that you can build a viable business around.  The book has a good discussion of the main ways technology products grow.

– Innovation Accounting / Product Scorecards

Probably my favorite section of the book covers what Eric calls “Innovation Accounting.”  There are several very relevant examples from companies you’ll recognize and the book does a good job of highlighting some of the big benefits as well as the pitfalls of business and product KPI’s.  This should be required reading for anyone responsible for coming up with the scorecards for their teams.

– Importance of Qualitative and Quantitative Learning

A hot button for me is when I meet people that only believe in one or the other of qualitative learning or quantitative learning.  But Eric truly seems to understand the importance of each: “Qualitative learning is a necessary companion to quantitative testing,” and “poor quantitative results force us to declare failure and create the motivation, context, and space for more qualitative research.”

– Sustained Leadership

I’d like to end this article with probably my favorite quote from the book, which I think does a good job summarizing why these techniques are so essential to modern product teams: “Sooner or later, a successful startup will face competition from fast-followers.  A head start is rarely large enough to matter, and time spent in stealth mode-away from customers-is unlikely to provide a head start.  The only way to win is to learn faster than anyone else.”  Amen.