Backlog and roadmap
Rank your backlog by evidence and plan what ships in each release
If your backlog is ordered by whoever asked last, this sorts it out. We score every feature against your goals, the evidence behind it, the effort to build it and the risk it carries, then group the result into releases. Each release has a stated purpose: what it should prove before you spend on the next one.
What you get
What’s included
One combined list
Every feature, request and idea from your notes, tickets and conversations in one place, with duplicates merged.
Scoring on four factors
Each item rated on goals, evidence, effort and risk, with the reasoning written next to the score.
Ranked backlog
The full list in order, ready for your developers to work from.
Release plan
Features grouped into releases, each with what it's meant to prove.
Parked list
What we recommend dropping or holding, and why, so it stops coming back to every planning meeting.
A good fit if
- Founders with more feature requests than build budget
- Teams whose priorities shift every time a member, coach or investor asks for something
- Apps already live that need a plan for the next few releases
- Co-founders who disagree on what comes next and want a shared method to settle it
Not included
- Detailed requirements for each feature (see the PRD)
- A costed build estimate
- Re-ranking after each release (that's fractional product planning)
How it runs
From kickoff to handover
- Step 1
Collect
You send the backlog, requests, support themes and any usage data you have.
- Step 2
Agree the goals
We confirm what the business needs from the product in the coming months, since every score depends on it.
- Step 3
Score and rank
Every item is scored and ranked, with the reasoning visible so you can challenge any of it.
- Step 4
Plan the releases
We group the ranked list into releases and walk you through the plan.
Questions
Questions about Feature prioritisation & release roadmap
Which prioritisation framework do you use?
We score on goals, evidence, effort and risk, and write the reasoning down. The written reasoning matters more than the framework name, because it's what lets you defend a decision to a co-founder or a customer.
What counts as evidence?
Anything that shows demand or pain you can point to: repeated member requests, support tickets, cancellation reasons, usage data, sales conversations. A feature one person asked for once scores lower than one that keeps coming up.
We have no users yet. Can you still prioritise?
Yes. With little evidence, risk and assumptions carry more weight, and early releases are planned to produce the evidence you're missing.
How far ahead does the roadmap go?
As far as the evidence supports. The next release is specific. Later ones are written as themes, because they should change once the earlier releases teach you something.
Should our developers be involved?
Yes, if you have them. They usually have the best read on effort and technical risk, and the scoring gives that knowledge a place to count.
More from Product Strategy
Keep exploring
Often paired with this
Work with us
Ready to start Feature prioritisation & release roadmap?
Tell us about your business. We'll confirm the scope and send you a start date.