Check the Idea Before You Build

After this lesson, you will be able to plan a small research round, ask questions about what people actually do, and use the notes to decide whether to continue, change direction, or stop. We will continue with ToolShelf, the fictional neighbourhood tool-sharing service. It has no real users or interview results; we will use it to practice the research process without pretending we have evidence.

Decide what you need to learn

Checking an idea does not mean asking people whether they like it. It means finding out whether the situation you care about happens, how people handle it today, and whether the problem is important enough to deserve more work.

Start with one or two uncertainties from your problem brief. For ToolShelf, they might be:

• Do people in the target neighbourhood sometimes need a tool they do not own?
• What do they do the last time this happens?
• What makes that current option difficult or good enough?

Turn each uncertainty into a research question. Avoid objectives like “prove ToolShelf is a good idea.” That wording invites you to collect only supporting evidence. A better objective is “understand how people handled their most recent small repair that needed a tool they did not own.” It leaves room for the answer to be “I already had what I needed” or “I rented one nearby and it was fine.”

The GOV.UK guide to planning a research round recommends setting clear objectives around the behavior, problem, assumptions, and decision you need to make next. Its advice is written for government service teams, but the habit is useful in product discovery: decide what you need to learn before you start asking.

Talk to people who have the experience

For an early exploratory round, the AI Product Builders plan uses five to eight conversations as a practical starting point. GOV.UK guidance suggests four to eight participants for methods such as experience mapping, contextual research, in-depth interviews, or usability testing. These small rounds help uncover examples and questions; they do not produce a statistically representative estimate of how many people have the problem. The same guide says surveys, A/B tests, and benchmarks may need hundreds of participants to produce clear findings, so they need a different design and much larger sample.

Recruit people because they have recent experience with the situation, not because they are easy to persuade. If ToolShelf is meant for neighbours doing occasional home repairs, look for people who have recently completed or attempted that kind of task. A friend can take part if they fit the situation, but a group made only of supportive friends may miss people who would disagree with you. Include variety within the audience you chose, such as people with different levels of experience or different ways of getting a task done.

Keep the invitation plain and neutral. You could say: “I’m learning how people handle small home repairs when they need a tool. I’d like to hear about a recent example. I’m exploring the problem, not selling a service.” That tells a person what the conversation is about without suggesting that they should approve your product idea.

Avoid recruiting only people who already use the solution you hope to build. If the idea is a tool-sharing app, interviewing only people who already borrow tools through apps makes the app seem more inevitable than it is. Learn from people who use other methods too: borrowing from someone they know, renting, buying, delaying the project, or choosing a different repair.

Ask about the last time, not an imagined future

People are often trying to be helpful when you describe an idea. They may say it sounds useful, suggest features, or tell you they would try it. That feedback can be interesting, but it is not the same as seeing a need in their lives. People may misjudge what they will do later, especially when the action has no cost in the conversation.

Ask for a recent story instead. An in-depth interview guide from GOV.UK recommends focusing on real examples, using open and neutral questions, and following up when something is unclear. Try questions such as:

• “Tell me about the last small repair you worked on.”
• “What were you trying to get done?”
• “What did you need before you could start?”
• “What did you do when you realized you did not have that?”
• “What happened next?”
• “What was the most difficult part, if anything?”
• “Did you try another option? What made you choose it?”
• “How did you decide the job was finished?”

Let the person tell the story in their own order. A pause is useful; you do not need to fill every silence. When you hear a detail you do not understand, use a simple follow-up: “Can you tell me more about that?” or “What happened after that?” Avoid suggesting the answer inside the question.

Compare a leading question with a neutral one:

You can show a concept or prototype later, once you understand the current behavior. Even then, ask the participant to try a task and describe what they are thinking. Do not explain how the design is supposed to work before they try it; that can hide where the flow is confusing.

Look at the alternatives people already use

