Running Lean is a handbook for practicing entrepreneurs who want to increase their odds of success.
Which, for me, was originally off-putting. Why? When I was reading the blurb, I focused in on the words innovate and iterate and blocked out venture and bootstrapping. I came at this book as an engineer, not as an entrepreneur. And my initial enthusiasm quickly waned: is this going to be one of those self-important business books? But pretty quickly, I figured out that it was not; Maurya was about to lay out a plan for (in essence) applying the scientific method to your business plan.1
Again, as an engineer by trade, I caught myself thinking: this is not what I came here for, I came here for ideas about effective agile development. That’s in there, but it’s just one of the many lessons that is embedded in Running Lean. Maurya writes lucidly about how to take your product/business idea and shape it; about how to organize your team to focus on The Problem and The Solution; about how to reach out to customers and interview them, to help them help you define the problem space; about how to pull out real information from those interviews and test releases, and learn real lessons instead of just confirming how great you think you are. The lessons of Running Lean help you to create a real solution for a real problem, and not just be a clever solution looking for the right problem.
But what about us engineers? What about folks like me that were looking for strategies on development iteration? Those lessons are in there, too — if you can get past the entrepreneurese and pay attention to the content.
There’s a quote in there:
Not only does this approach delay validation of one of the riskier parts of the model (because it’s too easy for a user to say yes), but a lack of strong customer “commitment” can also be detrimental to optimal learning.
And it made me think of this recent post by Gus Mueller (of Flying Meat Software). In that post, Mueller talks about what his historical pricing model has been for VoodooPad (one of his flagship products), and in particular what the pricing model has been for folks on an upgrade path; and then he goes on to talk about how the Mac App Store has disrupted that. In discussing all of this, he breaks down a number of different approaches he could take in the face of this new reality for his business. He is concerned about price, and naturally he is concerned about product quality; but he is also concerned about the relationships that his customers build with his products. Mueller writes:
I can already hear someone saying “just charge less and you’ll get four times as many customers- which is twice as much money!”. This will also multiply the support burden (and probably by more than 2x). Lower price means more people will buy a product on a whim. I’d rather have fewer customers that have done the research, compared multiple products, and is willing to pay a higher price for a product that fits their needs.
Fewer but more committed customers. Customers that have done the research. Customers that have decided that this is a product that solves (in a very real way) a very real problem for them. This sentiment dovetailed with Maurya’s lessons from Running Lean, and it resonated with me in a big and very important way. In a way, this is exactly the sort of thing that Maurya is writing about — about not chasing “vanity metrics” like hits or downloads or installs or sign-ups, but instead focusing on asking hard questions and finding real answers, and ultimately building real solutions for real problems for real people. But make no mistake, what Maurya posits is no easy task — it requires discipline, and there is a sanguine optimism that underlies his implicit assumption that you can do it.
Disclosure: I received an electronic copy of this book from the publisher in exchange for writing this review.
- And by extension: to your product development lifecycle. [↩]