What are common expectations of the type of feedback that alpha/beta users should provide to Product Marketing Managers and Product Managers? What are some perks or incentives that you offer for alpha/beta users?

This goes back to your goals for running the alpha/beta and what kind of information you want to gather.

In general I look for honest feedback on some of the following themes, but you’ll want to work closely with your PM partners to define specifics.

1. Does the product solve the right problem or in other words is this a problem the customer actually has?

2. Does the product actually solve the problem? If not, what would need to change.

3. Does the product meet customer’s expectations. If not, what did they expect and how should it be adjusted to meet them?

4. Does the customer enjoy using the product -- what are the pain points, what’s missing, what do they really like.

5. How would they describe what the product does and why they are using it.

You can gather this feedback through qualitative interviews or ideally through a UX study so you can work out any kinks in usability.

Usually participating in the alpha/beta tends to be a good incentive in itself since customers enjoy getting early access to tech. However you can also thank them with gift cards. If funds are an issue, you can get creative by offering access to a gated feature/plan, an hour with somebody from the leadership team, or free tickets to one of your events.

I strongly recommend against providing ANY incentive for alpha and beta users to provide feedback or engagement. I find it creates bias and influences the kind of feedback you receive. You want real users with real problems running into your software; otherwise you get nice-to-haves or less thoughtful comments. 

It's hard to set expectations for the kind of feedback you receive. Early on, you don't know what customers will react to, or even where the real bumps will be. I'd recommend starting super open ended, and then narrowing in after some of those early patterns emerge. The best time for this is when you start addressing the first round of feedback. 

The most important thing is to create the space for feedback, and make it an active process. Don't sit back. Set the expectation for feedback with beta users early, and then make it part of a process to capture it. 

So I'd say that:

1. Initial phase: Open-ended discovery with users. Watch, ask questions like "Tell me about your experience." "What were you trying to accomplish?" "What was challenging?" 
2. Second phase: Regular (weekly/bi-weekly) checkins. "How's it going?" "Have you tried X yet?"
3. Third phase (fixing things). Take specific improvements back to customers. "We heard your feedback (and others') and made some updates. Can we look at this again together?"
4. Fourth phase. THANK THEM. Not just with physical rewards and words. Show them exactly how their feedback shaped the product. Show the impact, what new ideas it created, and how it helped others. 

PM and PMMs are likely to have different goals when it comes to feedback from users with early access, but I think that both should at the very least seek to understand, "to what degree have we solved the problem for customers that we set out to solve with this feature/product/release?". If you practice jobs-be-done, that question might be better phrased as "is the user able to hire our product for their job-to-be-done? Why or why not".

As for PMM-specific expectations, I would base these on the goal of your alpha/beta, which you should align with PM on upfront. For example:

- Validate Problem-Solution fit

- Uncover and fix issues ahead of GA

- Source reference customers for a marketable moment 

- Improve the UX before GA

- Inform positioning and messaging

- Inform pricing and packaging

Lastly, I've never given or been involved in a project where an incentive other than, "get early/exclusive access", was offered. If you're building the right things for your customers, you should have no issue getting users wanting to participate in a beta. In theory. 😅

Great question. It depends on what the PM is trying to glean from alpha/beta phases of the dev cycle. Is this a time for functional testing? Are we soliciting for validation of use cases? I've seen early access (EA) used for a myriad of reasons based on the complexity of the feature/product and customer base. What's important is that PMM is aligned with PM on what EA is for, goals, and how each party (inclusive of customer) should participate throughout the process. Oftentimes we just "do" the prescribed steps in fast succession without stopping to understand the why. Understand and codify the why.

If/when you have alignment - I look for the following type of feedback (from PMM perspective):

• the customer can use the feature as outlined in product scope/definition

• the feature is adopted with ease (v. raging clicking and confusion)

• value is received/unlocked and we are able to capture the upside in a form of a testimonial/sound bite.

• use case is validated and surrounding materials are vetted as useful for mass commercialization or identified as a need

Incentives that can be used:

• Exclusive beta privileges

• Exclusive user community access

• Ambassador programs

• Swag/gift cards (I really try to avoid these in favor of more meaningful initiatives)

• Time with influential folks (CEO/CPO)

• Guest content participation

I love this question!

Let me start with a mistake some Product and PMM teams make when it comes to betas of new products: They assume the beta is where customers tell you what you should build; where you learn what kind of product customers want.

The truth is, before your R&D teams code a prototype for a beta, PM and PMM should have mostly figured out which essential capabilities should go into your new product to make it a win. You should have researched the customer need or pain point you're solving for and mapped those needs to product features and potential benefits. These are all discoverable through market research, customer interviews, UX research where you have customers click through wireframes, and competitive intel. And all of this can and should happen before build.

Imagine not knowing these above things before you code your beta product, only to discover during the pilot that your R&D teams built the wrong thing entirely. What a costly waste of resources!

What, then is the goal of a beta? In my experience, a beta can be useful for the following things:

1. Gather customer success stories, proof points, and case studies you can leverage in your global GTM moment or marketing launch (messaging, positioning, etc.)

2. Ensure your product performs as expected in the wild, according to customer-centric exit or success criteria. For example, in the case of LinkedIn Ads, where I work, for our betas we set goals for whether the beta product helps customers achieve certain targets for Cost per Marketing Qualified Lead, revenue or opportunity pipeline generated, attributable brand lift, etc. If we don't hit these targets, we might need to hold back the launch to improve the MVP.

3. Test different positioning statements with customers who've used your product and can vouch for its benefits or value props. This kind of goes with #1.

4. Learn more about who your target customer really is: their jobs to be done, their use cases for your product, their verticals or sales tiers, etc. Which ICP's demonstrate the highest CSAT?

5. Identify some follow-on features to build post-launch. Or, worst case scenario, you discover in the that your prototype is missing 1 must-have feature, and now your Eng team can hopefully fast-track its development before launch.

6. Uncover key questions your sales team will have for a global training. Sales reps whose accounts participate in the beta can clue you into what training needs they'll have and key info they'll need to sell effectively. Your beta reps can also become internal sales champions for your product!

As for whether your should financially incentivize customers to join your beta, I'd say tread carefully. Sometimes it makes sense to give your customers a value-add for participating to help you collect more data in a compressed testing timeframe. But if you make your product entirely free to use during the beta because you fear it's not good enough to win customer budgets, you might be masking or compensating for inherent weaknesses that you won't even see till it's too late (i.e.: during the main product launch). Financial incentives, if too generous, can also obscure who your target customer really is or complicate your ability to price correctly in GA (general availability).

So when it comes to incentives, ask yourself this before proceeding: Why I might I need to offer a financial incentive to my customers in the first place; what do I gain from this; what are the risks (and how do I mitigate them); and what is the minimum level of incentivize necessary to achieve my beta goals?