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.
About this guide
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.
Worked example
Build a product-research knowledge base for a PRD
A fictional three-note exercise: turn conflicting requests into one limited PRD decision, then name what needs more research.
Try this task
Using only the three research notes, choose the smallest defensible PRD decision, preserve the conflict and unknowns, and state which choices require more human product judgment. Cite every conclusion with [[filename]].
Expected reasoning
Specify a source-linked draft with a human review step before sharing. Do not commit automatic publishing, export, storage defaults, team permissions, or a broad roadmap from this small conflicting sample.
Why keep this connected
Three notes can be compared in ordinary files. A source-linked research wiki becomes useful when revisions, contradictory requests, and the boundary between evidence and product judgment must remain visible in a living PRD.
Review boundary
Check each preference against its note, especially review-before-sharing versus automatic publishing and export; keep storage defaults, permissions, and broader demand unresolved.
Inspect the example in Wenlan
Wenlan v0.18.3 interface displaying data read back from an isolated test run. The sources are fictional and the reference answer was written for this exercise. No automatic AI generation or approval is shown.
After the cited source changed, Wenlan marked the page as out of date and kept its original text. The ‘updating…’ label indicates a pending rebuild here; it does not show a completed correction. Review the changed source before rebuilding and accepting a new answer.
Source files
Open a file to read its complete authored Markdown.
The source files are the same authored English dataset in all three locale views.
01research-note-a.mdResearch note A — source-linked review
# Research note A — source-linked review Fictional moderated session note; no real participant or customer is represented. The evaluator wanted an imported Markdown note to produce a draft answer with a link back to each source passage. They preferred to review the draft before it became a shared page. The note records one narrow workflow preference, not demand for automatic publishing, team permissions, or a mobile app.
02research-note-b.mdResearch note B — local-only request
# Research note B — local-only request Fictional research note; no real participant or customer is represented. The evaluator asked to keep source files and drafts in a local workspace and rejected an external export for this exercise. They said an explicit review step matters more than a polished final page. The note does not establish that every user wants local-only storage or that export is never useful.
03research-note-c.mdResearch note C — conflicting product request
# Research note C — conflicting product request Fictional product-research note; no real participant or customer is represented. A separate request asked for a CSV export of the source-linked draft and also asked for automatic publishing after import. The request conflicts with note B's local-only preference and note A's review-before-sharing preference. The sample is too small to resolve the conflict or justify a broad roadmap.
Reference answer
Reference answer: choose a reviewable draft, keep the roadmap narrow
The three fictional notes support one limited PRD decision: imported Markdown may produce a source-linked draft that a person reviews before sharing. Export, automatic publishing, storage defaults, and broader permissions remain unresolved because the notes conflict and the sample is small.
Product-research reference for a PRD
Limited decision
Add one narrow requirement: an imported Markdown note can produce a draft answer with links to its source passages, and a person must review the draft before it becomes a shared page. This is supported by the source-linked review preference and the request for an explicit review step. research-note-a.md research-note-b.md
Keep unresolved
Do not commit automatic publishing. Note A prefers review before sharing, note B prioritizes local-only drafts, and note C separately requests automatic publishing and CSV export. The notes conflict and are too small to decide a universal storage or export policy. research-note-b.md research-note-c.md
A product owner must decide whether to run more research before choosing export, storage defaults, team permissions, or a broader PRD. Those decisions are not established by this packet. research-note-a.md research-note-b.md research-note-c.md
Changed source: research-note-c.md
Expected update after this change
The reference's statement that note C requested CSV export becomes stale. Revision 2 clarifies that the request was for a locally saved source-linked review report, not CSV export. The automatic-publishing conflict, narrow review-before-sharing decision, and unresolved storage or permission questions remain; a human product owner still decides whether more research is needed.
# Research note C — conflicting product request, revision 2 Fictional product-research note; no real participant or customer is represented. A separate request asked for a source-linked review report that can be saved in the local workspace. It did not request CSV export. The same request still asked for automatic publishing after import, which conflicts with note B's local-only preference and note A's review-before-sharing preference. The sample is too small to resolve the conflict or justify a broad roadmap.
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