How do you adapt release for very distinct audiences, especially when the release are beta or otherwise not completely generally available?

Question

Mary (Shirley) Sheehan · Accepted Answer

I'm into taking a very phased approach - e.g. Beta audience during a certain time period (where you are not only testing the product features but also the messaging and positioning), then roll out to an expanded Beta if necessary, then full GA. For almost all top tier launches we do this in a phased approach.

In our product we're able to "feature flag" the new product or feature for just the hand-selected group. One thing that worked well recently was to do a webinar just for the Beta participants with the PM to walk through the functionality and answer any questions (this was a good way to scale training). We were then able to follow up with a survey about how they expected to use it, and set up a date / time for 1:1 convos about their experience with the product.

Manav Khurana · Answer

I've always liked having one core audience & many supporting audiences for a product story... think about it. Movies with multiple heroes are confusing.

Pick your core audience and tell the product story for them. If you have multiple supporting audiences, then describe how everyone can work better (using your product) with related audiences.

As an example, at Twilio we launched the Enterprise Plan. It provided capabilities for Finance, Security, DevOps, IT, etc. We messaged the product for developers because they were our primary audience. We talked about how the Enterprise Plan helped developers pick the tools they want, while satisfying concerns from the procurement, security and operational teams. It worked well. Developers sold the product for us :).

Carlos González de Villaumbrosia · Answer

I was going to go into a long-winded answer until I saw that Josh Goslinger kind of laid out the core points I was going to mention (like a pro I may add). Regardless, I'll give you my two cents.

Within use cases, you can do some A/B for segmented audiences to gather information on what exactly is needed in these distinct audiences, and what kind of journey they are trying to go on with your product. Since you describe a release that is not necessarily available, these broken down use cases will paint a clearer picture on what will need to be available in the future.

Since the release is somewhat 'vague' and the audience is unique, the release may miss its initial mark. This is fine! It is a beta and you are learning from this.

Josh Gosliner · Answer

Of course this always depends on the product, but I typically like to think about use cases in addition to or in place of segmented audeinces. Use cases can frequently apply to a number of audiences and therefore better explain the value than just speaking to an audience.

Additionally, uses cases enable me to tell user stories that are much more compelling in trying to understand the "why" of a new feature or major release.