How to scope your first growth experiment

A first growth experiment should help you make one decision. Writing that decision down is often the first difficult step. “Improve conversion” leaves room for several changes, several audiences and several explanations for whatever happens. A useful plan narrows those possibilities before work begins.

The process below is an operating guide, with an illustrative example throughout. It is intended to help a founder organize a small test. It does not prescribe a statistical threshold or promise a particular business outcome. Tests that require formal causal conclusions need suitable design and analysis for their circumstances.

Begin with the question you cannot answer

Describe the point of uncertainty in ordinary language. Perhaps new customers ask what happens after booking a consultation. Perhaps trial users stop before completing a first task. Perhaps buyers cannot explain the difference between two service packages. Choose one of those observations and write the decision it creates.

For example, imagine a small design studio that receives inquiries through a service page. Prospects often ask what the first meeting includes. The founder wonders whether a more concrete explanation would help suitable prospects decide to contact the studio. The decision is whether to keep a revised meeting description, not whether the entire website can produce more growth.

If the question contains several verbs, it may be too broad. “Change the page, add a discount and launch ads to improve bookings” is a project with multiple moving parts. Break it into decisions that can be considered separately. The first experiment should be small enough that someone can explain the plan without describing a whole quarter's marketing strategy.

Record a baseline you can actually use

A baseline describes the current situation using records you trust. Write down the source, period and definition. If you count inquiries, decide which inquiries qualify and whether duplicates are removed. If you count completed tasks, define completion before examining the result.

The design studio might inspect a recent set of inquiries and note which prospects asked about the first meeting. If its records are incomplete, that limitation belongs in the plan. A guessed number cannot become a reliable baseline simply because it appears in a spreadsheet. The founder may need a short observation period before trying the change.

Do not collect more information than the decision needs. A small test can drown in metrics that nobody knows how to interpret. Keep the primary observation visible and add only a few checks that would reveal a practical problem. For the studio, suitable inquiry quality may matter alongside the number of inquiries. More messages from people seeking an unrelated service would not necessarily justify keeping the new description.

Write the hypothesis as a reasoned expectation

A hypothesis links the proposed change to the observation. “A concrete description of the first meeting will reduce questions about what happens next” is more useful than “the new copy will perform better.” It explains what the founder expects and why the change might help.

State the evidence behind the expectation. In the example, the evidence is repeated questions in actual inquiry conversations. That supports investigating clarity. It does not prove that the proposed wording solves the issue or that confusion is the only reason prospects hesitate. The hypothesis should preserve that uncertainty.

Then write the change in enough detail that another person could implement it. A sentence such as “make the page more compelling” is not an implementation instruction. “Replace the general consultation paragraph with three sentences explaining preparation, meeting agenda and next-step recommendation” is much easier to review.

Choose the smallest practical change

A small test is not necessarily a small visual edit. It is a change whose purpose and consequences are manageable. The studio might revise one paragraph and leave the service package, inquiry form and traffic sources unchanged. That gives the founder a clearer account of what was attempted.

Avoid adding an unrelated improvement because the page is already open in an editor. A new image, price change and form redesign could each influence behavior. If they must change together for the test to make sense, describe them as a package and acknowledge that the test will not isolate each element.

Check that the change can be reversed or paused. Note who can restore the previous version and where it is saved. Also consider who needs to know the test is running. A person responding to inquiries may need to use the same explanation as the page so visitors receive a consistent answer.

Decide what evidence would support the next step

The decision rule should be written before the result arrives. It might describe adopting the change, revising it or collecting more evidence. A useful rule also admits an inconclusive outcome. Otherwise the founder may feel compelled to declare a win or loss when the information does not justify either.

In the studio example, the founder could review whether prospects understand the meeting and whether the revised description creates new misunderstandings. If the test includes a formal comparison, its design and required observations must be chosen appropriately before launch. A small collection of comments can help explain confusion, but it should not be presented as proof of a percentage improvement.

The minimum practical change also matters. What difference would justify the cost or complexity of keeping the revision? A tiny movement in a noisy measure may not change a business decision. Write the business reason for the threshold, then make sure the observation method can support that judgment.

Set limits and a review date

A plan needs an ending. Specify the intended observation period, who reviews the evidence and what can cause an early pause. The pause conditions should concern real problems, such as incorrect information, broken submission behavior or a surge of confused prospects. They should not simply let the founder stop when a preferred result appears.

A review date keeps the test from becoming a permanent change through neglect. It also creates a place for team discussion. The person who made the change should bring the original hypothesis, implementation notes and evidence summary. A reviewer should be able to distinguish the plan from adjustments made after launch.

Check for changes outside the experiment. A new referral partner, an unusual event or a major seasonal shift may affect the observations. Record those circumstances rather than pretending the test happened in a vacuum. Sometimes the responsible conclusion is to gather better evidence later.

Review the result and the decision separately

At the end, write what happened before writing what to do. Describe the observations, missing information and departures from the plan. Then explain the decision. A team may keep a clearer paragraph because it improves the accuracy of the offer description, while acknowledging that the test did not establish an effect on inquiries.

That separation makes the record useful next month. Someone can see which conclusions were supported and which remained uncertain. It also protects a team from turning a good story into a stronger claim than the evidence allows.

Put the whole plan on one page

A workable first plan contains the question, baseline, hypothesis, exact change, observation method, decision rule, owner and review date. Add a short list of limitations and pause conditions. If a colleague cannot identify the decision from that page, revise the plan before launching the work.

For the design studio, the immediate next step is to draft the meeting description and show the plan to the person answering inquiries. That review may reveal a missing detail before any visitor sees the change. Starting with a reviewable plan gives the founder a better chance of learning something useful, even when the eventual result is mixed.