linkedin tracking
icon-sprite Created with Sketch.
Skip to main content
Beta versus MVP May 27, 2020
Design

Beta versus MVP

reading time
Photo of George White

Written by

George White

Share this article

This post was developed from an original George White (CIO, Cantina) / @Stonehippo Twitter thread. Its insights begged to be shared with a broader audience. So, here they are in long form.)

This is a story about product development, what we name things, and how it shapes what we are doing.

A friend of mine recently asked me if his startup should call their upcoming first release an MVP (minimum viable product) or a Beta, which is a test vehicle for making sure that your product isn’t too buggy and has features people can use. An MVP is a complete product, a Beta is a milestone release.

My short answer to them: “Has anyone ever bought your thing?”

My short answer to them: “Has anyone ever bought your thing?”

First: I dislike the term MVP. It’s not rigorous and often misapplied. So, here is how I determine what label to put on a first release:

  • I think about a rough framework of Desirable-Feasible-Viable (do people want it, can we build it, can it be a sustainable business), as most things released as MVPs are unproven or shaky.
  • I consider whether the producer of a supposed MVP knows if it contains the minimum features for viability, since no one has paid* them for it.

* Yes, I’m focusing on dollars here. You could argue that “adoption” is a proxy for buying, but I disagree, if it’s product or service.

For me, the answer to my friend’s question about naming that initial release boils down to this:

  • Beta = a test release of the minimum number of features needed to prove viability
  • MVP = a minimum number of features that actually sells, i.e. is possibly viable

This leads me to a side note: a Beta is not for proving Desirability! If you got to Beta without doing research and some form of co-creation or prototyping with potential buyers and users, you skipped past the elements that would help prove Desirability, and probably started building too soon.

A venn diagram of Desirable-Feasible-Viable, showing how they overlap equally, with Cantina logo in lower right.

Which leads me to another point: ideally, you are only testing one aspect of Desirable-Feasible-Viable at a time (for example, during development, you might need to do proof-of-concept work to show that you can build the thing, i.e. demonstrate Feasibility). If you’re testing multiple things at once, it might be hard to untangle what you learn from the results.

At the end of the day, I advised my friend to call his release a Beta, and not an MVP. At this stage, they have a minimum set of features that they suppose might be viable, but haven’t yet proven.

Summary

If no one has paid you anything for it yet, it’s not an MVP.

Do you lead your organization’s innovation strategy?

Cantina wants to hear from you. As a strategic design and development consultancy, we work with companies at all stages of growth to define their strategy for continued innovation and market differentiation through optimization of customer experiences. Drop us a line if you’re interested in starting a conversation about showing the value of prototyping, innovating, and ideating.

Insights

Contact us

Talk with our experts today

Tell us how you need help. We’ll be in touch.

Thank you! Your message has been sent!

We’ll be in touch.

Want to know more about Cantina? Check out our latest insights or join us at one of our upcoming events.