Benefits of Beta Programs & Early Feedback
Est Reading Time: 7 min
Oct 28, 2020
Publishing prereleases serve as a dress rehearsal for the formal release. Deploying prereleases helps your entire organization as well as the third parties that integrate with your solution. That is why when releasing software, many teams beta bug fixes, enhancements, and feature additions before rolling out a formal release.
Using this release can be worth the risk to many stakeholders, such as power users or developers. It provides early access to advanced features to start benefiting from new improvements and share their experiences. Simultaneously, you close the feedback loop and optimize the changes before rolling it out to the broader user base. That's why so many leading technology teams provide prereleases.
Granting early access to new features is a win-win for both you and your users. Normally the segments of people we see using prereleases fall into one of the following groups:
Each of these segments provides unique value to your early access program. Passionate product users, users with resolved issues, and early adopters of new features provide feedback purely through using your release. Their usage allows you to:
In addition to passive feedback, these users may also provide active feedback such as questions, comments, and reviews. This feedback can help you:
In addition to your users, developers, and third party integrators who integrate with your system tend to give active feedback if they subscribe to your prereleases. They can provide similar value to your team as users but tend to do so at a more technical level, helping to test out APIs, SDKs, and other integration points. By following their usage patterns, you can evaluate interest in services you expose and optimize documentation to make it easier for others to use your latest changes.
Active feedback from users and integrators gives you the ability to market features with a strong positive response. Publishing your prerelease release notes to social platforms such as Twitter and Reddit kicks off a central location for users to provide feedback and interact with your team. This allows you to build momentum around your changes, follow up with posts around feedback you've received, and use that momentum to gain additional traction for your release.
By being transparent and pushing customers to share reviews and feedback in the public spotlight, you put attention on your release. This shows your engagement with the community and can help increase users in your early access program while also alerting later adopters of upcoming changes that will impact them. This, in turn, drives more sharing and conversations around your release, which provides you with additional inputs to base decisions off of.
With information coming in on your prerelease, you can close your feedback loop by using the data points to make informed decisions on how to best iterate on your release. From high-level decisions like pivoting or persevering on a feature, down to more technical improvements such as:
Capturing, analyzing, and acting on the data you collect helps you make your release as effective as possible. It reduces issues that automated pipelines miss by uncovering reality and eliminating many assumptions that need to be made before a release, such as how users will use a feature or how developers will build integrations.
Many companies such as Tesla, Apple, and Google plus decentralized platforms like Ethereum and Prysmatic Labs incorporate prereleases into their product lifecycles. Using prereleases helps them deliver the best possible experiences to their communities, reduce change failure rates, and remove bugs before they become costly mistakes that negatively impact their brand and reputation.
Terminology Note: Nightly builds, alpha programs, beta programs, canary releases, etc all relate to a prerelease program. Different teams use different naming conventions for their prereleases. Usually, these various names are indicative of different stages of a release. For example, nightly builds tend to be builds that happen daily and are highly unstable whereas a canary build is a more polished version but still more temperamental than a beta release>
Seeing the mega, large, and mid cap's beta programs can be intimidating
but adding prereleases to your workflow and gaining from the benefits can
be done quickly by single contributors. Assuming you're using GitHub for
storing your software project, you can get started by tagging your git
releases using semantic versioning and add a
-beta to it to indicate a
beta release. You can then socialize the release to your teammates or
community. It's important to use prerelease notation to inform end-users
that a release is not stable, meaning there is a higher probability for
unexpected things to happen. Doing so helps to protect your reputation
and the confidence users have in your standard releases.
For explicit alignment with the semantic specification, here's how to define prereleases in your versioning:
A prerelease version MAY be denoted by appending a hyphen, and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Prerelease versions have lower precedence than the associated normal version. A prerelease version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.–.
If you don't want to worry about managing prerelease versioning, you can add the Next Release GitHub plugin to your build. Once it's added, you can simply add a beta tag to your release, and we'll automatically handle versioning of your prereleases and help you communicate them to each of your stakeholders.
Once you've managed your builds' versioning, you can start building out your early access program. Deployment, enrollment, and notifications are three foundational elements to making your program a success. This is why we suggest asking yourself where you will deploy and host your prerelease builds, how you will get people to use them, and how you will manage feedback. There are thousands of options for these questions, and the answers will depend on your product, community, and bandwidth. If you'd like to brainstorm or need someone to bounce ideas off of, feel free to send us a note, and we'll be happy to jump on a call.
For the purposes of this post, we'll assume you're developing an image analysis package for python that is used by other developers who network on Twitter and Reddit. Since your communities already use Twitter and Reddit to socialize, you can reuse these platforms to notify users of new beta releases, solicit feedback on the release, and dig deeper into issues via direct messaging. You can use your GitHub repository to host the prerelease packages and automatically publish them to PyPI for easy pip installation via one of the Python Foundation's GitHub Actions.
This approach can be reused for most software package use cases and can be expanded on for consumer-facing applications. You might use feature flags and your internal service desk for managing deployments and feedback.
If you'd like more information on prereleases, setting up your pipeline to support them, or general release management, feel free to reach out.
Sign up today with instant, no-hassle setup. No credit card required!Sign Up Now
© 2020 Next Release, LLC. All rights reserved. Made with ❤ in Michigan.