Scoring frameworks exist to settle arguments between people. Alone, you are managing your own preference for building over selling.
Feature prioritisation frameworks — RICE, ICE, weighted scoring — all exist to settle arguments between people who want different things. Alone, you are not resolving a disagreement between departments. You are managing your own preference for building over selling.
A prioritisation system that produces a ranked list of forty items has not helped you.
RICE scores reach, impact, confidence and effort. Three of those four break at solo scale.
Reach needs data about how many users touch a feature. With sixty customers, the honest answer to reach is usually a guess with a decimal point on it.
Impact is scored on a fixed scale, which invites you to assign a 3 to the thing you already want to build. Nobody is present to challenge the number.
Confidence is where the framework becomes circular. You assign confidence based on how sure you feel, then use the result to justify the decision you felt sure about.
Effort is the one that survives, because you genuinely know how long things take. A framework where one input of four is reliable will produce a confident ranking of your own biases.
Replace the score with a question: does this move the number I named on Monday?
That works because it borrows the prioritisation from a decision you already made. Your weekly cadence names one priority; features either serve it or they wait. No scoring, no committee, no invented reach figure.
Three follow-ups when the answer is yes, and all three must also be yes:
The rule that saves the most time: the third request builds it.
One request is one person's workflow. Two might be coincidence. Three separate customers asking unprompted for the same thing is a pattern, and patterns are worth building for. Until then, log it and say so honestly.
| Situation | Response |
|---|---|
| One customer asks | Log it. Tell them it is logged. |
| Three customers ask | Build the smallest version |
| A prospect asks before paying | Do not build. Prospects who need a feature to buy usually do not buy after you build it. |
| Your largest customer asks | Judgement — but check it serves the job, not just them |
| You thought of it yourself | Highest-risk category. Wait for a request. |
That last row is the uncomfortable one. Features founders invent are the most likely to be built and the least likely to be used, because building is more enjoyable than selling and the roadmap is where that preference hides. For the fuller version of saying no to feature requests — including the actual wording to use — see the dedicated guide.
Keep a visible, written list of what you have decided against, with the reason and the date. Two benefits.
It stops the same idea resurfacing every six weeks and consuming a fresh hour of deliberation. And when three customers do ask for something on it, the note tells you what changed, which is genuinely useful information about your market.
The list also connects to the job your product does. A request that does not serve the job is a request to become a different product, and declining it is the decision that keeps the product coherent.
If your roadmap has more than five items, it is a wish list. Five is roughly what one person can hold in mind and finish. Anything beyond that is being stored, not planned.
Frequently, and it is the hardest call to make.
If activation is under 20%, no feature will help — people are not reaching the value you already built. If churn is concentrated in the first sixty days, the same. If nobody is signing up, the constraint is upstream of the product entirely.
Check those three before opening the roadmap. The four metrics that matter covers where to look, and the churn framework covers diagnosing the second one.
Test each one against the single priority you named at the start of the week. If you cannot draw a straight line from the feature to that number, it waits. Scoring frameworks exist to settle disagreements between people, and alone there is no disagreement to settle.
Three of its four inputs break at small scale. Reach needs usage data you do not have, impact is self-scored with nobody to challenge it, and confidence is circular — you assign it based on how sure you feel, then use the output to justify that feeling.
When three separate customers ask for it unprompted. One request is one person's workflow and two might be coincidence. Requests from prospects who have not paid are the weakest signal, because they usually do not buy after you build it.
Treat them as the highest-risk category and wait for a request. Features founders invent are the most likely to get built and the least likely to be used, because building is more enjoyable than selling and the roadmap is where that preference hides.
Five items at most. That is roughly what one person can hold in mind and finish. Anything longer is a wish list being stored rather than a plan being executed.
When activation is under 20%, when churn clusters in the first sixty days, or when nobody is signing up. In all three cases the constraint sits outside the product, and shipping a feature will not move it.
Tell Marcus your current bottleneck and what is on the list. You get one thing to build and a reason for everything else waiting.
Try GhostCoach free →14-day free trial · cancel anytime · 30-day money-back on Lifetime