Alpha, Beta, POC or MVP: what does it matter?

If you work in product or technology, the chances are very few people can describe exactly what it is that you do.

We work in a happy techy echo chamber, referring to Alphas and Betas, post-itting our bets, pointing at our vision and saying things like ‘delight’ a lot. Someone told me recently that he was looking into a “headless sandbox”. Picture that…

With jargon like this, it’s little wonder there’s confusion in the technology space when we make it so unintelligible. So when we say Alpha, Beta, MVP and POC, what exactly do we mean?

I asked our hive mind on Slack for their thoughts on MVP vs Proof of Concept vs Alpha/Beta release, along with their opinions on definitions and differences. Even amongst colleagues working in digital product, it prompted some pretty interesting responses:

“Not much…although Alpha and Beta are further developed”

“Concept testing is free from constraints and could be any idea, or as a result from many divergent ideas ... I'd say concept testing is a thingy...”

“PoC gives theoretical ground to an idea of a solution or a particular function. Meanwhile, MVP implements the features designed at the stages of the PoC and prototype””

“PoC is distinguishable; other phases overlap. MVP can be a subset of Alpha/Beta…right?”

Whilst the experiences of ‘our acronyms’ varies, one thing is clear: we we need to get over the obscurity in jargon. The following will explain these acronyms and how to use them. With zero buzz words. Let’s get going.

But first…

Why are we working in this iterative way in the first place?

Because a large percentage of digital projects fail (60% in year 1, 90% by year 5). Investing everything in an idea and hoping it works is a gamble. To reduce the size of your potential loss, you want to be as confident as possible that the product will be a success, with the minimal amount of resources and effort expended, before fully launching it into the world.

Iterative design and validation is your insurance process, reducing the size of the gamble and de-risking in chunks. Typically, our group of acronyms are tools that can be used as part of that insurance process.

So what comes first, the CHKN or the E-G-G?

No matter how many diagrams we draw, creating products isn’t a straightforward sequence of steps. Alpha naturally comes before Beta, until you launch your ‘Beta’. Then your users think the Beta is horrible, and you’re back to producing Proof of Concepts again.

Forget: Design, test, build, release, win.

Remember: Research, test, adjust, kill it, redesign, build, bin most of it, research, design, build test, jackpot.

With this in mind, we can use our tools to test and offset different types of risks across the product lifecycle, at differing degrees of stability and confidence.

Proof of Concept: “Is this a good idea…?”

It’s in the name, “concept”. You’ve done your research, defined a problem to solve, and have a bright idea on how to do it. It doesn’t have to be sustainable or fully functional at this stage; it might look like a theoretical demo of a product or process, or a written proposition with some pictures and arrows.

You don’t know the best practice for producing it, or how much of the market will want it, but you’re determining if your idea is worth pursuing and what might be technically needed to make it real. It’s why PoC’s can be useful things to demo to investors or bosses to understand if the idea is worth backing.

MVP: “Mars Rover”

Your Mars rover, out there in the product galaxy looking for signs of life. It tests whether your idea will deliver value to real people. It might be a small part of your huge vision for global success, but it’s a stable, functioning, version of your product which your users are willing to pay for (or maybe not, you’re about to find out).

Your MVP answers more design and technical questions than your PoC, but its main goal is to test your big bet and prove there’s a market for it.

Take Dropbox. Their MVP 1 was a video. Creating a fully functioning product would have required some immense technical hurdles. So, in the spirit of offsetting maximum risk with the smallest effort, they created a 3 minute demo video and shared to potential early adopters, to see if it was worth doing.

It validated the idea in a way that wasn’t people saying they didn’t like it in a focus group. They actually signed up for it: 5,000 people on the Beta waiting list leapt to 75,000.

The main objective of an MVP is to validate the idea in the market, quickly. But Dropbox didn’t stay as a video. Rarely would a product have a single version of an MVP before full production. The MVP is developed over time into different guises, sizes, and states of stability.

Alpha/Beta can be used as milestone versions for the MVP. They refer to the type of risk, or stability of the tests that you’re putting out into the world.

Alpha: “How do you turn this thing on?”

An Alpha release is where ideas meet engineering, a version of your MVP supported by code thus increasing it’s ‘stability’. It’s the space to test out different solutions to business and user problems, and explore new approaches that challenge the way things are done right now.

This might be the minimum amount of functionality to take the product to market to test with 1000 users; you don’t have to prototype all of the features and functionality. Often it makes sense just to focus on the areas you think will be most challenging to create and explain. Remember, you’re doing the minimum you need to test your riskiest assumptions.

By the close of Alpha, expect to find issues, and throw away code along with lots of the ideas you’ve tested. With a bit of luck, you’ve found something worth taking forward.

Beta: “What’s working, what next?”

Your Beta should be a version of the MVP that’s functional, having smoothed out many initial issues from Alpha (if you did one). It’s useful; your users should anticipate paying for it, but it isn’t on general release as future versions are expected before it’s a sustainable product.

Beta’s been used in recent years to justify a less-than-perfect experience of a product, or as a tactic to generate excitement and exclusivity around a product or feature. But to get value out of a Beta launch, you need to have a clear idea of what you’re wanting to test and learn.

Gmail rather famously remained in Beta for years: after an initial Alpha release to internal Google staff, Beta was launched in 2004 first to a by-invitation-only group, before steadily expanding out to groups within the general public. ‘Beta’ only ended in 2007.

The common theme

Think less of this: “What stage am I at in a process.”

And more of this: “What type of risk am I facing? How confident am I in this idea, and how stable is the idea I’m trying to bring to life?”

Think differently about those definitions

These aren’t pre-defined steps in a release strategy to market domination. Whether you use Alpha, Beta, MVP a PoC or none of the above, will depend on the risk that you’re trying to address.

• Who is the audience?

• What answers do we need?

• How will we collect data to validate this?

Once you’ve decided this, you might then consider ROI, your culture, or the type of product itself before picking your poison, much like Dropbox did.

All four act as gateways to reduce risk and sunk-cost bias: that is, the tendency to continue on a path if you've already invested time, effort, and money into it, even if the current costs outweigh the benefits.

Often when you’re making something brand new, there’s no way to definitively prove people will like it. You have to ship it - put it out into the world - to internal users, forgiving customers, or the mass market to test for value, at different levels of confidence and stability.

Call it what you want, but if the purpose and outcome of the release cannot be aligned on, it probably shouldn’t happen at all.