'; }

Our Blog

The Skinny on Lean Startups

November 6, 2014 - Business Psychology -
By: Chris Riley

Using lean for streamlining manufacturing processes has certainly had some enviable successes, and applying it to other areas of business seems like a great idea. Certainly, every area of business can benefit from eliminating waste across value streams and universally optimizing methods. But, in terms of long-term growth and success, when the trend shifts toward applying lean concepts to business models, we may confront some significant challenges using it to effectively bring a product to market.

The success or failure of whether lean will work as your business model depends on how you view your minimum viable product. While it’s true that experimentation and iterative design is better than spending all your resources on one top-down design, if your MVP is actually a “minimum viable message” that you are testing for response, using lean concepts (as in lean marketing) may not be the best approach. Ultimately, your business needs to build a relationship with the market, and relationships start with first impressions. Per lean, your first iteration may be a product that does not even come close to solving a problem. If you roll out an MVP that is not fully realized, the users who were on board initially will likely drop your product quickly and not give you a chance in the future.

MVP Infographic

This may be especially true if you’re planning a product that appeals to developers and operations. If this is your focus, and you try a lean startup approach, you may be quickly overwhelmed with negative feedback. Releasing a product to developers with the idea that you’ll fail fast and learn continuously may end with just failing fast. You won’t get a chance to reach “product-market-fit” because your target audience will dismiss your non-viable product and not bother to return for the second round of testing.

So while a lot of good—a focus on customer feedback, split-testing and iterative design—can come from taking the lean startup approach, startups need concentrate on one important goal: Creating relationships with the market and putting out a viable product that adopters will absolutely love and can’t live without.


Chris Riley (@HoardingInfo) is a technologist who has spent 12 years helping organizations transition from traditional development practices to a modern set of culture, processes and tooling. In addition to being a research analyst, he is an O’Reilly author, regular speaker, and subject matter expert in the areas of DevOps strategy and culture. Chris believes the biggest challenges faced in the tech market are not tools, but rather people and planning.

  • Alex YatesReply

    Great post Chris,

    We've struggled at times with the MVP concept. For me, when lean start-up goes wrong it's often because people tend to define viable incorrectly. Our brand is based on quality and many of our customers are DBAs. For us it is important to include stability in our definition of viable, as well as feature specifications.
    I've struggled , however, to figure out a binary test that defines whether your code is stable enough. Do you have any suggestions

    Once again, great post. If you'd like to read how we applied MVP on a recent greenfield: http://workingwithdevs.com/sql-lighthouse-account-of-agile-project/

    November 7, 2014
    • mm
      Chris RileyReply


      What an interesting problem. I hope I understand it correctly. But also a very cool opportunity. The fuzzy response is your viability is really based on "do we solve a real problem" and if the key problem solved is reliability this has to be built in. But looking outside in, I think the direction you guys are going it is more important to provide is the one stop portal interface that does the heavy lifting with multi-node DBs. Essentially the management layer is the critical problem solved, and reliability is something I would have to be confident you are continually improving or testing.

      Here is an idea I have been mulling over as a product ( I wont do it so you guys should ) which is a universal DB interface that does service virtualization to a DB platform. For example as part of a QA process you could have this service, which is part libraries of queries and part standard data set which interact with every new release of your product during QA. Just like the area of genetic algorithms however, the hardest part is the time to generate the dataset (truth data and metrics based on that truth data), and writing the test cases. It is a trick because in this instance the test cases are related to reliability and I bet security as well. But for reliability a multi-node setup of the service virtualization application ( because in theory it will scale infinitely based on how you want to test ) and measure non successful vs successful transactions across the entire DB. Also latency etc could be a very good test. The most important part is consistency I think. Because if you can compare results of a series of runs with this tool then you have a better picture of the impact. And it' might not be so important the tests themselves.

      I hope that makes sense and not on a major tangent that does not relate to what you said. Love to talk about it more. I have another product idea up for the first DB vendor who asks about it :)

      Thank you for the link!

      November 7, 2014
Would you like to share your thoughts?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.