How to Build a Test Plan Your Board Can Read

A test plan for board members works when it answers three questions in plain language: what are we testing, what result means go, and what result means stop. The metrics and methods belong in the document, but the decisions those metrics drive belong on the first page. Most test plans fail at the board level because they describe process without connecting it to outcomes.

Why this matters

Board members and investors approve budgets based on test plans they often cannot fully evaluate technically. If the plan reads as a technical document, it gets approved on trust rather than understanding.

That is a problem for both sides. The founder loses the benefit of the board's commercial judgement, and the board loses the ability to ask useful questions.

A readable test plan produces better decisions, not because the board becomes technical, but because the trade-offs become visible.

What a board test plan is not

It is not the internal QA plan. The internal plan tracks bugs, devices, and build stability. The board plan tracks whether the game should continue to receive investment.

Three things to leave out.

• Device matrices and OS versions. The board does not need to know which phones you tested on.
• Bug counts and severity ratings. Unless a critical bug threatens the schedule, this is operational detail.
• Technical descriptions of the test infrastructure. How you run tests is your concern. What the tests revealed is theirs.

The board plan is a decision document, not a status report. It should make the go or stop decision as clear as possible.

A test plan the board can read is one that connects every metric to a decision.

The structure that works

Five sections, each short enough to fit on a single page when combined.

1. What we are testing and why. One paragraph. State the specific question this test answers and why it matters for the business, not the game.

2. How the test works. Two to four sentences describing the method. Enough for the reader to understand the approach, not enough to replicate it.

3. The metrics and their thresholds. A table mapping each metric to a go, conditional, and stop result.

4. The timeline and cost. When the test runs, when results arrive, and what the test costs.

5. The decision framework. What happens in each outcome. Go means what specifically, conditional means what changes, and stop means what is preserved.

Writing the metrics table

The most important part of the document. Each row should be readable without technical background.

Use this format.

Three rules for this table.

1. Define every metric in plain language. "Day one retention" means nothing to someone who has not run a mobile game. "Share of players who return the next day" does.
2. Set thresholds before the test runs. Deciding what good looks like after seeing the results introduces bias.
3. Include the conditional column. Not every result is clearly go or stop. The conditional column shows the board that there is a middle ground and what you plan to do in it.

The thresholds themselves depend on genre and publisher requirements, as covered in How Publisher Submission Bars Differ.

Framing the cost

Board members think in investment terms. Frame the test cost as a cost of information, not a cost of production.

Three elements to include.

• The test spend. What the advertising or user acquisition costs.
• The development time. What the team spends preparing and running the test, expressed as days or weeks and their cost.
• The cost of not testing. What it would cost to proceed to full production without this information. This is the number that justifies the test.

A $2,000 test that prevents a $50,000 mistake is a 25x return on the information spend. Frame it that way, because that is how the board evaluates it.

The decision framework

The section most often missing and most often needed.

State explicitly what each outcome triggers.

Go: proceed to the next milestone. State what that milestone is, what it costs, and what it tests next.

Conditional: specify what changes. More testing, a design revision, a smaller next step. Be specific about what conditional means in practice.

Stop: state what is preserved. The codebase, the learnings, the creative assets. Stop does not mean waste, and the board should see that clearly, per When to Kill a Game and What to Salvage.

The decision framework turns a test from an expense into a structured investment step. Each test produces a decision, and each decision either advances the project or protects the remaining budget.

Common mistakes

Four errors that reduce a test plan's usefulness at the board level.

1. No thresholds defined. The plan says what will be measured but not what the numbers mean. The board cannot evaluate a result without a reference point.
2. Only go and stop, no middle. Real results usually land in between, and a plan with no conditional path forces a binary decision on ambiguous data.
3. Technical language without translation. Every metric needs a plain definition. Every abbreviation needs to be spelled out.
4. No cost of alternatives. The test cost alone looks like an expense. The cost of not testing makes it look like insurance.

What we would do

Write the metrics table first, before anything else in the document. It forces clarity about what you are actually testing and what the results would mean.

Then write the decision framework second. If you cannot state what you will do with each outcome, the test is not well enough defined to run.

Fill in the rest of the document around those two anchors. Context, method, timeline, and cost are supporting detail for the decisions the board will actually make.

Present it in person if possible. A five-minute walkthrough of the metrics table and the decision framework is more effective than the document alone.

The short version

• A board test plan answers what you are testing, what go looks like, and what stop looks like.
• Leave out device matrices, bug counts, and technical infrastructure.
• Use a metrics table with plain definitions and go, conditional, and stop thresholds.
• Frame the test cost as a cost of information and compare it to the cost of not testing.
• State explicitly what each outcome triggers, including what is preserved if you stop.
• Write the metrics table and the decision framework first, then build the document around them.

Write the metrics table for your next test today. If you want help structuring a test plan for your board or investors, start a conversation.

Related reading: How Publisher Submission Bars Differ, When to Kill a Game and What to Salvage, and Report Game Progress to Investors.