Lean startup – Lessons from the frontline

Posted on November 23, 2011

I am starting my own company, as you’ve probably guessed by now. While I’m sure that you’re interested to hear what I plan on doing I need to save that for a future post. In the interim, I’m going to share some of my lessons learned from kicking off a new company.

When I first heard of the Lean Startup methodology that Eric Ries developed, I found it incredibly appealing because it provided a structured approach to creating a successful startup. Reis argues that you should be building the smallest possible product that attracts paying customers, listening to their feedback, then quickly and continuously improve the product. The methodology relies on measurement, experimentation and adaptation based on the real feedback from your customers.

Running a Lean Startup encourages you to think differently about the value of your company, and to understand how you can create that value in the shortest amount of time with the least amount of effort. In addition to ideas taken from lean manufacturing, developments such as agile software development and the emergence of cloud computing paved the way for lean startups.

Over the past two months, I have spent a lot of time speaking with startups, serial entrepreneurs, advisors, and everything in between. I found it very easy to apply the lean startup methodology to someone else’s business. Without being emotionally attached to their idea, staff or operation it was easy to hand out advice that aligned nicely with the concepts of Lean Startup.

At the same time, I was oblivious to this oversight in my own company. In the first iteration of my business plan I completely ignored the Lean Startup concepts. I was planning on making a huge gamble by hiring a big team and kick-starting the business without customers in the pipeline. I attribute part of my mentality to coming from a big company where everyone has specialized skills and roles. However, I was also emotionally vested which prevented me from taking a hard look at my plans through the Lean Startup lens.

Thankfully, I eventually noticed the oversight and fixed it. Or at least I thought I fixed it. Two weeks later I realized I had only applied the lean startup methodology to the technical side of the business. I needed to make some more mistakes before I came to that realization.

The Lean Startup methodology is very easy to read, understand and appreciate. The hard part is trying to take the emotion out of it. Eric talks about this a lot in his book and interviews but it took me learning it the hard way for the lesson to stick. Hopefully someone else can learn from my mistakes. Anyone else struggled with this one?


11 Replies to "Lean startup - Lessons from the frontline"

  • mkirkup
    November 23, 2011 (12:53 pm)
    Reply

    It is worth noting that there are variations on using the lean startup methodology. Joel Spolsky has a very compelling article on why they decided to forgo releasing their minimum viable product when it was very lean. Instead, they ran a closed beta to capture customer feedback and evolve it closer to a polished product to get better press coverage and feedback at launch.

    http://www.joelonsoftware.com/items/2011/09/15.html

  • Trevor
    November 23, 2011 (1:10 pm)
    Reply

    You should also read “The Four Steps to the Epiphany” – does a great job explaining “Customer Development” as opposed to traditional “Product Development” and very useful for making sure you aren’t just focused on the technical side.

    • mkirkup
      November 23, 2011 (1:16 pm)
      Reply

      Thanks Trevor – Downloading as we speak. :)

  • Jeff Bacon
    November 23, 2011 (1:18 pm)
    Reply

    While an MVP (minimum viable product) approach is one that companies have migrated to over the last year (especially in mobile), it’s not always the right approach. You need to make sure your product has enough features to be successful, not just the minimum to be useful. In some cases, release and iterate it totally the way to go, in others, a longer design and development timeframe can make a major difference in the success of your product. There’s a lot of products that “work well” and to stand out, you often need to “work great”.

    • mkirkup
      November 23, 2011 (1:28 pm)
      Reply

      Thanks Jeff. I completely agree with your point which is why I added the comment from Joel’s article above as a counter to my point about relying on releasing your MVP. Part of the gut call for each startup will be which approach do they believe will increase their likelihood of success. One of my biggest points is that we can get in trouble viewing our own companies through an emotional lens and as such make the wrong call.

  • Derek
    November 23, 2011 (1:19 pm)
    Reply

    Mike,

    First off, best of luck with the new endeavor. You’re missed already at the large company.

    Secondly, an interesting article and subsequent comment. Some great advice for those in the start-up world. One question or comment I would have is, do you see Joel’s approach and Eric’s approach to software release as effectively the same methodology, with slightly different implementations? Or do you truly believe there is a fundamental difference? I only ask as, I would see the counter to both of those approaches as the “big company” approach of build a full-functional finalized product then release it. Thoughts?

    • mkirkup
      November 23, 2011 (1:31 pm)
      Reply

      Thanks Derek – appreciate the kind words.

      To me there are a lot of similarities between what Joel and Eric recommend in that both are customer centric and evolve based on how users are interacting with the product. Large companies (and I know this intimately) have the bad habit of creating a product, getting it to the point where customers can start to use it (typically a closed alpha or beta) and then putting themselves in a position where they cannot act on any of the feedback (except very minor issues) until the next version.

  • Wes
    November 23, 2011 (2:15 pm)
    Reply

    Good post Mike – and good learnings I think.

    Even though we’re consider ‘Fat’ in lean start up terms e.g. 9 years in, 15 people cash flow positive and profitable, we still live by the lean start up principals when developing, launching and growing products.

    A couple of resources we live by:
    Start up metrics for start ups – http://www.slideshare.net/dmc500hats/startup-metrics-for-pirates-long-version
    http://www.youtube.com/watch?v=irjgfW0BIrw
    Getting Real – http://gettingreal.37signals.com/
    ReWork – http://37signals.com/rework/

    Good luck with your start up – keep in touch Mike

    • mkirkup
      November 23, 2011 (2:21 pm)
      Reply

      Well, “Fat” might be an unfair characterization of your business – profitable, cash flow positive and great people is exactly how I want to run my company too. :)

      Great links – thanks for sharing Wes.

  • Neil
    November 23, 2011 (5:39 pm)
    Reply

    My advice when it comes to startups is to first read every single essay written by Paul Graham to inspire and motivate (http://paulgraham.com/articles.html) and then basically get down to work. Hard work, where you put your back in to it and haul with all your might every hour of every day. Sketch out a business plan, but don’t put too much time in to it, because your final products and company will almost certainly look absolutely nothing like what you thought they would – I don’t really know of any single startup that has gone “according to plan”.

    Don’t get caught up with too much planning. It’s easy to remain forever in planning, paralyzed by fear or uncertainty that you might make the wrong decision. And the only way to get better at creating value is by actually doing it, again and again (iteratively) until you have a well oiled machine. And then the industry will go and switch things up 180 degrees, and you’ll have to adapt, re-learn how to be successful, or die.

    Personally, I dismiss the idea there exists “a structured approach to creating a successful startup”. It’s like wishing for a silver bullet for software engineering.

    • mkirkup
      November 23, 2011 (10:40 pm)
      Reply

      Thanks Neil.

      I am a huge fan of Paul Graham and agree that his articles are definitely worth reading. Appreciate the feedback.


Got something to say?

Some html is OK