A Solution Looking for a Problem: The Wrong Way to Build a MVP

Written by Adrian Cunanan

March 11, 2018

Creating a Minimum Viable Product is all about validation…

IN PRODUCT DEVELOPMENT, THE MINIMUM VIABLE PRODUCT (MVP) IS A PRODUCT WITH JUST ENOUGH FEATURES TO GATHER VALIDATED LEARNING ABOUT THE PRODUCT AND ITS CONTINUED DEVELOPMENT.

At ThriveStreams, this is one of the main challenges that we dealt with. After our first product failed to ship because of feature-itis, we decided to work on a product that we could ship fast. We decided on a customer segment to service because of our own personal experience with overcoming mental health challenges.

 

Mistake 1: Build a solution looking for a problem

In the beginning, we began designing a better mental health tracker and called it ThriveSync. We went straight into development with what we thought was an MVP because it only had two features. We overestimated our ability to ship the product in one two week sprint. It actually ended up taking 3 months working part time.

We released the product with great media coverage (including TechCrunch and CNET). Feedback led us to believe that there was an opportunity to provide value to mental health providers and their patients.

Mistake 2: Continue to build without validation of the customer problem

 

We then began to develop a dashboard for mental health providers to access their patients’ mood data. Our unique value proposition was that we would help providers to decrease the number of hospital readmissions with a remote patient monitoring platform.

We did not test our assumption that this was even a problem for mental health providers and that it was painful enough for them to pay for the solution.

Mistake 3: Going straight to our code editors to test our assumptions

We consistently made the mistake of going straight to code after we designed what we thought was a solution to a problem we had not validated. We should have known better when it took us three months to rebuild our platform to be HIPAA compliant.

 

ThriveSync = 3 Months of Development

This was a very expensive effort that we thought was the correct approach and we had already committed to building this solution to be tested for a research study funded by the National Institutes of Health.

Lesson Learned: NO CODING WITHOUT VALIDATION OF A TRUE PROBLEM!

 

Code is expensive resource-wise in terms of time and money.

It wasn’t until our acceptance into the Blueprint Health accelerator program that we finally learned how to build a true MVP. We tightened our Build > Meaure > Learn cycle to fit into a 2-week sprint. We brainstormed a collection of customer segments, picked one to test, made an assumption about their problems, and then went out to test our assumptions.

We would go into customer meetings with a sales deck that included a screenshot of our proposed solution. We only showed them this slide at the end of the presentation after we had the opportunity to discover their true challenges in a conversational manner.

ThriveStream (Passive Tracker): Lines of Code = 0

Every sprint ended in an evaluation of the data we collected and a decision to pivot or persevere.

In the end, after 3 experiments we were able to identify a problem for employers. Employees facing mental health challenges increased the cost of providing health care and productivity would decrease due to both absenteeism and presenteeism.

Thrive.ai (AI Digital Mental Health Companion): Lines of Code = 0

Unfortunately, by the time we found a problem we did not have enough financial runway to go to our code editors and develop the Minimal Viable Product with code.

We share this lesson as our real-world experience of how we learned to make a true Minimum Viable Product to validate our assumptions.

Related Articles

Start With Why

Start With Why

We failed… I started a company in 2012. The company set out to revolutionize behavioral healthcare. Closed the company in 2016. This is my attempt to document and pass on my learnings along the way. My experience spans a range including Entrepreneurship/Product...

On Communication – Part 3

On Communication – Part 3

Part 3: The Science From: https://hbr.org/2016/07/what-great-listeners-actually-do Of course, there are different levels of listening. Not every conversation requires the highest levels of listening, but many conversations would benefit from greater focus and...