Day 56 — Demystify series 4/7: “PoC, Beta, MVP”

Photo by Tim Mossholder on Unsplash

What’s the difference between MVP and Beta release? Why do we need a POC (proof of concept)? In this article, I’m going to share my experience working with different product release strategy for different reasons. Here’s the considerations to determine the releasing strategy:

• Definition & Differences
• General Rules
• Contextual Factors: When to Choose What

Definition & Differences

• Proof of Concept (PoC): a smaller project used to quickly verify certain assumptions before going to actual design and development cycle of the real product.
• Alpha release: The first product release, an untested product with incomplete or partial-complete features set. The name comes from Greek language, for alpha is the first letter in Greek.
• Beta release: Following the same naming convention as Alpha, Beta release is the second release of the product. In beta release, the product team has fixed those bugs and issues discovered from alpha release.
• Minimum Viable Product (MVP): a concept coined by Eric Reis, from his best seller book The Lean Startup. MVP is also the first product release, with the minimum feature set that is assumed to be sufficient to appeal to early adopters (hence the word “viable”).

Photo by You X Ventures on Unsplash

The Differences

• Purpose: PoC is used to either test the tech feasibility of a concept, or to gather stakeholder feedback in order to see if the concept can be transformed into a real product. Alpha release is aimed to quickly put out the product to test the core features with users. Beta release is used to see after the bug fixes from alpha release, is there any other critical issues that need to be resolved before the official release. MVP is similar to alpha or beta release, but integrating the business case verification and product strategy into the release planning.
• Target Audience: PoC is often used internally to get feedback with stakeholders. Alpha & beta release is often tested with users that have better tolerance on bugs & issues; for example, early adopter, client with close relationship, etc. MVP is often release to the broad audience to verify the product assumption, in both business and design aspects.

Find the right audience to provide the types of feedback we need. Photo by Nicholas Green on Unsplash

General Rules

No matter which one we choose for our releasing strategy, all these release plan share some common rules for us to follow:

• The “What”: What are we trying to validate? The answer of this question can help us determine what kind of release plan we should choose. For example, if you want to know if the technology at hand is sufficient to support the concept, a quick PoC can be done with shorter time frame and lower cost. On the other hand, if you want to know if the business model of the new product is viable, an MVP might be a better choice for you.
• The “Who”: Who are you testing with this method? For example, if we’d like to know if the concept appeals to senior leadership for support or funding, a quick PoC is the way to go. But if we need to see if the targeted early adopter would like our idea, an MVP is needed to get that answer.
• The “How”: The most important thing of these release strategy is the learning. How well we can get the feedback usually determines how successful our release strategy is. It’s probably easy to get internal feedback by setting up some meeting and demoing our PoC. However, effectively gathering feedback of an MVP is a totally different story. Are we trying to understand the business model viability, or the product usability? The approach of data gathering could largely vary depends on what we’re trying to verify.

Design thought leader Jared Spool on learning vs. failing. Image source: Twitter

Contextual Factors: When to Choose What

• Process ROI: As described above, different release strategies have their own merit depending on what you’re trying to achieve. Except for thinking about the “who, what, and how”, another perspective to consider is how much investment required of each method in order to get the benefit. The investment is usually associated with men hours, equipment, other contracting cost, etc. Therefore, cost can be estimated with the understanding of the size of the audience, deploying method (automatic with existing platform vs. bespoke approach), testing time frame, etc.
• Project Risk: Depending on the risk appetite of the stakeholders, we can craft our release strategy to hedge the project risk. If the project is associated with hundreds of millions of dollars, we might want to go through more testing and feedback loop before the official release. If the project is in a highly-regulated industry, where legal & compliance risk is usually higher, involving subject matter expert in the testing phase is crucial, and internal testing first might help lower the risk.

Photo by David Travis on Unsplash

• Product Type: Lots of open source software do alpha release with the public, so that they can get more people to test it and gather large amount of feedback. On the other hand, most of the proprietary software utilize internal alpha release. Take Gmail for example, Google did an alpha release only to Google staff as an internal product. Later, in 2004, Gmail did a invitation-only beta release with public, and then in 2007 they rolled out to the general public.
• Organizational Culture: For startup, the business model of a product is strongly tied to the organization viability. Therefore, the earlier they can get feedback from users the better. On the other side of the spectrum, in a large, hierarchical organization, where command and control is the dominant style of management, getting required internal sign off sometimes is crucial for project success. In that case, a quick PoC which takes shorter time to implement with lower risk might be a good idea before full-speed charging to the real product.

Conclusion

1. Understanding the pros & cons of each release strategy helps us get the right feedback at the right time.
2. Apply general rules: who is the target audience for validation? what do we want to validate? how to get that data?
3. Contextual factors matter. Consider the method ROI and project risk to better craft the release strategy.

How do you determine your release strategy? Any experience or tips you’d like to share? I’d love to learn from you.

ABC. Always be clappin’.

To see more

All Daily Agile UX tips

Day 55 — Demystify series 3/7: “Intuitive, Easy to Use, Easy to Learn”

Day 54 — Demystify series 2/7: “Creative, Artistic, Innovative”

The opinions expressed in this article are those of the author. They do not represent current or previous client or employer views.