Turn User Research into a Product Roadmap: Evidence, RICE and Capacity
Synthesize supplied notes with participant-level counts, then author a separate roadmap with testable requirements, consistent estimates, dependencies and three capacity scenarios.
Fastest way
Ask your AI to do it
Paste this into the AI agent you already use:
Use User Research Studio to synthesize permitted notes without inventing participants or quotes. Review themes, contradictory evidence and participant denominators, then author a separate Product Roadmap Studio input with traceable evidence, acceptance criteria, consistent RICE estimates and team capacity. Reconcile scenarios and make tradeoffs explicit before commitments.
Can research findings become a defensible roadmap?
User Research Studio v1.0.0 organizes supplied observations into evidence-linked themes and actions. Product Roadmap Studio v1.0.0 turns a separately authored plan into specifications, RICE scores and capacity scenarios. Both use Python 3.10+ standard-library tools offline. There is no automatic converter: the agent must review the findings and author the product decision.
Count participants, preserve disagreement and verify sources
Read the research package input reference. Prepare exact observation text, stable observation IDs, anonymized participant IDs, segments and original locations. Hash the original notes bytes and place notesHash in the authored study. The agent writes interpretations and support/contradiction references; the helper validates references, not the truth of a quote.
- One participant with several notes still counts once in a theme fraction. The denominator is all supplied unique participants, or all participants in the selected segment. Inspect minority and contrary evidence even when a filtered finding disappears.
- Study frequency is not market prevalence. Severity, effort and the proposed action are reviewed judgments; a matching hash establishes source identity, not research validity or causality.
Run the two independent fictional examples
Install and read each complete package. Run each command from its own package directory into a new output folder. The examples use different fictional briefs and do not transfer data between tools. For a real task, author a reviewed roadmap input from the accepted findings and retain source locations.
Review research setup and source requirements
Review roadmap setup and planning rules
# From the User Research Studio package folder:
python3 scripts/build-research.py --input examples/study.json --notes examples/notes.json --output ./practice-research
# From the Product Roadmap Studio package folder:
python3 scripts/build-roadmap.py --input examples/plan.json --previous examples/previous.json --demo --output ./practice-roadmapTranslate an accepted finding into testable scope
- Write the user problem, owner, goal, decision, non-goals and acceptance criteria. Preserve observed baselines separately from targets, and keep confidential research out of a public handoff.
- Use one reach window and person-day units. RICE equals reach × impact × confidence / effort, with confidence between zero and one. Check a calculation independently; high priority does not turn an estimate into achieved adoption.
- Enter available team capacity after overhead. Prerequisites must finish in an earlier release; blocked or deferred dependencies can leave descendants unscheduled. Lean/Baseline/Expanded use 70%, 100% and 125% capacity without changing effort.
Review both the evidence and all exported scenarios
In practice-research/index.html, compare Findings, Evidence and Action plan with analysis.json, actions.csv and original notes. In practice-roadmap/index.html, follow one dependency through all three scenarios, inspect unscheduled reasons and reconcile team usage with scenarios.json. Filters change views, never the exported complete plan.
Inspect the current example output → — Compare the visible result with the exported files and checks described in this section.
Inspect the current example output → — Compare the visible result with the exported files and checks described in this section.
Make the tradeoff explicit before a release commitment
Read every specification, quality note, change record and stakeholder brief. The greedy schedule is inspectable rather than optimal; a suggested slot is not a customer promise. Deliver approved evidence and input files alongside the plan. Tracker updates, participant outreach and actual release work are separate actions.