Product research workflow
Build a Product Research Knowledge Base Before Writing a PRD
Turn approved research notes, support and sales signals, and prior decisions into a source-backed evidence base for a defensible PRD.
Article packet
Workflows
Product managers, UX researchers, and product operations teams preparing a PRD or roadmap review
8 min read
01
Start with one product decision and its approved evidence boundary.
02
Trace each requirement to dated research, support, sales, or decision sources.
03
Keep observations, interpretations, assumptions, contradictions, and open questions separate.
See the source-backed workspace a reviewer inspects
The product proof below is a genuine Wenlan desktop capture from the app's deterministic test fixture. It shows recently refined Pages with source counts plus a review queue for conflicts and newly available sources. The fixture is not customer data; the same review surface supports product-research evidence.
- 01
Approve the source boundary
Include only dated research notes, support or sales passages, and prior decisions the product team is allowed to inspect.
- 02
Distill one product decision
Build one maintained Page for the question under review, with source IDs and contradictions attached to each consequential claim.
- 03
Review before drafting
Open the cited passage, check the current revision and stale state, then carry only supported or explicitly unresolved requirements into the PRD.
Worked PRD evidence packet
This is an example structure, not a claim about your users. Replace every row with approved evidence from the product decision you are reviewing.
- Evidence input
- A dated interview observation, support passage, sales note, or prior decision with an exact source location.
- Requirement candidate
- One reviewable statement that separates the observed problem from interpretation, scope, and assumptions.
- Review result
- Supported, contradicted, stale, or unresolved, with the reviewer and next check recorded before PRD approval.
01
Start with one product decision, not a company-wide archive
Before drafting a PRD, build one product-scoped evidence base for the decision under review. Collect only approved interview notes, support or sales notes, research artifacts, and prior decisions that the team can inspect; the goal is to make each requirement traceable, not to create a generic repository of every conversation.
Wenlan can keep those supported Markdown, text, text-extractable PDF, folder, and read-only Obsidian sources connected to source-backed Pages, citations, revisions, stale state, and review. It does not decide the roadmap or turn a source into an approved product requirement.
02
Freeze the source boundary before synthesis
Write down the product area, review question, date range, included source types, and excluded material before asking an agent to synthesize. A narrow boundary makes it possible to tell whether a requirement is supported by an observed user need, a team interpretation, an assumption, or a decision that needs to be revisited.
Keep source dates, document versions, and exact headings or passages in a small source register. If a note is incomplete or a source is not approved for this product decision, record it as unavailable rather than silently filling the gap.
- Approved interview or research notes: preserve the observation and its source location.
- Support or sales notes: separate a repeated problem signal from an unverified request.
- Prior decisions: record the decision date, rationale, scope, and evidence available then.
- Assumptions and open questions: keep them visible instead of presenting them as user facts.
03
Build the evidence chain from note to requirement
Use one row or Page section per important requirement. Link the requirement to dated source passages, distinguish reported observations from your interpretation, and record contradictory evidence before deciding whether the requirement should remain, narrow, or stay unresolved.
The same chain should survive a PRD review: a reviewer can open the source, see the current revision, understand which assumptions remain, and follow how a prior decision changed. If a source changes, refresh only the affected Page and leave the previous revision available for review.
- Record the product question, source ID, date, exact location, and scope.
- Classify each statement as observation, interpretation, assumption, decision, or open question.
- Attach acceptance or rejection rationale to the evidence, not just to a meeting outcome.
- Compare conflicting signals and preserve the contradiction when the evidence cannot resolve it.
- Mark unsupported or stale requirements before they enter a PRD draft.
A bounded product-research knowledge workflow
wenlan status
wenlan sources add ~/Research/product-notes
/distill <product decision>
/pages <product decision>
/lint
/curate04
Draft the PRD only after the evidence is inspectable
A PRD can summarize the evidence base, but it should not hide the evidence behind polished prose. Before the review, check that every requirement has a source path or an explicit unresolved label, every important assumption has an owner or next check, and every prior decision still matches the current source set.
This makes the document useful even without Wenlan: a small evidence register, requirement-to-source map, contradiction log, assumption list, and decision history are a repeatable product-research practice rather than a vendor-specific format.
05
Know what this workflow does not automate
Wenlan does not transcribe meetings, redact personally identifiable information, recruit participants, ingest analytics, connect Jira, Linear, Slack, or a CRM, automatically prioritize opportunities, generate a complete PRD, choose a roadmap, or claim a product outcome. Use maintained sources and human review for those decisions and controls.
It also cannot make an unsupported request true. Keep the source, claim, date, limitation, and review state visible so an agent can help organize evidence without replacing the product team's judgment.
Make one product decision traceable
Start with an approved source set, map requirements to dated evidence, and keep contradictions and open questions visible before the PRD review.
FAQ