Feature prioritization: why gut feeling fails

When everything people want adds up to three times what the team can build, sorting by who asks loudest is tempting: it's fast, and nobody argues. But every slot you give to the loudest request is a slot the most useful one doesn't get.

That's opportunity cost: the value of the best option you give up by choosing another. With limited capacity, every yes is also a no to something. If CatChow spends next quarter's spare slot on loyalty points, the cost isn't only the build. It's the fewer stock-outs and happier clinics that the clinic ordering work would have delivered in that time.

So the real question about any request isn't is this a good idea? Most requests are. It's is this better than what it pushes out?

A useful test for the order of work: if the quarter suddenly ended halfway, would you be glad about what's already done? Arrange the work so the answer is yes, with the most valuable part first.

Keep opportunity cost apart from its neighbors: the build cost, the risk of failure and the upkeep after launch.

Building a feature is a one-off cost. Keeping it is not. The carrying cost of a feature is what it keeps costing every month after launch, long after the build has been paid for.

It shows up in many places. Support answers questions about it. It has to be tested again with every release. Help pages need updating, and sales has to explain it. And every new feature must be made to work alongside it, so each one adds a little to the cost of everything that comes after, and makes the product a little harder to use.

Features are also hard to remove: someone always complains when you switch one off. CatChow still maintains gift cards launched three years ago. Twelve people used them last year, and the team tests them in every release.

So a cheap feature is never free. Before saying yes, ask what it will cost to keep, not just to build.

Keep the terms apart: design before launch is build cost; what you didn't build instead is opportunity cost. And one part of upkeep grows faster than the rest: every option a customer can switch on multiplies what has to be tested.

Part of a feature's carrying cost grows faster than people expect: combinations. When customers can switch options on or off independently, a new option doesn't add one more thing to check. It doubles the number of possible setups.

With n independent on/off options there are 2ⁿ setups, and 2ⁿ − 1 of them have at least one option switched on. Five options give 31; a sixth gives 63. The team doesn't test each one by hand, but each one must work: the right price, the right box, the right invoice.

CatChow's box has five extras: treats, litter, vitamins, a toy and a dental snack. Gift wrap would be the sixth, and that “one more checkbox” would double the setups that can break.

Two habits keep this in check. Ask whether a new option really has to combine with all the others, or can come only with some of them. And retire options that almost nobody switches on: each one you remove halves the matrix.

Five shortcuts replace evidence with something else, and each feels reasonable in the moment.

HiPPO, the highest-paid person's opinion: the senior voice wins by default. It isn't wrong because it's senior; it's risky because rank replaces evidence and nobody checks it.

The biggest customer: whatever the largest client wants goes first, and the roadmap slowly becomes a custom shop for one buyer.

Copying: “a rival launched it”. You inherit their priorities instead of choosing yours, and their customers may not be yours.

The loudest voice: the request with the most messages in sales or support tops the list. Volume measures how often something is said, not how much it's worth.

Shiny object syndrome: the team drops its plan for whatever new idea excites people this month, so nothing ever finishes.

None of these signals is useless. A senior hunch, a big client's problem or a pile of support tickets is worth hearing. The mistake is letting any of them set the order on its own.

The Kano model sorts features by how they change customer satisfaction. In its simple form there are three kinds.

Expected attributes cause anger when missing, and nobody notices when they work. For CatChow: the right food, delivered on the promised day. Performance attributes please in proportion: the more flexible the delivery dates, the happier the owners. Delighters surprise people, and nobody misses them when they're absent.

Each kind earns a slot for a different reason. Expected attributes come first, because without them nothing else counts. Performance attributes are where you compete. Delighters can win affection, but only after the basics hold.

Categories also drift over time. Once everyone offers something, it stops delighting and becomes expected. A delivery-tracking link surprised subscribers years ago; today almost every shop has one, so its absence would annoy people and its presence earns no praise. Yesterday's delighter is tomorrow's minimum.

The model applies to old features as much as new ones, which is exactly why checking it from time to time pays off.

