How to Run a Beta Test: An 8-Week Roadmap With Exit Criteria
7 min read ยท 2026-10-11
To run a beta test, decide what it must prove. Then give a working version to a small group of real target users for a fixed period, collect their feedback in one place, fix what blocks them, and decide whether to launch. A beta is not a soft launch. It is a test with a goal, a deadline and a verdict at the end.
The roadmap below takes 8 weeks. You spend one week setting the goal, two weeks screening testers and preparing, four weeks testing in two waves, and one week reading the results. It works for a web app, a mobile app, a SaaS feature or a physical product with a digital part. If your product is small, shorten the testing waves. Don't skip the first phase or the last one.
The roadmap at a glance
Goal: Prove that real target users can get value from your product without help, and end the beta with a clear verdict based on criteria set in advance. Duration: 8 weeks
Define the beta goal and exit criteria (Week 1)
Decide what the beta must prove before anyone touches the product.
- Write down the 2 or 3 questions the beta must answer, for example "Can a new user complete setup alone?"
- Turn each question into an exit criterion you can check, such as "most testers finish setup without contacting us".
- List what is in scope and out of scope, so testers don't report on unfinished areas.
- Choose a closed beta (invited users) or an open beta (anyone can join).
Milestone: A one-page beta plan with questions, exit criteria and scope, approved by the team.
Screen and confirm testers (Week 2)
Pick people who match your target user, not just people who like you.
- Send a short screener form to your waitlist and past interview contacts.
- Select the testers whose answers match your target profile.
- Invite more than you need, because some will never log in.
- Confirm the dates, what you expect from them and what they get in return.
Milestone: A confirmed list of testers who match your target profile and agreed to the dates.
Prepare the build and feedback channel (Week 3)
Make it easy for testers to start and easy for you to hear them.
- Freeze a stable build and fix any bug that blocks signup or the core task.
- Set up one feedback channel: a form, a shared board or a dedicated chat group.
- Write a short tester guide: how to access the product, what to try, how to report a bug.
- Prepare 3 short surveys: after first use, at mid-point and at the end.
Milestone: A teammate who has never seen the product completes signup and the core task using only the tester guide.
Run wave 1 and watch closely (Weeks 4-5)
See where testers get stuck in their first real use.
- Open access and send the tester guide on day one.
- Check the feedback channel every day and reply to every report.
- Book short calls with a few testers to watch them use the product.
- Tag every piece of feedback: bug, usability, missing feature, praise.
Milestone: Every tester has logged in at least once, and every report is tagged.
Fix blockers and run wave 2 (Weeks 6-7)
Fix what stops people, then check that the fixes work.
- Rank issues by how many testers hit them and whether they block the core task.
- Fix the blockers. Park nice-to-have requests in your backlog.
- Release an updated build and tell testers exactly what changed.
- If you can, add a few new testers to see the product with fresh eyes.
Milestone: The top blockers from wave 1 are fixed and confirmed by testers in wave 2.
Close the beta and read the results (Week 8)
Compare what happened with the exit criteria you set in week 1.
- Send the final survey and close the feedback channel on the planned date.
- Mark each exit criterion as met, partly met or not met.
- Write a one-page summary and share it with the team and the testers.
- Once the product is ready, plan the launch itself as a separate project. The go-to-market roadmap template covers that part.
Milestone: A written verdict. Either the product is ready, or it needs a fix list and another wave, or it needs a rethink.
How to set exit criteria that lead to a real decision
Most betas fail at the end, not at the start. The team collects lots of feedback, and then nobody knows if the product is ready. Exit criteria solve this. They are the conditions you agree on before the beta starts. If they are met, the beta has done its job.
Good exit criteria are tied to behavior, not opinions. "Testers like it" is weak. "Testers complete the core task without help" is strong, because you can check it. Here are examples you can adapt. Pick 3 to 5 criteria. With more than that, the verdict gets blurry again.
- Most testers finish onboarding without contacting support.
- No open bug blocks the core task.
- Several testers come back in the second week without a reminder.
- Testers can explain in their own words what the product does for them.
- A few testers ask when they can keep using it or pay for it.
How to write a beta screener
A screener is a short form that tells you if a person matches your target user. The best testers have the problem your product solves and are trying to solve it today. Friends and family are kind, but they rarely match. Their feedback tends to be polite and vague.
Keep the screener to a few questions. Send it first to people who already raised their hand. If you don't have a list yet, see how to build a SaaS waitlist before launch. One tester who fights the problem every day is worth more than five who are just curious.
- What is your role? Tells you whether they belong to your target segment.
- How do you handle this problem today? Tells you whether they feel the pain and already use a tool or habit for it.
- How often do you face it? Tells you whether they will use the product enough during the beta.
- How much time can you give over the next few weeks? Tells you whether they will actually show up.
How to collect feedback without drowning in it
Feedback scattered across email, chat and calls gets lost. Pick one channel and send everything there. If a tester emails you, copy the message into the channel yourself. Mix three types of feedback, because each one catches different problems.
Teams often skip observation, yet it is often the most useful. People work around problems without telling you. When you watch them, you see the hesitation, the wrong click and the moment they give up.
- Reports: bugs and issues testers send on their own. Good for finding what is broken.
- Surveys: short questions at fixed moments. Good for comparing answers across testers.
- Observation: short calls where you watch a tester use the product. Good for finding what confuses people who never report it.
How to decide what to fix during the beta
You can't fix everything in two weeks. Sort each issue with two questions. Does it block the core task? How many testers hit it? An issue that blocks the core task for many testers comes first. A feature request from one tester goes to the backlog.
Be careful with feature requests. Testers often suggest solutions, like "add an export button". Ask what they were trying to do. The real need may be sharing results with their manager, which you might solve in a simpler way. Keep a list of these needs. They will feed your product roadmap after the beta. How often should you update your roadmap explains when to fold them in.
Tell testers what you fixed. A short "you reported this, we fixed it" message keeps them engaged for wave 2.
Common mistakes to avoid
- No exit criteria. Write 3 to 5 checkable conditions in week 1 and judge the beta against them in week 8.
- Testing too early. If testers can't finish the core task, you learn little. Get to a working version first, as in how to build an MVP in 30 days.
- Only friends and family. Screen testers on their role and how they solve the problem today.
- No end date. Set fixed dates and close the feedback channel on time.
- Feedback in many tools. Route every report into one channel and tag it.
- Building every request. Fix blockers first. Put requests in the backlog with the real need behind them.
Frequently asked questions
How long should a beta test last?
Four to eight weeks works for most software products. That gives you time for one round of testing, one round of fixes and a second round to confirm the fixes. Very simple products can run shorter. Complex B2B tools may need longer, because testers use them less often.
How many beta testers do I need?
Enough to see patterns, but few enough to talk to each one. For a first closed beta, a small group you can follow one by one usually beats a large group you can't support. Invite more people than you need, since not everyone who signs up will take part.
What is the difference between a closed beta and an open beta?
A closed beta is invite-only. You pick the testers, control the group and get deeper feedback. An open beta lets anyone join. It tests the product at a larger scale, with less predictable users. Most teams start with a closed beta and open it up later.
Should beta testers pay for the product?
Usually not during the beta, because you are asking for their time and feedback. Many teams offer early access or a discount later instead. A paid beta makes sense when you want to test whether people will pay. In that case, make it one of your exit criteria.