Cody Evol, a Director of Product Design at Eventbrite, helped develop one of our more useful frameworks to help us understand how much time we devote to a project. When I joined Eventbrite almost two years ago, every team was describing their project as an MVP, which is quite strange, as the Minimum Viable Product framework was built for launching new products, which is not what most teams were doing.
Product teams using inappropriate frameworks off the internet to justify their approach? Inconceivable!
The key thesis of Cody’s design quality framework is that the level of investment before something reaches a customer is tied to how confident we are that we understand both the problem and viability of the solution.
Your development approach should change based on how ambiguous the problem and ideal solution are.
When there is a lot of ambiguity about the problem or the solution, we should generally try to de-risk the project before investing a lot of time into it by using the approaches above. And we have many tools at our disposal to do this. With enough validation, teams should invest in building minimum viable products or features. Minimum viable product is probably the best known product development framework outside of perhaps Agile. It is about delivering value to users by building the smallest product you can to test your hypothesis. You ship to learn, which influences future product development. However, most things we build aren’t minimum viable products. It’s a product development framework for brand new products, and we rarely build brand new products. More likely, we are building features. These can be even more lightweight because you are building something on top of an existing product (you can think of a product as a bundle of features). The “Follow This Creator” feature was a great example of a minimum viable feature on the consumer side of our product. We didn’t know if consumers would adopt it, so we launched it just on Android without even building the push notification functionality. As we saw consumers adopt it, we built it for iOS and web and with email and push functionality.
The goal is usually to reduce the ambiguity around the product problem and solution so that you are not building an MVP/MVF, but instead doing phased delivery. This is a type of development where you have a strong vision and the problem and solution are validated, so the goal is to build toward that desired vision, and release incrementally as valuable pieces of that vision are complete.
MVP’s and MVF’s are to prove that our ideas actually solve a problem. If we prove that, we typically need to invest a lot more to reach the potential of the product or feature idea. Rarely do MVP’s or MVF’s crush expectations out the gate.