Your product competes with whatever people do today, not only with another app that has the same name. Alternatives can include a friend’s help, a spreadsheet, a phone call, a shop, a community noticeboard, a manual process, waiting, or deciding not to do the task.

Ask what made the current option work well enough and where it caused friction. If someone rents a tool from a nearby shop, the need may be about opening hours, travel, cost, confidence, or something else. Do not assume the answer. Record what you learn and ask what happened in the specific example.

You can also review existing services and public information before talking to people. Look at the steps, prices, coverage, eligibility, reviews, help pages, and conditions that are visible to you. If relevant, check community posts or public discussions for recurring concerns. This desk research can help you avoid asking questions with obvious answers, but it cannot tell you what a particular participant experienced. Keep sources and dates with your notes because offerings can change.

Make an alternatives table with one row per current path:

These rows are starting points for questions, not claims about ToolShelf’s audience. A good alternative may already solve the task. If it does, your product may need to address a different part of the problem, or the idea may not be worth pursuing.

Take notes that keep observations separate from conclusions

During or soon after each conversation, capture the session identifier, date, the participant criteria they match, and the research question you were exploring. Then separate three types of notes:

• Observation: what the participant did or said, written as closely as you can to what happened.
• Interpretation: what you think the observation might mean.
• Question: what you still need to check.

For example, a note template could look like this:

1Session: P__     Date: ____     Research question: ____
2Recent situation described: ____
3What the person did: ____
4What happened next: ____
5Exact phrase, only if recorded accurately and approved for use: ____
6Observation: ____
7My interpretation: ____
8What I still need to learn: ____

This is a blank template, not a fictional participant record. Keep identifying details out unless you have a clear reason and the right permission to collect them. When you review several notes, group similar observations and look for differences as well as patterns. One vivid story can be memorable without being common. A repeated theme can point to a useful next question without proving how widespread it is.

After the conversations, summarize the findings in plain language and keep the underlying notes available to the people who are allowed to review them. The GOV.UK guide to analysing a research session recommends recording observations separately from interpretations, then using findings to decide what to change or research next.

Decide what would count as a useful signal

Before you start, write down what kinds of findings would make you continue, change the idea, or stop. This reduces the temptation to redefine success after hearing the answers.

For ToolShelf, a continue signal might be several people independently describing a recent occasion when not having a tool interrupted a task, along with a current workaround that took meaningful effort. That would justify another round of learning. It would not prove there is a viable business or that an app is the right answer.

A change direction signal might be that people have the tools they need, but coordination with another person is the difficult part. You might revise the problem brief and research that coordination. A different situation could point to a different audience.

A stop or pause signal might be that people rarely encounter the situation, their existing options work well enough, or the problem matters too little for them to change what they do. Stopping an idea is a useful result when it saves effort for a problem that matters more. It is also reasonable to pause if you cannot yet reach the people whose experience you need to understand.

Do not treat a payment as a universal final rung. Existing spending or a real commitment can be stronger evidence of behavior than a polite opinion, but a person may pay for one situation without wanting a recurring product. Any paid pilot, preorder, or deposit must be clear about what is offered and what happens next; do not collect money to create the appearance of demand. The signal ladder is a way to think about evidence types, not a guarantee that every product should end with a payment test.

For a small qualitative round, look for specific stories and meaningful variation, not a percentage to put in a pitch deck. Note who you spoke with, who was missing, what the conversations can and cannot tell you, and which question remains. GOV.UK guidance distinguishes small qualitative rounds from surveys and benchmarks that require much larger samples for clear findings. Do not present a handful of interviews as a market-size estimate.

Handle consent and research notes carefully

Tell participants what you are learning, what you will write down, who may see the notes, and whether you want to record the conversation. Make participation voluntary and explain how someone can stop. Ask before recording, sharing an exact quote, or using a participant’s material in a presentation. Recording can be useful, but it also captures personal information and can make some people less comfortable.

