[zerkten]

You need to consider the blast radius and how long features may be in preview. Ideally, you would scope the preview to just a subset of users. When you go to a complete customer base you start to get into the situation where the customer has failed to communicate with their users, and have more people raising issues. This isn't bad necessarily, but you have to be prepared to handle it.

If you keep something in preview for a long time then there can be a divergence from the main product. Make sure that data or work from users is migrated across when you finally release.

It makes sense to think about the opportunity for support to participate in the preview. Let them listen in to customer calls and learn about the problems. Providing a dedicated support person for previews is tempting, but long-term it's better to avoid this specialization and enable the whole support team to participate. This shares knowledge and avoids certain people being granted special privileges while others toil on average support tickets.

Microsoft publish some of their methodology at https://docs.microsoft.com/en-us/microsoft-365/admin/manage/.... The key point is that they have set out the boundaries for their program so that customers know what to expect and it can be repeated for every customer.

You will have to learn how to do your previews, but you should lay down some rules. Set it up so kudos from participants can be used for marketing after. You are the one to decide when the preview ends, but setting some minimum time in preview gives customers more confidence and time for you to process feedback. Make it clear if features are locked when you enter the preview and what feedback you are after.

Once the preview is over, thank the participants. Call them out if you have a public forum. Participation can become a mini case study for your marketing efforts.