MVP's: The Real Deal

We all know how it goes: An idea strikes our mind, and before we notice, hands are already on our keyboard, our favourite IDE wide open, (luckily a bit of brainstorming) and a product is born.

Yeah yeah, we all know we should hold the horses and make some state-of-the-art research. With ease we talk ourselves into believing that most of it sucks (compared with the product in our minds). We can do it way better, and everyone will love it, because everyone needs it. Code-blocks on it!

Some hard-work and long-night weeks go by, and now we have our first MVP, our minimal viable product, something to show to our early-adopters and check what happens. It may not be definitive, but hey! this is Agile, we are doing Iterative-incremental development here!

This is the moment where fantasy starts to fall apart. Our early-adopters do not adopt it as much as we wished. We realize our solution may not be as compelling as we thought, or maybe the customer pain we were trying to relieve was not as significant as we originally thought. User feedback indicates it’s time to pivot, make a value-proposition switch, maybe change our entire business model, hence most of what we have been (luckily just) coding.

As a both freelance and enterprise developer, as well as novice entrepreneur, I have seen (and experienced) this scenario countless times, across a wide project-scale spectrum. And I have to admit, until some months ago, this was the moment when I felt kind of relieved and said “Oh god, good thing I got this information at such an early stage. This saved me tons of resources and wasted effort”.

But what about this: Was there any way I could have saved more resources and avoided even this wasted effort?

By all means, the answer is Yes. But be aware fearless reader! You will have to dig into some dark zones.

• Do you imagine letting prospective users interact with a paper version of your product and ask someone to click a “link” on a paper with their index finger?
• Do you conceive testing the market response to an AI based solution without any real AI implementation but manual work instead?
• What about spending some of your scarce budget on customer profiling before ANY coding?

Scary, I know.

The purpose of this article is to get right what most of us got wrong in the first place about MVPs: An MVP it's something that only exists in order to help us learn about our customers and their behaviour.
This hides the fact that an MVP may not even be an iteration of our product, just an "experiment" designed for discovery purposes. And this is, for most of us, a quite uncomfortable idea. Our comfort-zone relies on the build -> deliver flow, and anything else feels just upside-down. At least at the beginning.

Remember your early days with TDD? When you were not yet test-infected? You may remember that first awkwardness of coding the what prior to the how. You may remember it, but now TDD has become second nature to you and anything else probably feels kind of blind-walking, right?

Well, now think about an mvp-infected state, where any feature you choose to build, has an mvp-guided customer-side validation that ensures there is a value for your customers behind it.... What a sweet road to walk through!

Some advice though: be as sure as you can of what you are hoping to measure (learn) with an MVP. Or leastwise, keep firmly in mind what you are NOT trying to validate. As said, our unconscious will struggle to find external approval (comfort) in every aspect it can, and deviate our attention from the specific purpose of the MVP.

There are lots of known ways to achieve this, we all know (or should) books like The Lean Startup (Eric Ries) and The Art of the Start (Guy Kawasaki), two great books that bring a warehouse of real-life examples of successful MVP’s. However there is no proven methodology behind MVP’s and the best way to answer your specific market questions will probably emerge from creativity and some lateral thinking.

However, just so you can take some real example out of this article, I will share some pictures of a successful MVP user testing session conducted for a project I was part of. Potential users were presented a “wireframed” version of a web application in plain paper, and they were asked to perform specific tasks on it, using their hands as mouses, to finally get their feedback.

This was a highly rewarding experience and you would probably be surprised to see how involved users became and how much information we collected, from both their words and their behaviour.

Great MVP’s are born from deeply understanding how little we know about our customers and how crucial this is for the success of our venture.

Good luck getting to know your customer!

P.S. If you are comfortable with spanish, take a look at this post, wich gives a highly interesting approach of lean principles applied to the sales process.