The GOV.UK consent guide explains the information its research participants should receive, including the purpose of the research, data collected, how results will be used, who will see them, recording, and withdrawal. Those details are a sound checklist for a small project. This lesson is not legal advice; check the requirements that apply to your organisation and location, especially before collecting sensitive information or working with children or vulnerable participants.

Store notes and recordings in a place with access limited to the people who need them. Remove names and other identifiers from working summaries when you do not need them. Keep notes only as long as needed for the purpose you explained, and delete or securely dispose of them according to your commitments and applicable requirements.

If you use an AI service to help organize notes, first check whether you have permission to process those notes that way. Remove personal and confidential details where possible. Give the model a bounded task such as “group these de-identified observations by topic; keep uncertainty visible; do not invent or complete missing details.” Then compare its output with the original notes. An AI summary is a convenience for analysis, not a new participant or an independent source of evidence.

A practical research plan for ToolShelf

Here is a plan you could adapt. Because ToolShelf is fictional, the plan is an example of what to do; no sessions have taken place.

1. Decision to inform: Is the problem worth exploring further, and what part of it needs closer attention?
2. Research question: What do people do when a small home task needs a tool they do not own?
3. Participants: Five to eight people who have recently handled a small home task; include people who borrowed, rented, bought, delayed, or found another route.
4. Method: Short, one-to-one conversations about a recent example. Do not begin by pitching the app.
5. Opening: Explain the purpose, voluntary participation, note-taking, any recording, how findings will be shared, and how to stop.
6. Core questions: Ask about the last task, what triggered it, the steps taken, what happened, and what was difficult or satisfactory.
7. Analysis: Separate observations from interpretations. Group similar experiences, record counterexamples, and note who was not represented.
8. Decision: Continue exploring, revise the problem, pause, or stop. Write down why and what you would need to learn next.

The next step is not automatically to open an app builder. If the interviews show a real, meaningful problem, you can choose a small prototype to test a specific part of the experience. If they do not, update the problem brief before spending time on features.

Sources

• Plan a round of user research, GOV.UK Service Manual: set actionable objectives, select participants, plan consent and analysis.
• Using in-depth interviews, GOV.UK Service Manual: use open, neutral questions about real examples and follow up to clarify.
• Getting informed consent for user research, GOV.UK Service Manual: explain purpose, data use, recording, voluntary participation, and withdrawal.
• Analyse a research session, GOV.UK Service Manual: keep observations distinct from interpretations and use findings to decide next actions.

Mistakes beginners make

1. Asking people to approve the idea. “Would you use this?” invites politeness. Ask about their last real attempt to solve the problem.
2. Recruiting only supportive friends. Invite people because they have the experience, and include people whose current methods differ.
3. Pitching before listening. Once people hear your solution, it can shape the examples they tell you.
4. Confusing a signal with proof. A few conversations help you learn what to investigate; they do not estimate a whole market.
5. Writing interpretations as observations. Keep what happened separate from your explanation of why it happened.
6. Ignoring people who disagree. Counterexamples may show that the audience, situation, or problem needs to change.
7. Recording or sharing without clear permission. Explain what you will collect and how it will be used before the session.
8. Letting AI invent missing findings. Use it to organize de-identified notes only when permitted, and check its summary against the source.

Recap and try it yourself

Check an idea by choosing a decision to inform, talking with people who have recent experience, asking about what they did, examining current alternatives, and separating observations from your interpretations. Decide beforehand what would make you continue, change direction, or stop. Treat a small interview round as a way to learn, not as a representative survey. Use consent and privacy practices that fit your setting, and keep AI summaries tied to the notes they came from.

Try it: choose one assumption from your problem brief. Write one open question about a recent real example that could test it, plus two neutral follow-ups. Name the kind of person who could answer from experience and one alternative you need to understand. Before asking anyone, decide what answers would make you continue, revise the question, or pause. The next lesson introduces the parts of an app so you can connect a validated problem to a possible product shape.