Running Lean, by Ash Maurya, is an extension of The Lean Startup, offering a down-in-the-weeds look at how a smart guy builds product using the Lean Startup methodology.
As was the case with The Lean Startup, I found this book to be a well-organized refresher of material I’ve already poured over elsewhere, specifically: Ash Maurya’s blog (which is fantastic; add it to your Reader), The Lean Startup and The Four Steps to the Epiphany.
In this case, however, it’s not a book I recommend you run out and buy; instead, I’d suggest checking out my book review of The Lean Startup, reading my thoughts below, and spending some time visiting the links provided.
The Lean Canvas
One of the key principles that Ash introduces early is that your product is not the product, a scalable business model is the product. To help evaluate your entire business model, he introduces The Lean Canvas, an evolved version of Osterwalder’s Business Model Canvas.
The image above does a lot of the talking, but the idea is that you can capture the essential hypotheses of your business model… all on one page (like Ash, I love single-page working documents). From there, it’s all about testing your hypotheses (via customer interviews, product experiments, advisors, etc – more on this below) until you arrive at a business model (and a product) that works.
Overall, I think the concept is spot-on and his post on the topic is a great read.
Before You Build Anything, Spend Time With Customers
The Lean Canvas is a great place to start when you’re exploring different business ideas; next, and before you build anything, Ash recommends you get out of the building and talk to potential customers.
>> Brief aside >> I couldn’t agree more… I have been consistently amazed by what customers come up with. My favorite analogy came from Steve Krug, who said something like: “they’re more likely to point out that your house is missing a roof (major feature) than the living room walls are the wrong color (minor feature your team has been debating)”. I have seen this in action, several times – in one case, a simple research project suggesting we should have built a different product – and am fast to recommend this path when talking to young startups.
Where this book excels is in providing a step-by-step guide to how these conversations could be conducted (based heavily on Steve Blank’s Customer Discovery model). There are two key interviews you should conduct with customers (have each one several times) before you build anything:
- Problem Interview. Your goal is to talk to potential customers about their problems (i.e. NOT about your solution). You want to understand: (a) who are the early adopters (b) how bad is their pain and (c) what do they do to solve this problem today. Here’s a post from Ash that covers the ‘Problem Interview’ in great depth.
- Solution Interview. Once you understand the key problem, it’s time to have customers help you discover the right solution. In this interview, you demo/visualize your solution and validate that it will solve their problem.
Ash even goes as far as to provide interview scripts in the book – a great resource, in particular, for those new at interviewing. As with any methodology, though, it’s less important to follow the steps and more important to apply the principles.
With all this talking out of the way, this brings us to the point where you’re ready to build a Minimum Viable Product (MVP).
Lean Product Development Process
In the first run through the process, the goal is to create a minimum viable product that tests your riskiest product hypotheses. In subsequent runs, the same principles apply but instead of creating an MVP, you’re making incremental product improvements to test your follow-on hypotheses.
Either way, you’re running experiments to vet falsifiable hypotheses (e.g. simplifying the signup flow will lead to a 20% improvement in our activation rate). Here’s what forms the basis of an experiment:
- Understand the problem. And state it clearly. Now, this could be a business-model-level hypothesis from your Lean Canvas (e.g. core customer problem is that audiobooks are a pain to manage from their mobile device) or a product-level hypothesis (e.g. our activation rate is too low to sustain our business).
- Define the solution. This is the meat of any product development process – it involves wireframing, prototyping, customer testing, (iterating), designing, and delivering the proposed solution.
- Validate qualitatively. This isn’t required with every release, but the idea is that you take the finished product and review it with customers in-person. This is something we didn’t do at Zeo, but that we should have.
- Verify quantitatively. Once deployed with real customers, use innovation accounting, cohort analyses and split tests to determine which experiments are driving real value to your business.
Now rinse & repeat until you have product/market fit, and a business model that is clicking. Here’s a great post that covers how Ash uses this process to drive his company.
Other Gems
Finally, to wrap things up, here are some other thoughts I found helpful in the book:
- Hack to find problems worth solving: go deep in a vertical and surround yourself with other passionate people; if you’re looking, you’ll see problems and existing alternatives they’re currently using.
- My first hands-on introduction to Continuous Deployment. I’ve heard about it, talked about it, even been around it, but I didn’t learn some of the underlying principles the way Ash lays them out. Here’s a presentation he gave on Continuous Deployment that covers much of the same material.
Though I didn’t recommend running out to get this book (particularly because of its overlap with materials that I read in the past), I did enjoy the read and hope I saved you some time with this post.
{ 0 comments }
