The team has worked hard, and milestones have been hit. It’s time to release, and a decision is made: do we call this done, or do we call it beta? I’m going to bundle all the betas together here, but it’s beta if any of these labels apply to the release: early adopter, limited access, preview, public preview, advance access, or a cutesy name referencing a select membership club. They all mean “this isn’t done.”
Why does a company release before it’s done?
This simple question has a really complicated set of answers. The biggest one is “marketing”. The intention is to signal to the market that your product is coming: it’s a press release with benefits. Where you were doing thought leadership and promises, you now have a product that users can access… but it’s not finished. It’s not ready to use yet, but it will be soon. The beta announcement is a starting flag to a market campaign built around a product capability that is strategically important to the company. That’s a coordinated outcome involving lots of parties who are working to pretty tight schedules. The most important of those schedules is the typical customer budgetary cycle, which is aligned with the typical conference schedule for your industry. There are dates where marketing efforts are expected to bear more fruit, and you might not be able to say “hold up, engineering needs another month to really get this right.”
The next biggest reason is to elicit product feedback. Potential customers of the product may try to use it, which would give the team a valuable source of bug reports (and usage data in the case of a cloud service). Every question asked by a potential customer is useful in this stage. What do they click, what do they read, what do they ask. Is the product aligning with the expectations set by marketing? Does the potential customer have needs and wants that the product might solve? Can they see where the product might help? This is all especially interesting when you can’t white glove their access to the product.
The third reason is hopefully really minor: internal signaling. The team is informing their field engineering colleagues that the real release is in sight, using a channel that can’t be ignored the way internal communications sometimes are. “Hey, this thing is going from internal blah-blah to a thing you’ll need to know, heads up.” A release drives internal enablement; a beta label explains why the docs aren’t ready and the UI is buggy and the features aren’t complete.
What do we hope for?
The ideal outcomes vary per each thread of intention. From a marketing perspective, the desired outcome is press and analyst interest. The announcement should have been floated weeks ahead of its actual date, there should be briefings and demos already under way, and the ideal outcome is an orchestrated wave of publicity saying “Company Is Doing Thing: Here’s Why That Matters”. Note that this process is the same for beta as it is for 1.0 release! However, you don’t really get to do it at the same scale again once the product is out. You might do a big 2.0 refresh, but there’s not as much interest in “Company Improves Thing”. Some marketing amplifiers are very trusting and do not care if the release is beta or not, but the other side of that coin is they won’t care that it’s improved either. Other market voices are very concerned with whether it really works, which leads to Company’s desire for product feedback.
Product feedback is a large desired outcome for a beta release. The goal of a product development process is to build what customers want. There are processes and frameworks for trying to do that. Sadly, the pool of customers and prospects that can make the time to help a vendor build a new thing is smaller than you’d think. Also, people can struggle to distinguish wants from needs, and communication is notoriously difficult to achieve. Releasing a product for a broader audience can produce real feedback: who tries it, what do they try to do with it, does it work, how does it perform, where does it fail.
Another exciting outcome is community technical awareness. When they do these tests, if these customers involve their field engineers and professional services partners, that’s potential to greatly amplify the signal of “new tech arriving”. Each sales engineer or service consultant has huge potential reach and influence, and their positive opinions on the product could provide a boost.
What might happen?
Positive outcomes are easy: everything the product team hopes for comes true. The beta is announced to great fanfare, prospects and customers storm the gates to use the preview, and their well-labeled and neatly organized feedback drives a small effort to solidly wrap the 1.0 we were planning to do anyway. High-fives all around, beer’s on us.
Less awesome outcomes can happen as well. The baseline of marketing outcome is that no one cares after all, or your news might be swamped by something bigger. Sometimes the zeitgeist turns on a dime and you need to respond to that instead of executing to your product marketing plan. Honestly, that’s probably good news with a beta release; you can wait for the real release and try again.
The product feedback angle is more worrisome. It’s certainly scary to get feedback indicating that your assumptions are wrong. Prospects use it exactly as you didn’t want them to. They can’t find the feature you were excited to see exercised. They hit it with mid-sized load and it falls over. These are the moments that all-nighters are born from. I’ve been on a lot of teams which spent Thanksgiving or Christmas working instead of with family, and beta product feedback has driven some of those experiences.
An even worse possible outcome is that no one tries it at all. Internal or external. “Hello? Is this thing on?” That can indicate a swing-and-miss in marketing, broken internal communications, or more… but the worst case scenario is that it’s telling you the product is mis-aimed. Maybe no one is trying it because no one actually wants it.
Let Me Explain. No, There is Too Much. Let Me Sum Up
There’s two reasons to do a beta instead of a generally available release: “we’re finishing it up shortly and it will be for sale ASAP”, or “this probably isn’t going to work and the people who were doing it are gone, odds are we’ll quietly delete it on the next major holiday weekend”.
Product development is chugging along but you’re up against a time wall and have to announce something because the conference is here and you bought a booth and let’s go go go. Call it a beta so you don’t disappoint too hard, and ship it.
Or, you’re sending up a trial balloon to see what happens — maybe this is a dumb idea, or maybe it’s the next big thing, and you just don’t know.
Then there’s the Apple way… Gruber thoughts.
Monkeynoodle.Org 