Recently, I had the opportunity to review a project that had gone off the rails. The parties were the inventors (non-technical, co-founders) and the developer (a contracted entity.) The contract between the entities clearly laid out a set of deliverables that the developer would create based upon a somewhat flexible timeline. This project was all happening during the pandemic weirdness, which certainly did not help matters in terms of component availability or predictable shipping times.
At core, the contract described in detail a prototype consisting of hardware and software that could be used for a number of purposes including early user feedback and fund raising. The catch to this is, in the contract the deliverable was described as a minimum viable product (MVP) instead of using more accurate language of a functional prototype which would be used in the MVP process. According to Eric Reis in his book the Lean Startup, an MVP is an iterative process to allow the collection of feedback from user interaction to determine product/market fit using the least amount of resources possible.
Because the MVP language was conflated with the prototype in the contract, the inventors developed expectations that the output of the development process would be a fully baked, ready to ship to the masses, product. The developer viewed this as a functional prototype to integrate various features and functions envisioned by the inventors provided to the users to determine the modifications before true productization. In these divergent expectations, a conflict, that ultimately ended up in the legal system, was born.
The key difference between a prototype and an MVP is the infrastructure around user engagement and the capture of user feedback. Often, a prototype is used as the mechanism to allow the user to experience the concepts the inventor envisions. For example, when Zappos was conceived of, the key question was “would users feel comfortable purchasing shoes online when they couldn’t touch, feel, or try them on?” To answer that question, the founder created a simple web site with inventory from a local shoe shop. He promoted it and had users purchase shoes from the website. He would visit the local shoe store, buy the shoes in the correct size, and then ship them to the end user. Obviously, this MVP was not going to work long-term as a solution for selling shoes online, but it did provide a mechanism to expose users to the concept and collect the information needed to create what ultimately became Zappos.
In disputes like this, it is important to understand what was really committed to deliver vs. delivery expectations. When reviewing this particular statement of work, it became clear that what was contractually committed was the development and delivery of a functional prototype, not an MVP, despite the language used in the contract and the expectations of the inventors.
If you are a non-technical inventor, make sure that you truly understand the contract you are entering into with a contract developer. Not only in terms of what is being delivered, but how it will be used, expectations of quality, and what development might be required after the contract term.
If you are a contract developer, make sure your non-technical counter-part is not conflating concepts like MVP with prototype and that they clearly understand that getting a product from concept to market is a journey, and often not a straight and even path journey at that.
If you find yourself in the middle of a development dispute and would like to introduce a neutral, third-party view point, I’m happy to engage. Contact me today.