Every team has a list longer than the year. Prioritisation is not sorting that list. It is deciding what you will refuse, and being able to say why out loud.
Two failure modes bracket the work. One is prioritising by whoever spoke last and loudest — the founder's demo, the enterprise customer's threat, the engineer's favourite refactor. The other is prioritising by spreadsheet, where arithmetic stands in for a judgement nobody wanted to own.
A framework is not an oracle. It drags the inputs into the open — how many people, how much better, how sure you are — so someone else can point at the weakest one. Expect the ranking to move while you are still building it. A ranking that never moved is a ranking nobody argued with.
Product Sense
Product sense is the pattern library that lets you look at a proposal and feel something is wrong before you can say what. It is real, and it is earned — from shipping things, watching them fail, and sitting through enough user sessions that you have heard the objection before.
Use it to decide what is worth researching, and to move fast on small reversible calls. Do not use it to justify a six-month bet. Strong product people hold an instinct as a hypothesis and then go hunting for the evidence that would kill it.
You build it by closing the loop. Ship, then go back and look at what actually happened. Shipping without looking does not build judgement. It builds confidence, which is a different and more dangerous thing.
- Product Sense: What is it, Why it's Needed, and How to Keep it Fresh — article
- Product Sense — article
- Where does Product Sense come from? — video
Business & User Needs
A feature users love that the business cannot afford to run is a pilot, not a product. A feature the business loves that users route around is a line item that gets quietly killed in eighteen months. Neither side wins alone.
Make the business case explicit instead of implied. Which number does this move — signups, activation, retention, support cost, expansion revenue — and roughly how much? Vague benefit is how pet projects survive scrutiny.
Then look at the overlap honestly. Some of it is real: onboarding that removes confusion cuts support cost and raises activation in the same stroke. Some of it is not, and the honest version is that you are taking something from users this quarter for a reason you should be willing to state plainly.
- Balancing business needs and user needs in a product — article
- Navigating the User Needs vs. Business Needs Dilemma — article
Opportunity Solution Trees
Put the outcome at the top — one measurable change in behaviour, not "grow revenue". Hang the opportunities beneath it: the needs, pains and desires from research that would move that outcome if addressed. Then pick the one opportunity you are working on now and give it at least three candidate solutions, not one. Under each solution, the experiments that would tell you whether it works.
The structure does two jobs. It forces competing solutions to the opportunity you chose, which breaks the habit of marrying the first idea. And it keeps every solution attached to an opportunity attached to an outcome, so when someone asks why you are building this, you have a path to trace rather than a story to improvise.
A solution hanging off nothing is not a priority. It is a preference with a ticket number.
- Opportunity Solution Trees: — article
- Opportunity Solution Tree — article
- What is an opportunity solution tree? — video
Priorization Frameworks
A framework does not tell you what to build. It makes your reasoning visible so other people can attack it. When someone asks why the integration beat the redesign, "here are the four inputs and here is where I am weakest" starts a conversation. "It felt more important" ends one badly.
Pick one and apply it across the whole list. Scoring three items with RICE and the rest by instinct produces a ranking worse than either method alone, because the numbers lend borrowed authority to the guesses sitting next to them.
Watch for false precision. A 42.7 against a 41.3 is a tie. Read the output as tiers — clearly worth doing, arguable, clearly not — and spend your argument on the boundary between them.
Kano
Kano sorts features by how satisfaction responds to them. Basics earn nothing when present and lose the customer when absent — the password reset email arrives. Performance features scale roughly linearly: faster export, more storage, better matches. Delighters are the mirror image of basics: absent, nobody misses them, because nobody expected them; present, they lift satisfaction sharply.
You find the category by asking two questions per feature and reading the answers as a pair: how would you feel if it worked this way, and how would you feel if it did not? Pleased it is there, untroubled if it were not — a delighter. Untroubled it is there, unhappy if it were not — a basic. Pleased one way and unhappy the other — performance. A shrug at both tells you nobody will notice whichever way you go.
Categories decay. Today's delighter is next year's basic — the phone camera, dark mode. Delight buys a window, not a moat.
- Kano Model — article
- The Kano Model — video
RICE
Reach times impact times confidence, divided by effort. Reach is people affected in a fixed period — users per quarter, counted from your own data rather than imagined. Impact is a set scale per person: 3 for massive down to 0.25 for minimal. Confidence is a percentage that discounts the two numbers you just invented. Effort is person-months.
The discipline is in the units. Fix them once for the entire list, or you are comparing quarterly reach against monthly reach and calling the result a ranking.
Confidence is where honesty lives and where gaming happens. With no evidence on impact, 50% is not false modesty. It is the correct input. A high score built on low confidence is not a reason to build. It is a reason to run a cheap test first.
- RICE Scoring Model — article
- What is the RICE Scoring Model? — video
MoSCoW
Must, Should, Could, and Won't — this time. It is a scope agreement for one release rather than a ranking, and it works because it hands non-specialists a vocabulary they can actually use in a room.
The definition that saves it: a Must is something whose absence makes the release not worth shipping. Not important. Not strategic. Fatal. Apply that test honestly and half your Musts demote themselves inside a minute.
Cap it with arithmetic. If Musts account for more than about sixty per cent of estimated effort, you have no buffer and the plan breaks on the first surprise.
Write the Won't list down and circulate it. An unspoken no is heard as "later", and later turns up as an argument in week six.