Mark Needham

Thoughts on Software Development

The Lean Startup: Book Review

with 5 comments

I’d heard about The Lean Startup for a long time before I actually read it, mainly from following the ‘Startup Lessons Learned‘ blog, but I didn’t get the book until a colleague suggested a meetup to discuss how we might apply the ideas on our projects.

My general learning from the book is that we need to take the idea of creating tight feedback loops, which we’ve learnt in the agile/lean worlds, and apply it to product development.

Eric Ries talks about the ideas of the Minimum Viable Product (MVP), which is something that I’ve heard mentioned a lot in the last few projects I’ve worked on so I thought I knew what it meant.

I’d always considered the MVP to effectively be the first release of any product you were building but Ries’ frames it as the minimum product you can release to get feedback on whether your idea is viable or not. For example Dropbox’s MVP was a video demonstrating how it would work when the team had written the code to sync files on all operating systems.

On a lot of the projects that I’ve worked on we start after the point at which the business has decided what their product vision is and we’re responsible for implementing it. They haven’t necessarily then gone on to make a big return from building the product which I always found strange.

The most frequent argument I’ve heard against releasing an ‘incomplete’ product early in the organisations that I’ve worked for is that it could ruin their brand if they took this approach. One suggestion the book makes is to release the product under a spin off subsidiary if we’re worried about that.

The book also discussed the ways that we need to treat early adopters of a product and mainstream customers differently.

For example early adopters won’t mind/may actually prefer to play with an unfinished product if they can help influence its future direction.

By the time we have proved that we have a viable product and are looking to aim it at the mainstream market it will need to be more feature complete and polished in order to please that crowd.

There is a big focus on making data driven decisions such that we gather metrics showing how our product is actually being used by customers rather than just guessing/going on intuition as to what we should be doing next.

Facebook released an interesting video where towards the end they describe the metrics which they have around their application such that they can tell whether a deployment is losing them money and therefore needs to be rolled back.

One particular thing that the book talks about is cohort analysis:

A cohort analysis is a tool that helps measure user engagement over time. It helps UX designers know whether user engagement is actually getting better over time or is only appearing to improve because of growth.

We tend to use metrics to help us see the quality of code and which things we might want to work on there but I think the idea of using it to measure user engagement is really cool and should help us to build a more useful product.

I especially enjoyed the parts of the book where Ries talks about ways that some of the ideas have been applied with startups which are doing well at the moment although I think it’d be fair to say that the lean startup framework has been retrospectively fitted to explain these stories.

I think the danger of thinking that they were following lean startup principles is that it can lead to us not thinking through problems ourselves which I guess is the same problem with any framework/methodology.

I’m intrigued as to whether it will make a difference to the overall success rate of startups or not if they follow the ideas from the book.

I imagine we’ll see some ideas failing much more quickly than they might have otherwise and the suggestion is that when this happens we need to pivot and try and find another approach that will make money. Despite that, there there will come a point when the startup runs out of money without finding a way to monetise their product and it’ll be game over.

Overall the book is quite easy reading and worth a flick through as it has some cool ideas which can help us to spend less time building products which don’t actually get used.

Be Sociable, Share!

Written by Mark Needham

December 18th, 2011 at 9:00 pm

Posted in Books

Tagged with

  • The book spinned up a discussion in an XP mailing list about balancing the internal quality of an MVP with the need for fast releases: an hacked up version of the product that validates its value hypothesis may not be able to evolve as quickly, especially after a pivot. Do you feel speed of development in the short run is in contrast with current Agile/Software Craftmanship practices?

  • The advice to do things under a spin off if the company is worried about brand doesn’t sound like good advice — brand reputation is a real issue that stops many big companies from being nimble, but is obviously much less of a problem for a startup. Was the book’s advice anymore nuanced than that?

  • Hey,

    I’ve been trying to find exactly where in the book that bit is talked about to see if it elaborates any further – I’d just written the idea down in my notes but didn’t note the page foolishly. I’ll look again and see if I can find the exact advice.

    I’ve worked before on a product which was run under a different brand to the organisation which was funding it effectively as a startup and although I don’t know much about branding I didn’t think it seemed such a bad idea? 

    I think it’s much easier to work in quick feedback loops when you get rid of the bureaucracy that can often accompany attempts to put things in production in bigger organisations. 

    He did talk about it being more difficult for famous entrepreneurs to release a new product because people expect a lot from it due to their fame but the vibe I got was they just have to live with that. 

  • I think it is a little bit but it seems to tie more with the ideas that Dan North has been talking about whereby you delay your decision to spend more time TDDing code/making it well factored. He talks more about it on his blog –

  • I guess it’s not bad advice if it is practical for the business, but in many cases the existing brand is part of the product — it can’t be separated. For instance, I’m working for a household name Australian company, and we spent a year developing a solution before launch. We were delivering some parts to production, and we worked in a Scrum methodology, but it would have been near on impossible to build or launch the product without the brand, and I don’t think our situation would be unusual.

    Anyway, I have the book on my reading list, so hopefully will get a chance to read it over summer.