Decision Library
Every roadmap item competes with what it displaces
A product decision is rarely a matter of build or not build. It is a choice between scopes, sequences and the other work a team could finish in the same weeks. A Decision Room treats the requested feature as one option among several and asks which one answers the user's problem soonest and with least regret.
Five honest options
Build the full feature. Build a thin version that solves the most common case. Test before building, with a placeholder that measures how many people reach for the feature, or a manual service delivered by the team behind the scenes. Buy or integrate a component. Do nothing for now and measure the workflow you already shipped.
Doing nothing is a real option with a real cost, and the room prices it: customers who leave, deals that stall, and support hours spent on the workaround.
What counts as evidence of demand
Behavior outranks opinion. Usage logs, support tickets that name the problem, deals lost with the reason recorded, and customers who agree to pay for the change in advance are strong evidence. Feature requests counted by volume are weaker than they look, because the loudest accounts are rarely a fair sample of the ones that matter most.
Interviews help when they ask about the last time something happened rather than what someone would do in future. A promise to use a feature is a prediction, and the Inspector marks it that way until usage confirms it.
Sort by kind before cost
In 1984 the researcher Noriaki Kano and his colleagues described how customers react differently to three main kinds of product quality: basic expectations whose absence angers people, performance qualities where more is steadily better, and delights nobody asked for. A feature in the first group protects revenue. A feature in the third can win attention, but it rarely rescues a product missing the first.
Sorting candidates this way before scoring stops a team from comparing a missing essential with a pleasant extra as though they were the same kind of thing.
How the room argues a roadmap item
The requested feature gets a Champion, and so do the thinner version, the test and the wait. The Challenger presses on the claim the request leans on most, usually how many customers need it and how badly. The Craftsman checks whether the estimate is believable for this team, given what similar work took last time, and the Grandfather asks which choice is hardest to take back once customers depend on it.
The Verdict states which scope leads, what the losing options got right, and the usage figure that would change the order. The product owner records the Human Decision beside it.
What to weigh
Problem severity
How much the current gap costs a real user in time, money or abandoned work.
Evidence of demand
Behavior and advance commitments from the customers who matter, weighed above requests and compliments.
Time to learning
How quickly the option produces a signal the team can trust about whether to go further.
Build and upkeep cost
Design and engineering weeks now, plus the maintenance the feature adds to every later release.
Opportunity cost
The work that slips when this option takes the team's next quarter.
Reversibility
Whether the change can be withdrawn without breaking habits customers have already formed.
Where it goes wrong
Roadmap theater
A decision meeting is held to end an argument rather than to test it.
Merged compromise
Two rival ideas are combined into a larger scope that serves neither well.
Survivor requests
Requests come only from customers who stayed, so the reasons others left never reach the backlog.
Reporting, export, or wait
A team of six engineers is asked for in-app reporting. The full build is estimated at 14 engineer-weeks, a CSV export at 2, and waiting a quarter costs nothing to build. Support logs show 340 tickets in six months asking to get data out of the product, while 31 of 220 customers have asked for charts specifically. Two deals worth $96,000 together stalled on reporting. With weights of severity 20, demand 25, time to learning 20, cost 15, opportunity cost 10 and reversibility 10, the export leads: it answers most of the 340 tickets in two weeks and shows within a month how many customers then build their own charts. The Verdict names the condition that would promote the full build: more than a quarter of exporting accounts rebuilding the same report by hand.
Questions
- Can I bring a backlog of twenty ideas?
- A room works best on a few rival answers to one problem. Bring the three or four candidates competing for the same slot, and the room compares them on one set of weights.
- Who decides what ships?
- The product owner does. The Verdict is the room's reasoned reading of the evidence, and the Human Decision is kept apart from it, so a later review can see both.
Bring Argumont a Decision worth challenging.
Start with a paid 60 day pilot on your own real Decisions.