A minimum viable product, or MVP, is a project framework that provides the largest return of knowledge on the least amount of effort. By creating an MVP, teams are able to start the feedback loop early and prove concept success to stakeholders. With an MVP, teams learn at every step of the process how to create a better, more sustainable product.
MVP as a Learning Tool
You’ve got a new team or a new project idea and a tentative budget approved. You’ve also got a deadline from business to prove that this thing is going to work. The least amount of features you can deliver as proof is your MVP. This first launch date, release cycle, or beta version establishes the baseline for return on investment (ROI). Completing an MVP can be a fruitful way to teach business leadership their money is being funneled to the right channels.
We already encourage short feedback loops in our build pipelines, so why wouldn’t we want that for our products too? For example, usability testing can happen on an MVP rather than waiting until the application is fully featured and several sprints worth of completed work down a potentially bad path. Creating an MVP is an excellent device for feedback, as it provides teams with an early tool for learning the needs of their users.
Shipping a minimal-featured but useful product to users provides a path for early adopters to start generating revenue as the team scales. Building an MVP can also provide an organization with an opportunity to capitalize on first-mover advantage, being an early product in an emergent market. Both of these things are ways an MVP can turn directly into profit—the most likely ROI metric business stakeholders care about.
It’s important to get something launched as soon as possible: for ROI metrics, for feedback, or even for profit in some cases.
Select Features By What They Can Teach You
The hardest part of creating an MVP is identifying what to cut. If you’ve ever played the collectible card game Magic: The Gathering—like I’ve been for the past few decades—you’ll know one of the best parts of the game is building a new deck. In the popular Commander (EDH) format, a deck is limited to exactly 100 cards. It takes me only 10-15 minutes to throw together an oversized deck with good synergy, but the process to make cuts down to the perfect 100-card deck takes infinitely longer. I agonize over which creatures to keep (the cute cat or the regal bear), which spells work better (Fireball or Titanic Growth), and exactly how many lands I can remove and still have a viable deck (hint: none.) Similarly, it is often more difficult to limit the scope of an MVP project than it is to identify your initial project plan.
One way to decide on “cuts”—or reducing the scope of your MVP—is to ask yourself, “what do we learn from completing this task?” Each piece of an MVP is paid for with limited time and resources and therefore the ROI of each feature should be high. If the goal of an MVP is to learn, then each feature should teach. Reduce scope first with things that don’t provide answers to lingering questions.
An MVP Provides Answers to Lingering Questions
Recently I worked with a four billion dollar manufacturing company that wanted to develop a documentation site as a “single source of truth” for their design system as well as implement several visual updates to the components in that system. These tasks are a huge undertaking, and we wanted to ensure we presented as accurate an estimate as possible to this client for the effort it would take our team long-term.
We decided on a minuscule proof of concept for our MVP. We updated one singular component in their system (and not a complex one at that!) We moved this component through the entire design and development cycle—migrating the component specifications to Figma, implementing accessibility and testing best practices, and refactoring several files worth of outdated SCSS. Overall it took our team roughly 20 hours to complete. We learned a lot about the system, which features will need the most attention, what type of content will be needed for the documentation site, and most importantly how to estimate the rest of the work.
On a small scale, shipping a tiny MVP provides valuable information about the velocity and cost of completing work. A proof of concept provides significant details needed for making wise decisions about future work.
Showing Business Impact
Several years ago I worked with a similar team with a much larger budget. We were building a multi-brand design system from scratch for a top global retail and ecommerce website. This team had the budget to keep a designer and several developers busy for the better part of a fiscal year, but they had to prove a strong ROI to business leadership to keep it funded beyond that.
Many times a design system team wants to start with the basics: colors, typography, iconography, spacing, layout, buttons (always buttons.) It makes sense from a design perspective, as those foundations are the tools we start with when creating a new page template.
On this particular project, however, the pages were already built. It was more important to our team that we shipped something that the users wanted to implement immediately. Luckily, our team lead was a brilliant UX Designer who knew how to satisfy both business and users. We interviewed the product teams and looked for pain points in their current work. Then, our beta version of the design system aimed to solve a few of them. To entice developers, we shipped an early version of the design system with better, easy-to-use modal components. To awe designers, we developed a path to quickly and easily change the font for an entire brand’s website. Once the devs and designers were on board, business leadership wasn’t far behind.
On a large scale, shipping an MVP is an effective tool for showing leadership that your ideas, efforts, or teams are worth investing in.
MVP for Sustainable Products Conclusion
By creating a minimum viable product (MVP), teams can learn valuable insights about their product, their users, and the potential return on their investments. MVPs can work at both a small and a large scale, for enterprise-size organizations or new-to-market start-ups. Next time your team is looking to begin a new effort, try defining an MVP.
If you’d like to learn more about how Sparkbox develops MVPs with teams, check out other articles on this topic or drop us a line.