in Startups

The Misinterpretation of Minimal Viable Product

A few years ago the two memes of minimal viable product and lean product development were my favourites. There was this old-world, chronic problem of products getting stuck in product development until they reach “nirvana” – feature-itis, scope creep, etc. There was nothing more frustrating than sitting in a meeting where a product manager (with zero research or understanding) would state something like “we need to support groups, we absolutely can’t launch with out it or else it will be embarrassing”. So 18 months later product dev’t would complete, a few million would have been burnt and then we’d test it on the market and lo and behold nobody cared about that feature. Expensive. We can call this the “Microsoft Excel” product development methodology.

Why Lean Product Development Evolved... copyright Phil Gwinn

Now I am seeing the opposite problem. Startups are launching crap under the excuse of “testing the market”. I think as a collective group we need to come together and put down a firm set of launch requirements:

1. Crashing should not be a launch feature. Please stress your stuff.

2. Whatever your apps core purpose is, it should do it fast. i.e. you should do performance testing.

3. You should use real designers – it should be easy to use and be easy on the eye.

You should still aim for simplicity & a bare bone set of features, but your product must work and meet the expectation of a professional product. A great example of a company doing this well has been Kik. Their core messaging product worked, worked fast and looked great – was super simple but also had some well thought out viral hooks. They even survived eXtreme scaling!

An exception to MVP, I don’t think it would make a lot of sense to use MVP if you were attacking an existing industry. Sometimes you know the business model, you don’t need to test it out. And your product has to exceed the current bar of products out there. This, for instance, is why it was ridiculous for the Playbook to be missing major features (like email) at launch.

  1. I’m as averse to sports metaphor abuse as anyone, but the most apt one to apply here is about making it to first base; limit the scope to include only the features needed to demonstrate to users that you understand their basic needs, and indicate to them you will look to them to grow the product. Then you will have them at Hello World!

  2. Design, performance and general app integrity are definitely “ante” nowadays. In other words, I don’t think its possible to launch MVP, without some relative-thought and effort given to checking those three boxes. The level of effort will of course be generally determined by scale, but even the earliest stage idea can’t forgo these three things nowadays.

Comments are closed.

Webmentions

  • Three Insights Gained To Help Connect The Dots April 29, 2011

    […] Scrappy should not be confused with crappy.  Design, UX, and UI is super […]

  • Why The Rush? « Thoughts from Geoff Kratz @ FarWest Software April 29, 2011

    […] broken software that is in production too long, which in turn causes customers to look elsewhere. An interesting post on StartupNorth discusses this in part, talking about the difference between releasing a product too soon (before […]