• product
• development
• engineering
• prototype

Every scipreneur will come across the idea of building an MVP. However, it may be one of the most misunderstood concepts when it comes to innovative and deeply technological solutions.

The idea of focusing on an MVP was popularized by the introduction of Lean methodologies to the startup world. We can focus on defining the minimum amount of work we need to perform to validate our value proposition. Once we know what customers see as valuable, we can translate the requirements as the minimum set of features we have to include to get a customer to buy our product.

The challenge stems from thinking the MVP has to be a Product instead of a Prototype.

Trainings online, even workshops at incubators, use examples that are all over the place when it comes to quality. Many use Dropbox's early days, when they were only a landing page with a form to sign up. As much as I like that approach, what they did was validate the value proposition, but there was nothing built: no prototype, much less a product or a company.

When I started developing the first MVP at Dispertech I was induced into believing what I was building had to be ready to be sold. It should be minimal, but it should also be a product. That approach created a lot of cognitive dissonances.

On the one hand, I spent a lot of time trying to make some automations, indicating LED's, keeping the size small.

However, our value proposition was focused on the type of data we could generate and its reproducibility.

Testing my assumptions didn't require a full-fledged system that could be operated by people without training. I believe now, in retrospect, I could have tested many more ideas and triggered many more discussions if I would have spent less time building, and more time focused on what really mattered: defining which features would make a difference to our customers.

I learned my lesson. The second time I had to develop an MVP (nicknamed nanoQNT) I approached the process in a very different way.

Since I knew the customer segment quite well, I could validate the value proposition rather quickly, just by talking to people and before committing to building anything.

The next step was to validate our tech. In this particular example we were not spinning out an idea from a lab, so we had to perform a bit more of legwork to see if our approach would actually work. Once we did, I leveraged an open-hardware project, the OpenSPIM, to build a functional prototype.

This time around, instead of optimizing suppliers, finding the best deals, and limiting the preemptively the degrees of freedom, I decided to move the other way around. By having a prototype we could modify almost on the fly, we could very quickly test the impact of different features. Which ones were being appreciated and used, which ones were required but not used, etc.

The experience was radically different. The MVP was ready in a matter of months, and tests with external users began immediately.

Sure, it was something we were not confident to sell, but allowed us to hone into the specifics that would make a difference before committing to them.

And we learned a lot. We learned that people are willing to put the extra effort to use poorly designed software if the data is worth it. We learned that even if there was a lot of manual work involved, being able to prepare samples in parallel and then measure one by one was good enough. And just like with Apple, people didn't care as much about what was inside our box as they cared about the results and their interpretation.

It was clear, we had enough input to move forward into the product phase of the MVP.