A few years back, we ran an in-home beta for a robotic smart speaker. In the final survey, testers rated the experience below average, and more than three-quarters said they wouldn't recommend it.
They liked the hardware, but they kept reporting unreliable core features and frequent issues. Worse, it did less than smart speakers that cost a fraction of the price.
The product launched a few months later with most of those gaps still in place. It struggled to find buyers and was discontinued within a couple of years.
We see that more often than we'd like. Results tend to show up at the go/no-go meeting as a dashboard with an issue count and a participation number. Neither number tells anyone whether to ship. The fix is to put what testers told you in the terms leadership decides on: risk, customer satisfaction, and revenue. This approach works whether you face one big launch meeting or make smaller rollout calls every week.
Set the Bar Before the Test Starts
Beta results only settle a go/no-go decision if everyone agreed, before the test, on what "ready" looks like. If you planned your test around the decision it's supposed to inform, you're most of the way there. (If you didn't, the Ultimate Guide to Beta Testing walks through test planning.) The rest is writing down which results mean "go."
Those are your go/no-go criteria. Keep them few and measurable, and get the decision-makers to sign off before the test starts. These four make a reasonable starting point.
- No open blocking issues
- A minimum share of testers who complete the core task
- A minimum average star rating from testers
- An owner and a fix date for each of the top issues
For help picking the thresholds, see the testing metrics that matter for ship decisions.
Agreeing up front turns the meeting into a readout against a bar everyone already accepted. It also keeps the goalposts from moving once the results come in.
Translate Findings Into Risk, Customer Satisfaction, and Revenue
Testers give you three kinds of feedback: issues, ideas, and praise. Your job is to show what each one means for the launch.
Risk: what could stop the launch
Start with blocking issues: anything that stops one or more testers from using a feature, or the product, at all. They go at the top of every readout, no matter how few testers hit them.
A wearable company ran into one in beta. Testers reported inaccurate sensor readings, but the team couldn't find a clear pattern at first. Asking testers about their skin tone helped reveal the problem: the sensor wasn't equally reliable for everyone. Leadership delayed the launch and replaced the sensor, then tested the new one across skin tones before shipping.
Averages can hide problems like this, so break every serious issue down by who hit it. Something that looks minor across the whole test can be a dealbreaker for one group of customers.
For each risk, spell out what happens if it ships. If your last launch had a similar issue, its support ticket volume is hard evidence to bring into the meeting.
Customer satisfaction: what customers will say after launch
The number of reports alone doesn't tell you how serious an issue is. A typo that dozens of testers pile onto can drown out a hardware failure only one person reported. The hardware failure is the one that should worry you.
So rank feedback by what it does to the product experience. Our team's readouts sort the top issues, ideas, and praise by Feedback Impact Score, which combines four signals: feature weight, severity, popularity, and frequency. Feature weight and severity cover how important the feature is and how badly an issue affects it. The other two measure reach: how many testers engaged with the feedback, and how many reported the same thing.
Satisfaction splits by audience the same way issues do. If power users love a new feature and casual users find it confusing, look at where casual users get stuck. They may need clearer onboarding, or the feature itself may need work.
Revenue: what shows up in the ratings
Revenue is the hardest lens to put a number on before launch. Star ratings can help explain what's at stake.
When we analyzed final star ratings from nearly 100 tests run on Centercode, the testers who hit an issue stood out. On average, they rated the product a little under half a star lower than testers who didn't. In some tests, the gap was more than half a star. The full analysis is in The Impact of Pre-Release Product Testing on Star Ratings.
For a product hovering around four stars, a gap that size could put it above or below the four-star line. That line shows up in conversion data. PowerReviews analyzed more than 20 million product pages in 2022. Products rated 4.0 to 4.24 stars converted 19% better than products rated 3.5 to 3.99.
Compare ratings from testers who encountered an issue with ratings from those who didn't. A large gap helps explain why the issue matters, even if it can't tell you exactly how much a fix will improve public ratings.
Don't leave praise out of this part. It tells marketing what customers love, which is what the launch should lead with.
How to Present Beta Results in the Go/No-Go Meeting
Whether you present in person or send a report ahead, your findings need to answer leadership's questions before anyone asks them. Everyone in that meeting is listening for their own risk, and each team needs something different from your results. Support is picturing the ticket queue. Marketing is wondering what they can still promise. Beta testing is often the only input that shows how real customers experience the product, so it deserves more weight than it gets.
Waiting until the go/no-go meeting to share beta findings is too late. Share findings as they come in, and flag blocking issues the day you find them, so no one hears about one for the first time on decision day.
Answer the three questions leadership asks
In our experience, the same questions come up for almost every finding:
- What's the impact on the customer?
- What percentage of testers are hitting it?
- What would a fix look like, and how long would it take?
Walk in with the answers, backed by hard numbers. Using made-up figures, the difference looks like this.
The dashboard version: "15% of testers reported sync problems."
The readout version: "38 of our 250 testers (15%) couldn't get past the sync screen on older Android phones. The last time we shipped a sync problem like this, it drove about 1,100 support tickets in the first month. Engineering says the fix takes eight days. Our recommendation: no-go for the 14th. Reassess for the 28th once the fix is verified."
Bring a one-page readout
Nobody in that meeting is going to read 400 pieces of raw feedback, so don't make them. Put it on one page, in this order:
- Your recommendation: go, go with conditions, or no-go
- Blocking issues and where each one stands
- Your criteria, and whether each one was met
- The top findings, each with answers to the three questions
For the sync example, the criteria section might look like this.
Recommendation: No-go for the 14th. Reassess readiness for the 28th after verifying the sync fix and resolving or explicitly accepting the other missed criteria.
If you're sending the readout ahead instead of presenting it, the page is the whole presentation. Write it so it stands on its own.
Go/No-Go Decisions When You Test Continuously
If you run delta testing, or any program where testers stay on while you ship, the go/no-go decision gets smaller and comes more often. Each release, and often each rollout stage, gets its own go, hold, or roll-back call.
Your criteria become standing rules for each stage. A feature might move from your tester group to 10% of customers only when there are no open blocking issues and testers’ average rating is at or above target. Write those rules down once, and every stage after that is a quick check against a bar everyone already agreed to.
The one-page readout turns into a living scorecard. Keep the criteria table from the sync example updated as feedback comes in, so anyone can check where a release stands without waiting for a meeting.
Smaller calls can belong to the team that owns the feature, while leadership sets the criteria and weighs in on the big gates. When a big launch meeting does come around (a hardware ship date, a major release), it mostly confirms what everyone has already seen.
Before You Walk Into the Meeting
If you're recommending a delay, be ready for someone to ask whether there's a way to keep the original date. Talk with engineering before the meeting about what can be fixed and tested in time, and whether there's another way to launch, such as a smaller release.
For each option, explain who would still hit the problem and what that would mean for them. If you still recommend a delay, say what needs to change before the product is ready and when the team can check again.
Frequently Asked Questions About Go/No-Go Decisions
What is a go/no-go decision?
A go/no-go decision is the checkpoint where the people accountable for a launch decide whether the product ships as planned, ships with conditions, or waits. It usually comes near the end of beta, in the lead-up to launch.
Who makes the final go/no-go call?
The person who owns the launch, often a product leader or executive sponsor, with engineering, QA, support, and marketing weighing in. Whoever ran the test rarely makes the call, but they should walk in with a recommendation.
What's the difference between exit criteria and go/no-go criteria?
Exit criteria define when a test is finished. Go/no-go criteria define whether the product is ready to launch. A test can meet every exit criterion and still end in a no-go. That's the test doing its job.
What if leadership overrides the beta data?
It happens, sometimes for reasons you can't see from inside the test. Write down the decision and the known risks, then agree on what you'll watch after launch. Tips for balancing executive opinions and beta results goes deeper, and why beta results need another look after launch covers the follow-up.
How many testers do you need before leadership trusts the results?
Enough to see patterns within each group of customers that matters. That depends on how complex the product is and how varied your audience is. The Test Size Calculator gives you a defensible range, with a confidence level you can quote in the meeting.
Do you still need a go/no-go meeting if you test continuously?
For the big moments, yes. A hardware ship date or a major release still needs one clear call. The meeting just goes faster, because the smaller go, hold, and roll-back calls already happened along the way and the scorecard shows where things stand.
Do go/no-go criteria change for AI features?
They should. AI features can respond differently from one input to the next. Add criteria for how the feature handles the inputs real testers give it, and watch whether testers keep using it after the first few tries. Users give new products less benefit of the doubt than they used to.
