Tag Archives: minimum viable product

Culture First, Product Second

A few weeks ago I keynoted the Founder Institute’s opening session in Finland. A successful serial entrepreneur Sami Inkinen, a co-founder of Trulia, talked about the culture. Sami asked a great question from the audience: “Which one is more important: building a great culture or shipping your first product?” The majority chose shipping the product over the culture.

This, however counter intuitive it may sound, is the wrong answer. As I had a related  unpublished story waiting in my drawer, I chose to publish it.

The most important thing in any startup is its culture and the people who live and breathe that unique culture. Building a successful startup is always about creating a high performance team with attitude, commitment and passion. A high performance individual you see often while a high performance team that works efficiently together and is committed – that’s a rare thing. This part of the puzzle is very tough to get right the first time (or second time …) and usually requires iteration (i.e. firing people) which can be very painful and hard.

I wish I were more clairvoyant on this all important aspect but so far my experience is that you only see if a team works or not when they are in a knee-deep shit – as it is easier to be excited and high performing in the very beginning of a journey or when the times are good.    

Naturally being exceptionally good at hiring goes a long way.

The product comes second. Entrepreneurs need to define their minimum viable product (“MVP”) and choose a launch angle out of many possibilities.

Defining an MVP is hard, as for any given higher level product concept, you can easily choose dozens of different MVPs to test the product concept, and thus false positives or false negatives are a real issue – and fully dependent on your ability to see and guess the most relevant MVP for a given product concept in a given test market.

When the core team is in place and an MVP is out from the oven and exposed to the market, it is the right time to raise funding. This is the natural order, not the other way around where a skeleton team with key roles missing tries to raise funding with a set of PowerPoint slides.

Too many startups are wasting their own and angels and VCs valuable time in chasing funding when they are not yet fundable.

To summarize:

  1. First, build a great culture and hire the core team that is not only highly capable but positively contributes to your startup’s culture. Companies stay alive, fly or die because of their culture.
  2. Second, build a minimum viable product to test your assumptions. Do understand that from the very same product concept a number of different MVPs can be built. Some are better guesses than others. 
  3. Third, raise seed funding at the stage when you have core team in place and MVP ready to rock.

You can reach me at mika (at) marjalaakso (dot) com.

Nokia Startups Mistake #7 – Minimum Viable Product

“A minimum viable product that is anything but minimum.” 

This is part of my Nokia Startups Mistakes series. For a backgrounder, please read the introduction. This post is directly related to previous posts about the culture, the high burn rate, and being close to the customer.

For engineers with Nokia background, it seems customary to build gigantic minimum viable products (“MVP”). Nokia is not known for its agile software development practices. On the contrary, according to many Nokia alumni, it always took a hundred engineers to build anything at Nokia – no matter how small.

It takes a lot of product vision to define a meaningful MVP, and not being close to the customer makes it even more difficult.

How to keep the product minimum?

  1. Avoid excess funding,
  2. Slideware, paper prototypes, UI sketches are an excellent way to test market.
  3. Start with a small nimble software team comprising one to five people. If you need a bigger team, it is unlikely that you are building the minimum.
  4. Use agile and iterative software development practices.
  5. Get out of the room and establish a feedback loop with a few lead customers early on.

It is much easier to work with the problem definition and play with various paper prototypes etc. longer when there is only you and perhaps your co-founder. The whole situation changes mentally when you have even a small software team in place, and guess what they start to do?

Yeah, right – they start to code while it in many cases would be much wiser to keep working with the problem definition and cheap paper prototypes.

I hope you will enjoy this series, the thoughts it provokes, and the discussion it triggers. Please do participate to the discussion by sharing your own angle and experiences on this topic.

If you would like to get notified of a new post, please follow me on Twitter, and subscribe to the blog and its Facebook page.