Before you build: test a product idea with a one-page experiment
Someone suggests a new feature and the conversation jumps straight to how long it will take. Before anyone has examined the problem, the team is discussing screens, estimates and a release date.
A small experiment can give that conversation a better starting point. It helps you investigate one important assumption before committing to a larger build.
An assumption is something you are treating as true without enough evidence. An experiment is a planned way to gather information about it. The aim is to learn enough to make a more informed decision, including a decision to stop.
Choose the uncertainty that matters
Consider a fictional mentoring product. The team wants to add a mentor-comparison screen because it believes people struggle to choose someone suitable.
Several assumptions sit inside that idea: people want to compare mentors, the information shown helps them choose and the difficulty is selection rather than availability or cost.
Start with the assumption that could most change your decision. Building a polished comparison screen will not answer whether suitable mentors are actually available.
Put the experiment on one page
1. Write the problem and the assumption
Describe the user and the situation. For this example: “People seeking their first mentor struggle to identify someone relevant to their goal.”
Then name the assumption you are testing: “A short description of a mentor’s relevant experience will help people decide whom to contact.” Keep the claim narrow enough that an observation could challenge it.
Avoid starting with “Users need a comparison feature”. That embeds the proposed solution in the problem statement.
2. Choose a small way to learn
You could show a simple paper sketch or static prototype with fictional mentor profiles. A prototype is a representation of a possible product experience, useful for exploring a question before full implementation.
Ask participants to choose whom they would contact for a specific goal and explain their reasoning. Include an option to choose nobody, so the exercise does not force a positive result.
This can help investigate understanding and selection. It cannot establish that people will pay, book a real session or return after using the service.
3. Decide whom to involve
Look for people whose circumstances match the intended user group. Colleagues may be convenient, but their product knowledge can make a confusing experience look clearer than it is.
Explain the purpose, obtain agreement to participate and collect only the information needed. A small first round can reveal issues worth investigating. It does not represent every potential user or produce a reliable market-size estimate.
Record whose perspective you have included and whose is missing.
4. Define what you will observe
Write your questions before the session. Can participants describe the differences between profiles? What information do they use? Where do they hesitate? What do they need that is missing?
Keep notes on what they do as well as what they say. “I like it” is less useful than an explanation of how they reached a decision.
Avoid steering with a question such as “Wasn’t the experience section helpful?” Ask what influenced the choice and let participants identify the important information.
5. Agree the decision the evidence will support
Before running the exercise, discuss what different findings might mean. If participants cannot distinguish profiles, revise the information and investigate again. If they understand the profiles but cannot find a suitable mentor, examine availability.
If the idea looks promising, choose the next uncertainty to address. Do not turn one encouraging session into approval for every feature in the proposed service.
Record contradictory observations as well as the comments that support the idea.
A copyable experiment brief
The brief is an illustrative planning template, not a completed research report. After the exercise, add the observations and the decision you actually made.
Keep the learning connected to delivery
Share what changed in your understanding and what it means for the next piece of work. If an assumption is unsupported, say so clearly. A useful experiment can prevent work from proceeding, rather than simply justifying a feature already chosen.
Choose one upcoming idea and write the assumption that would most change your decision. Start the one-page brief there.


