What happens when you want to give users access to a feature before it’s finalized? How do you set expectations and attract the type of users that want to be at the cutting edge?
AI is letting teams ship faster. Meaningfully faster. But how do you avoid overwhelming your users with a never-ending deluge of features or a feeling that the product experience is constantly shifting under their feet..?
The answer isn’t a disclaimer buried in a changelog or a lengthy beta program workflow of emails, spreadsheets, and invitations (at least not for those of us that can avoid that suffering). It’s a consistent, communicated framework for conveying when a feature isn’t fully cooked and the discipline to consistently apply it every time. This sets user expectations and leaves them assured that unlabeled features can be fully relied on.
If you’re at the point where you’re shipping an overwhelming number of features, you might want to consider giving users the option to opt-out or otherwise control which level of features do and don’t show up in the product.
Why this matters more now
Traditional software shipped slowly enough that most features arriving at users were, at minimum, fully intentioned. Experimental work happened behind the scenes. With AI-assisted development, the gap between “this is interesting” and “this is live” has collapsed. The opportunity to validate a feature by shipping it is very real and enticing! But you don’t want users to go in with the wrong expectations that color their perception of your product’s quality.
Without a shared vocabulary, every rough edge creates the same question: “Is this broken, or is this just new?” Users shouldn’t have to guess. You shouldn’t make them.
The framework
Not every feature needs to pass through every stage. Move features forward when they’re ready, skip stages when you don’t need them. The point isn’t to add process and slow things down, it’s just simple communication about what a user is actually stepping into.
Keep in mind that you can choose to have each of these be either “private” or “public”. You could choose to make certain levels always one or the other, or you might have both categories. A public pre-release feature means basically any user can try it, and a private pre-release feature is either only available by application or invite.
You may also consider “internal-only” for situations where you can dogfood your features (or ‘drink your own champagne’ as I prefer to describe it).
Experimental
Ship these features with care and thorough expectation setting. This label means: might not work, might change completely, might disappear without notice. It’s a more like a warning than “you might run into a bug if you’re unlucky”. Reserve it for things you’re putting out to learn, not to deliver. Users who engage with experimental features are doing you a favor – treat that accordingly. Be sure to have a learning plan for these features. Write it down.
Alpha
Same caveats as experimental, but you’re more committed to a path. Alpha says: we’re probably going to build this, we just don’t know exactly when it will be done and what exactly it will look like. Expect change. Expect things to break. Expect to be asked what you think. Personally I would use this sparingly and only really use it for very large changes that you want to ease into.
Beta
This is where the bar rises. Beta means the feature should work as expected in the main case. Edge cases may not be smoothly handled. The user flow might still evolve – friction points you haven’t identified yet, labeling that isn’t quite right, steps that could be collapsed. But the core behavior is intentional and expected to persist. You generally want to have a decent idea of when the feature will become GA.
Early access
Early access is essentially “this is the feature.” You’re confident in what it is and that it’s becoming GA. The rough edges are more likely to be in documentation, training, or rollout coverage than in the feature itself. It’s the manual that’s lacking, not the product. This is often mostly about encouraging adoption by users that like new things and can figure things out on their own.
Communicate the framework
You can have a perfect internal taxonomy and still confuse your users. Most people have a working model of what “beta” means – but “experimental” means different things to different people, and “early access” gets used so loosely by so many products that it barely signals anything anymore.
The implication: label the feature, and explain the label. Progressive disclosure is your friend here. Make it easy to learn what the term means in the level of detail they need to feel comfortable. Try to provide a one-liner for those who don’t need a half-pager or already read it.
This is especially true the first time you ship something in a new stage. If your users haven’t seen “experimental” from you before, that label means nothing until you define it. Define it.
Expecting feedback
Feedback is generally a top 2 goal of pre-releasing a feature. Make sure you ask for it and make it easy to provide!
Every non-GA label is also an implicit invitation. Users who engage with something early are disproportionately motivated – they want the thing to work, they have opinions, and they’ll tell you if you ask. Don’t waste that.
Be direct about what you want to hear. “We’re particularly curious whether this works in [specific context]” gets you much more useful signal than a generic “let us know what you think.” The earlier the stage, the more directed your ask should be – experimental features need directional feedback, beta features need friction reports, early access features need the edge cases you haven’t seen yet.
The title is the commitment
Whatever label you attach, you’ve made a promise about what kind of thing this is. Experimental means you might pull it. Beta means you’ve committed to the direction. Early access means it’s coming – get excited.
Hold yourself to that. Don’t label something early access and then sunset it without a compelling reason. Don’t ship something as beta if it’s actually experimental and you know it. The vocabulary only works if the vocabulary means something.
And when things change – when an experimental feature gets pulled, or a beta evolves significantly – tell users. (Aside: this means you need to be tracking who uses it). They made a choice to use something non-GA. They’ll greatly appreciate a heads up when the thing changes.