The Kano model is a lens on customer satisfaction, and only that. Three limits matter when you use it to prioritize.

First, delight doesn't earn a slot on its own. Birthday greetings for cats would probably delight some subscribers, but they serve no objective. A feature still has to move a key result; the Kano category only tells you how customers would feel about it.

Second, the model ignores effort, risk and business goals. A delighter can be expensive to build and keep, and a performance attribute can matter less to your strategy than to a rival's. Kano says nothing about either.

Third, what you've seen here is the simple version. The full model has more categories, such as features people don't care about either way, and it asks customers a pair of questions about each feature: how they'd feel if it were there, and how they'd feel if it weren't. Sorting features by your own guess about customers' feelings isn't the same as asking them.

Use Kano to understand customers, then let your criteria decide.

Kano looks only at customers. Two more lenses bring in the team and the business. Together they're known as desirability, feasibility, viability:

• Desirability: do customers want it?
• Feasibility: can we build it, with the people, technology and time we have?
• Viability: does it pay off for the business, and does it fit the strategy?

Strong ideas pass all three. Most ideas fail at least one, and the lens they fail tells you what to do next. Take the clinic ordering portal: desirable for clinics, viable for the clinic channel, but not feasible until the warehouse replacement is done. So the question isn't portal or no portal; it's when will it become feasible, and whether a smaller solution can serve clinics before then.

A quick 1-to-3 score on each lens works well for a short list. For forty rows, it's too coarse: you'll want your own written criteria, taken from your objectives, so several people can rate the same row and land close to each other.

Loud signals don't rank anything; explicit criteria do, agreed before anyone looks at the candidates. They aren't new: they come straight from the objectives and key results you already have. They rank candidate solutions inside themes; the order of the themes themselves comes from strategy, the first of the two levels of ordering in Timeframes and the roadmap disclaimer.

A typical set has four or five criteria:

• Key result moved: which one, and by roughly how much?
• Reach: how many customers it touches.
• Evidence: how strong the proof is that it will work.
• Effort: how much work it takes from everyone, not only engineering.
• Urgency, but only when a real date is at stake, such as a conference stand.

Then follow the steps in order. Start from the objectives. Turn them into criteria. Rate every candidate, under its theme, against the same criteria. Only then adjust the sequence for dependencies and fixed dates. Finally, write down the decision and why.

The order matters. Choose criteria after seeing the candidates, and people pick ones that favor their own idea. Written reasons let others challenge the decision, not the person.

A criterion is only useful if different people can apply it and land close to each other. That means each one must be answerable with evidence, not taste. “Which key result does it move, and what evidence do we have?” can be checked. “Is it exciting for our brand?” can't: everyone answers it with their own preference, and the loudest preference wins again.

A quick test for each criterion: could the engineering lead, a sales manager and the CEO score the same row on their own and get roughly the same result? If not, rewrite the criterion until they could, usually by naming the key result, the customers counted or the kind of evidence that counts.

Written criteria also help with the hardest conversation: a senior person's hunch. Experience is often right about the problem and less often about the solution. Treat the hunch as a hypothesis: what problem would it solve, and what evidence would show that? Then run it through the same criteria as everything else, and say what evidence would move it up. That respects the experience without letting rank replace evidence.

A dependency changes the sequence of work, not its priority. Priority says what matters most; sequence says what has to happen first so that the important thing can happen at all.

Inside a theme, start with the critical path from Customer needs as themes: for a clinic, reordering a diet before the shelf is empty. Then look at what that path depends on. The clinic theme needs the new warehouse system: past two clinics, orders start getting lost. No clinic admin ever sees the warehouse, yet it goes first in time, because the theme can't grow without it. That doesn't make it more important than the clinic theme: like any enabling work, it is judged by the key results it unlocks.

How it fits together: The three costs (opportunity, carrying, combinations) show why every yes matters; the loud signals show what not to trust; the lenses and criteria show what to trust; dependencies fix the order in time. Next, Scoring frameworks turns the criteria into numbers you can compare.