Running Lean

Author: Ash Maurya
Publisher: O'Reilly
Pages: 240
ISBN: 978-1449305178
Audience: Anyone who wants to launch a startup
Rating: 4
Reviewer: Sue Gee

Sets out to provide actionable guidance for applying lean principles to a startup. Is it helpful?

This isn't a book about programming methodology - it is about business practices, but as the author Ash Maurya's has a technical background he approaches the problem with a "programmer mindset". He draws on the experience of own startups including BoxCloud a proprietary peer-to-web (p2web) file sharing application and uses its successor CloudFire, which he sold in order to embark on Spark59, as the major case study in this book,

The book's subtitle "Iterate from Plan A to a Plan that Works" sums up the main message of the book and its first chapter outlines how you should proceed with this strategy. However, before you embank on it, a point included in the Introduction helps understand the book's motivation:

Most startups fail and of those that succeed two-thirds have drastically changed their plans along the way. So what separates successful startups from unsuccessful ones is not necessarily that successful startups began with a better initial plan (or Plan A), but rather that they find a plan that works before running out of resources.

The book has a very logical structure which, as outlined in the introduction, divides the Running Lean process into three major steps which are covered in Parts 2 to 4 of the book.  Part 1: Roadmap has two chapters, the first of which describes the three core meta-principles that will be converted into actionable practices in the rest of the book:

  • Document your plan A
  • Identify the riskiest parts of your plan
  • Systematically test your plan




As well as providing a good overview of the author's approach, Chapter 1 also establishes the style of the book and its use of - diagrams, headings and bullet points to make the presentation very clear.

The second chapter in Part 1 uses the book-writing project that culminated in this book as a case study of the Running Lean process. You might think that applying the same process to a book as to a startup wouldn't work. But think again - the book is about an iterative process and it has obviously worked well given the success of this book. It also explains why this first appearance of a book is flagged as a 2nd Edition.




Part 2 has a single chapter titled Create Your Lean Canvas. Rather than spend months creating a business plan   Maurya advocates sketching a one-page diagram, called a lean canvas, in a a single sitting of less than 15 minutes. The canvas has nine sections to be tacked in order:

  1. Problem
  2. Customer segments
  3. Unique value proposition
  4. Solution
  5. Unfair advantage
  6. Revenue streams
  7. Cost Structure
  8. Key metrics
  9. Channels

The lean canvas for CloudFire is used as the case study for completing a lean canvas and when you come to doing your own there's a website where you can use the same layout. It's free for up to two users and paid plans start at $12 per month.for larger teams.

The chapter concludes:

The important thing is to share your Lean Canvas with at least one other person when you are done. 

This emphasis on getting feedback continues throughout the book.

Part 3 is about identifying the risks in your Plan A. Chapter 4, which is about prioritizing risks, starts by providing the author's definition of risk and then moves on to show how the Lean Canvas enables you to categorize it as:

  • Product risk - getting the product right
  • Customer risk - building a path to customers
  • Market risk – building a viable business.

CloudFire is used to help work out which of these three to prioritize and modifications to its Lean Canvas are incorporated as the chapter proceeds. One main message of the chapter is to seek external advice and a section is devoted to how to do this.

Chapter 5 has the title Get Ready to Experiment and tells you to start with the smallest possible team and to maximize your experiments for speed, learning and focus - do the smallest thing possible to learn.

Part 4: Systematically Test Your Plan occupies almost two thirds of the book and presents a four-stage process:

  1. Understand problem
  2. Define solution
  3. Validate qualitatively
  4. Verify quantitatively

Interviews are an important part of the first three stages. There's a customer interview in the first one and the recommendation is to include 10-15 people and to stick to a script - with a model problem interview provided in Chapter 7. Maurya also presents results from CloudFire and updates its lean canvas to reflect what was learned from the process.

While the Customer Interview is fairly short, the Solution Interview is more elaborate. While and for a software product you may imagine you need first to get a working solution Maurya advocates a minimum viable product (MVP)  - just enough of the solution to measure potential customers' reaction. Chapter 8 presents a comprehensive outline for a 25-minute interview and a sample document for recording results, a process that is allocated 5 minutes. Again CloudFire and its lean canvas is used to illustrate the process.

Chapter 9: Get to Release 1.0 contrasts a traditional product development cycle in which little learning is incorporated in the the development phase with a Continuous Deployment process in which cycle time between requirements and release is made as short as possible - minutes versus days, weeks or months. Acknowledging that Continuous Deployment is controversial, Maurya argues that implemented correctly it doesn't shortcut quality and demands stricter testing and monitoring. The book's Appendix includes a section on getting started with Continuous Deployment while Chapter 9 proceeds with discussion of an activation flow and the landing page of a marketing website.

Chapter 10: Get Ready to Measure is the first of three chapters on qualitative validation and explains the need for actionable metrics. The next chapter provides a model MVP interview and  the third one gets to product launch.

Chapter 13 has the intriguing title "Don't Be a Feature Pusher" and argues that need features should be in response to demand and that 80% of your effort should be devoted to measuring and improving existing features with only 20% devoted to new ones. Mauyra also outlines a Getting Things Done workflow in this chapter.

Chapter 14 moves on to defining and using a metric to measure product/market fit and here we learn the end of the CloudFire story. It also has a diagram that summarizes the workflow that has been followed throughout the book.

Chapter 15: Conclusion is very short. It has one and a half pages of comment and an equal amount of space devoted to resources - books, blogs and tools. Following this comes an appendix of B onus Material which seems to be notes for things that didn't fit within the flow of earlier chapters. This has the feel of being a bit scrappy and maybe when the book gets to its next edition this content will be better integrated.

Overall this book is likely to be helpful for the novice entrepreneur who has a good idea for a software or web-based product but lacks experience and is uncertain how to start on it. its advice about testing opinion and gaining feedback early and often should either help you achieve success or prevent you from getting bogged down or wasting valuable resources (time and effort) on a project that is going nowhere.      



The AWK Programming Language, 2nd Ed

Author: Alfred V. Aho, Brian W. Kernighan and Peter J. Weinberger
Publisher: Addison-Wesley
Pages: 240
ISBN: 978-0138269722
Print: 0138269726
Kindle: B0CCJ1N4X3
Audience: Developers interested in Awk
Rating: 5
Reviewer: Kay Ewbank

The name Brian Kernighan among the authors of this updated classic raises  [ ... ]

Software Mistakes and Tradeoffs (Manning)

Author: Tomasz Lelek and Jon Skeet
Publisher: Manning
Date: June 2022
Pages: 426
ISBN: 978-1617299209
Print: 1617299200
Audience: C# developers
Rating: 4
Reviewer: Mike James
We all make mistakes - do you want to read about them?

More Reviews

Last Updated ( Saturday, 29 June 2013 )