Creating a Minimum Viable Product is all about validation…
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.
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.
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.
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 Minumum Viable Product to validate our assumptions.