Eric Ries answers questions on the application of lean startup principles in some edge case scenarios

It seems that every other startup we see these days espouses lean principles.  I’m not always sure that there is a thorough understanding of what that means though.  Partly for this reason I recently wrote a post about how Path and Flipboard are seemingly abandoning lean startup principles which, combined with discussion in the comments, raised a few interesting questions about the implementation and applicability of lean startup principles.  We have now put those questions to Eric Ries, who was in town last week for the launch of his book Lean Startup – The Ultimate Guide to Lean Startup.  The questions and answers are presented below.


(Nic) At companies like Path and Flipboard they believe that high design values are a key part of the value they provide to consumers.  According to lean principles they should test that hypothesis as quickly and cheaply as they can, but delivering a high quality well designed user experience takes time and fast learning may not be possible.  How should companies like this approach product development?

(Eric) It’s a great question, the two things are not necessarily mutually exclusive. Even great design can be tested. Often, customers care less about the things that you think they will. At IMVU for example, we set out with some very high expectations about the quality of what we wanted to deliver but using Lean Startup principles we discovered something very interesting. We wanted our avatars to move around virtual environments in a very ‘real’ way. We wanted to build physics engines into the system that offered a very high degree of realism. This was really, really, hard to do. We tried a very clunky, simple approach to the problem instead. Our avatars moved instantaneously from where they were, to where they wanted to go. Inelegant and simple. Customers loved our ‘Teleport’ feature. The cost of delivering the solution we wanted to just didn’t make sense after that.

(Nic) Short iteration cycles and rapidly validating learning are key tenets of the lean approach.  These can be challenging on mobile given the time it takes to get new versions of apps approved and live in stores.  Is ‘lean’ therefore less applicable on mobile?

(Eric) It certainly makes it harder to do continuous deployment! The feedback that you can get from even a relatively small set of customers/testers though is always going to be helpful in focusing your development activity on the things that matter. The feedback you can get, even from a relatively small number of test users should be enough to give you real insights into what is valuable to people if you know what questions to ask and are honest about what you learn. Releasing a version of an App with new features that then becomes more popular, does not necessarily mean that those features are the reason that the app has become more useful. You need find ways to understand what customers are actually doing. Given the constraints of App Store approval, you also need to be able to see what customers are doing with the new app. Find some users that you can observe in the wild. Sometimes, the qualitative information that you can get from observing 10 or even 20 users will be as valuable to you as a bigger dataset of 1,000s.

(Nic) Does producing a minimum viable product in advance of a company having a commercially viable product just tip competitors off to what we are doing?

(Eric) This is a question I am always asked. People always overvalue their ideas and it is natural for people to want to protect their IP. Entrepreneurs should always try to find a way of socializing their ideas and getting feedback from real people – your friends are always going to be encouraging! Try this experiment to see how unlikely it is that someone will steal your idea. Take your second best idea for a business and try to get someone to steal it. Even if you sat down the lead product management people in the biggest company in the world and offer them a solution to a problem they have had forever, it is almost inconceivable that the idea will be ‘stolen’. (Note – Eric seems to have answered a different question here – i.e. will launching an MVP get my idea stolen?, rather than will launching an MVP damage my brand?)

(Nic) Most of the discussion around lean relates to consumer services where the cost of failure is minimal. Are lean principles equally applicable to startups with who are building products their customers will rely on for mission critical systems (e.g. banking systems, security software, some healthcare services) or which require significant capital investment (e.g. semiconductors, some cleantech)?

(Eric) There are always situations where lean startup ideas will be less important – frankly, if you know you can develop a successful cure for cancer, you don’t need to spend too much time validating the idea. In this situation the risk is in technology development and execution, not in the addressable market. For large scale, long term projects however, there is almost always a case for a company to remain focused on the important stuff. Organisations should not be afraid to change direction in the light of market feedback and that can come from iteration between the business and technology people. Let’s say you are building a piece of hardware that enables simple, high quality video conferencing and it will take two years to go from idea to market ready product. If you are not constantly aware of what the market is doing, you could easily end up with a product that is well designed and beautifully coded, but is just redundant as other products are bought to market. I think one of the most important things for the organization to understand is that just because someone has spent hours building something, it doesn’t make it right. If an engineering team has invested 5 person years to develop a solution that still requires 2 more years of work to finish, and the problem is solved elsewhere, how responsible is it to continue that development?

