Turn a customer problem into a product brief
Product ideas arrive without evidence or a clear decision to make.
For teams considering a new product or a meaningful change to an existing one.
What good looks like.
A product brief names the user, requirements, uncertain assumptions, and the next test the team has agreed to fund.
- Starts when
- A recurring customer need is nominated for product review.
- Accountable owner
- Product lead
Where AI could help.
AI could group source-linked needs and draft questions for the brief. A researcher checks quotations; the product lead decides which problem merits testing.
How the work could move.
A suggested process to adapt to your team. Each handoff needs a clear owner and a visible check.
Bound the problem
Researcher
Create an evidence table with observed behavior, customer language, context, and source links.
Ready when: The need is distinguishable from a proposed feature and contrary evidence is included.
Define requirements
Product lead
Draft the intended user, use case, measurable requirements, exclusions, and existing alternatives.
Ready when: Each requirement has a reason and a way to assess it.
Check feasibility
Sourcing and operations
Add a constraint note covering materials, lead time, unit-cost assumptions, and operational changes.
Ready when: Unknown constraints have an owner and a test rather than an invented answer.
Decide the next test
Product lead
Record an approved prototype or research test, budget boundary, rejection criterion, and review date.
Ready when: The test owner accepts the brief and the decision maker can explain what would stop the idea.
Explore the setup, checks, and exceptions
Start with your tools.
Keep a versioned brief in your document tool and link its evidence in the research repository. A product board can track test owners without replacing the specification.
When things go wrong.
- A single loud request is evidence to investigate, not a count of market demand.
- If requirements conflict, keep the tradeoff open for the product lead.
- If the cost or material assumption changes, revisit feasibility before proceeding.
A useful first step.
Choose one proposed product and separate three evidenced needs from three untested assumptions.
What to measure
Track briefs with traceable evidence, assumptions tested, and days from proposal to next-test decision.
Want this working with your team and tools?
Build it yourself, adapt what you already have, or work with us. We can help you choose where to start and handle the technical build.