Most roadmap prioritization frameworks assume a product manager exists to run them: someone with the job title, the calendar space, and the mandate to sit in a room scoring fifty backlog items on reach, impact, confidence, and effort. If that person isn't on your team, the fix isn't a lighter version of the same framework. It's dropping the scoring step entirely and ranking by three questions: who asked, what changes if you build it, and what's the evidence. That takes an hour, not a sprint, and it doesn't require anyone to have "product" in their title.
The Frameworks Aren't Wrong. They're Written for a Different Team
RICE, Kano, MoSCoW, weighted scoring matrices, none of these are bad ideas. They were built by and for teams with a dedicated PM function: someone whose whole job is holding the backlog, running the scoring session, defending the weights when an exec disagrees, and updating the board when priorities shift mid-quarter. That's the labor the framework assumes is free, because somewhere in the org, it already exists.
At a post-seed company, it doesn't. The "PM" is the founder between customer calls, or an engineer who inherited the backlog because nobody else would take it, or a rotating responsibility that changes hands every few months. Running a proper RICE session under those conditions doesn't produce bad scores, it produces a spreadsheet nobody trusts, because the reach and confidence columns get filled in from memory instead of evidence, and everyone in the room knows it. The framework isn't broken. It's solving for a labor problem you don't have solved.
This is the same gap P8's for-founders page is built around: the constraint at this stage usually isn't a lack of frameworks, it's a lack of someone with the bandwidth to run one properly, week after week, without it becoming theater.
What Changes When Nobody Owns "Product" Full-Time
Three things break down first when prioritization has no dedicated owner, and they compound on each other:
Scoring drifts to memory instead of evidence. Reach and impact estimates need something to point back to, a support ticket count, a churn interview, a usage number. Without someone whose job is to go get that evidence before the scoring session, the numbers get filled in from whoever's loudest or most recently on a customer call. The math still runs. The inputs are guesses wearing a spreadsheet.
The backlog becomes a request queue, not a ranked list. Every framework needs someone to actually apply it consistently across every new request. Without that owner, new asks get triaged ad hoc: whoever's around says yes or no in the moment, and the "roadmap" becomes a chronological list of whichever conversation happened most recently, not a ranked one.
Nobody's accountable for the ranking holding up later. A dedicated PM owns the consequences of a bad prioritization call, revisits it, and adjusts the next round. When the role rotates or doesn't exist, there's no one positioned to notice that last quarter's "high impact" bet didn't move anything, so the same mistake repeats with a different name on it.
A Three-Column Method That Doesn't Need a Framework Owner
Skip the weighted score. Rank by answering three questions for each candidate, in this order, and stop as soon as one of the first two fails:
- Customer. Who specifically asked for this, or would this fix, and how many of them are there? Not "users" in the abstract, a name, a segment, or a count you can point to.
- Outcome. What measurably changes if you build it, in a customer's business or in yours? If the honest answer is "it would be nice," that's a signal to deprioritize, not a soft yes.
- Evidence. What's the actual source, a call transcript, a support ticket, a usage log, a churn interview? If you can't name one, the request isn't ready to rank yet, regardless of how confident it feels.
This is deliberately closer to P8's decide-layer approach than to a scoring matrix: every ranked item has to trace back to something real, or it doesn't get ranked at all. A request that fails the evidence question isn't rejected, it's just not decided on this round, which is a different and more honest state than a fake score suggests.
Worked Example: Three Backlog Items, One Table
Here's what the three-column method looks like against three real-shaped requests a small team might be sitting on:
| Request | Customer | Outcome | Evidence | Rank |
| Bulk CSV export | 4 accounts on the Growth plan, named in support tickets | Removes a stated blocker to renewal for two of the four | 4 support tickets, one churn-risk call transcript | 1 |
| Dark mode | "Some users," no names attached | Unclear, no stated business or workflow change | Zero tickets, one internal Slack mention | 3 (not ranked this round) |
| Slack notification for failed syncs | 2 accounts, one already 30 days past a usage cliff | Directly addresses the failure mode in both churn interviews this month | 2 support tickets, 2 churn interviews | 2 |
Notice what the table doesn't have: an effort column, a confidence percentage, or a weighted total. Effort still matters, but it's a sequencing question you ask after ranking by evidence, not a variable to blend into the same score. Keeping it separate stops a low-evidence, low-effort request from outscoring a high-evidence one just because it's easier to ship.
What "How to Decide" Looks Like Without the Room
Customer-evidence prioritization is a decision method that ranks build requests by three checks, who specifically asked, what measurably changes, and what evidence backs it, instead of a weighted score run by a dedicated framework owner. It produces a shorter list than most scoring matrices, because anything that fails the evidence check simply doesn't get ranked yet, rather than getting a number anyway.
This connects directly to how to decide what to build next: a decision brief without a named source isn't a decision, it's an approval. The three-column method just makes that standard enforceable without anyone holding the "PM" title to defend it in a meeting.
Running It Weekly Without a Framework Owner
The method only holds up if it runs on a cadence, and the cadence has to survive someone being on vacation or mid-sprint. A few things make that realistic:
- Keep the three columns visible wherever requests already land, a shared doc, a pinned Slack thread, a lightweight board, not a new tool nobody opens.
- Anyone can add a row. Only rows with a named customer and a named evidence source move to "ranked." Everything else sits in an unranked queue, visibly, instead of getting silently triaged by whoever's fastest to reply.
- Revisit the ranked list weekly, not the whole backlog, just the top three to five rows, so the check stays under fifteen minutes.
- When something ships, write one line on what actually happened. That's the thin version of a decision brief, and it's what lets you tell, a quarter later, whether the ranking was any good.
The Information Gain: Why "No PM" Isn't the Real Constraint
The instinct at this stage is to treat "we don't have a PM" as the problem to solve, hire one, or find a framework light enough that anyone can run it. Neither fixes the underlying issue. The scarce resource isn't a job title, it's a standing, low-friction way to attach evidence to a request before anyone argues about priority. A solo founder with the three-column habit produces more defensible rankings than a five-person team running a weighted matrix on memory. The framework was never the bottleneck. The evidence pipeline was.
This also explains why the gap tends to reappear even after a team does hire a PM: the three-column habit, or its absence, usually outlives the hire, since it's a discipline about the backlog, not a headcount decision. Teams that skip building it early just hand the same unsourced backlog to someone with a new title.
Want a ranked list built from your actual customer calls and tickets instead of a spreadsheet you have to fill in from memory? Ask P8 for your first brief.
Product capabilities described reflect P8's current approach, not a guarantee of specific features.