You can also find ways to test and prioritize your development on long term projects. That video conferencing startup for example could build web sites or landing pages that offer elements of their solution to the market and then observe which ones get the most interest. This might not be perfect data, but it is likely to be more useful than no data  at all and a long list of unprioritized features.

Enhanced by Zemanta
  • Path is actually in the Lean Startup book as an example of a company that focused on making things that people want through building a minimum viable product, as opposed to listening to peers, tech blogs etc, and that seems to have paid dividends for them (if you count raising funds as a milestone). 

    It doesn’t seem from your previous post about their talk at Le Web that they are refuting those principles, but instead that they are in a different point of their development, where the customer need has been validated and now they are trying to create more value. I expect this is where design plays a big part, because it is about creating those memorable and delightful experiences, in which case rapid testing becomes less important than trying out something rough. Not to be too much of an evangelist for Mr Ries, but he does talk in his book that some of these techniques are more useful for early adopters who are more accepting of a rough and ready approaching, then when you are developing a product for the mass market, who just want things to work they way they should. It just seems Path might have outgrown some of these tools. 

    Also, I’d say there is a lot more to lean than simply a MVP. A more scientific approach to building new features, creating a culture of learning, cross-functional teams…

    Now I do sound like a fanboy. 

  • Hi Adil,

    I read the part about Path in ‘The Lean Startup’ after I’d written that Le Web post and it gave me pause for thought. I think it is a stretch to argue that Path had validated customer need with their first release, and therefore the long time period from first release to second means there was a large leap of faith and slow learning. Hence Morin has taken a step away from lean startup principles.
    Sent from my Android phone using TouchDown (

  • Pingback: More details on Lean Startup « zemantified()

  • My understanding of Lean Startup is that it combines these three principles

    i) everything is proven or dis-proven by a market test
    ii) smart startups quickly design appropriate tests that allow them to test the market 
    iii) everything begins with a guess (okay, hypothesis) and ends with proof

    Therefore the skill is, a) great guesses b) appropriate tests c) sticking to the lean startup principles/ discarding your cherished guesses which don’t gather positive proof

    As you said in your previous post Nic, this can be learnt – and therefore it can be taught.

    I’ve written a short piece that links this process back to the scientific thinking of Richard Feynman – you might want to have a look here


  • Hi Neil – the challenging bit for many is making the tests appropriate. Figuring out what to measure and how to measure it is easy at a theoretical level but for many it is tough in practice. Appropriate tests are a bit easier to find in science because they are anything that will disprove the theory (if memory serves me right…)

  • Yes, you are right Nic.

    I think the reason for this is that in business you can measure two different things and both will give you a valid or both invalid – or both give different answers!

    I’ll give you an example – I’ve been working with a digital startup on their business model – and in one version we believe that revenue is driven by signups – in another version – we believe that revenue is driven by depth of engagement with site (currently measured as page views).

    Currently, both routes to revenue are correct – so which one is ‘truly’ right?

    Well, with time – as the audience / user base matures, we believe one will become more reliable in forecasting revenue.

    However, the real value here is not the outcome – ie. this measure or that – but, rather, it is the discipline of going through the process.

    We are attempting to instill the ability to ‘going through the process’ in our startup teams as that will teflon plate them for an ever changing competitive, technological and user landscape.

    And this is where the link with Feynman’s approach to proof is valuable – just in business we have to keep testing to see if it is true – and we half expect to find that something that once was true – no longer is! But at least the team will know how to go through the process again of uncovering the essential link between activity and revenue.


    ps. This also helps shed light on why the team is the critical success element in any business