In a note about a digital project for children, I described parents’ need for safe, enjoyable content. But the content side was not ready: creators could not fill the gap at the required speed and quality. A need was not enough. That matters whenever market research becomes a build decision.
The workflow
- 01Need
- 02Behavior and adoption
- 03Ecosystem readiness
- 04Limited test
- 05Conditional decision
A need is not demand
A person saying a problem bothers them tells you about their experience. It does not tell you whether they will adopt a new solution, pay or change a habit. Separate these questions and their evidence. Acknowledging a problem starts research; it does not authorize a product build.
In a fictional appointment service, someone may hate missed appointments but prefer a reminder to moving all their data into an application. Research behavior, costs and alternatives, not whether they like the application idea.
Start with what people do now
Ask about the last occurrence, how the person tried to solve it, and what helped or stopped them. Observe steps, tools and waiting. GOV.UK recommends understanding users and their goals through evidence, interviews and observation. Use that method instead of asking people to predict the future.
What happened last time? Which alternative did you use? What made it difficult? What happened when you did nothing? “Would you use my product?” alone is weak evidence. A polite answer is not a commitment. Record the person’s context rather than assuming every answer represents the market.
Test adoption separately
A solution costs more than its price: learning time, migration, changed habits, a manager’s approval or trust. Record barriers before forecasting growth. Use a small prototype, manual service or realistic task. Explain that it is a test and do not promise unproven results.
Did the person finish? Where did they stop? What needed explanation? Did they choose to return? Sample size and selection limit generalization. Failure to finish may reflect the test design itself, so inspect the cause before judging the product.
Map the ecosystem
Some products depend on creators, suppliers, partners, licences or support. Who must do what for the user to receive value? Are they available and willing? Can capacity meet quality and timing? A market can need something the ecosystem cannot yet deliver.
Content readiness was the original gap. That does not prove all children’s content ideas fail. It asks who provides content, at what quality, cost, cadence and usage rights. Do not postpone the answer until after building.
Make a conditional decision
State options: build now, test, narrow the scope or defer. For each, describe evidence, gaps, cost and the condition that would change your view. Make the next decision clear rather than adding pages.
In a fictional case, try a manual service with a defined group before building a platform. If migration is the barrier, test it first. If a supplier is not ready, interface work will not fix it. Name an owner and review date for missing evidence.
Keep fact and interpretation apart
Use four fields: documented observation, interpretation, assumption and action. Link observations to dated sources without publishing personal information. Preserve conflicts. Do not make one case a sector-wide verdict or hide gaps behind confident language.
Good research may end in deferral, smaller scope or a new question. Ignoring an obstacle because you love the idea is the failure. Before the decision meeting, write the strongest argument against your recommendation. If you cannot, consider whether you searched beyond your expectations.
A small exercise
Choose an idea. Write evidence that the problem exists, people will adopt the solution, and the ecosystem can deliver it. An empty line is your next research question, not a space for optimism.
Sources and limits
The project story comes from Hossam’s original note. The steps and examples are illustrative, not private project data or outcome promises.