A working reference

The Decision Desk

Eight questions worth answering before an enterprise product commits money, scope or a date — and the short frameworks that make each one answerable in a meeting.

Puja Pandey Enterprise product, CRM and data Updated September 2026

How to use this

None of these are methodologies. Each one is a short list of things that have to be said out loud before a decision holds up later, written so you can put it on a screen in a meeting and work down it.

Four of the eight have a blank worksheet underneath them. Fill those in for something you are actually deciding this quarter — what you type stays in your own browser and is never sent anywhere — then use Print worksheet at the bottom to take a filled copy into the room.

01

The trade-off record

What moved down when this moved up?

A priority is not a score. It is a statement about what now happens later, and it only means something once someone names the thing that got displaced. If nobody can, the list is a queue in which everyone believes they are near the front.

Record, at the point of decision
What drops
A specific item, by name. Not “other work” and not “capacity.”
Who feels it
The team, function or customer group that waits, and roughly how long.
If it never returns
The honest consequence. Sometimes the answer is “nothing,” which is itself worth knowing.
Who was told
The person who made the request, in the room, not by summary afterwards.
Use it when A request is being accepted into a plan that is already full.
Worksheet 01 · Trade-off record Stays in your browser
02

The decision underneath the request

What should someone be able to decide better?

Large requests tend to arrive already shaped as solutions — a single view, a unified record, a dashboard. The request is rarely wrong, but nobody has yet said what it is for, and the gap between the broad answer and the narrow one usually has a budget attached.

Answer before it becomes a funded item
User decision
What the person has to determine at the moment of work — not what they would like to see.
Minimum information
The least they need to decide it reliably, and where each piece comes from.
Failure path
What happens when a source is unavailable, or two records disagree.
Outcome measure
Whether the decision gets faster without more wrong ones.
Use it when A solution arrives as a requirement, usually from someone senior.
03

The scope cut

What comes out when the date will not move?

The instinct is to cut from the bottom of the feature list. That produces a release in which everyone can start the task and nobody can finish it. Cut breadth instead, and defend the things that make the narrower version usable — which is where the pressure actually lands, because quality standards are the first thing proposed as phase two.

Two lists, in this order

Narrow who and where

  • One user group, not five
  • One journey, not the lifecycle
  • One region, not every market
  • One source system, not every integration

Defend what makes it usable

  • A complete path through the task you kept
  • Security, accessibility and quality standards
  • A recovery path when something goes wrong
  • Enough measurement to learn from real use
Test Can the intended user still finish the job, safely, and get something out of it? If not, the release was broken rather than shrunk.
04

The complete slice

Fewer people served fully, or everyone served partly?

Choosing one journey end to end is the easy half. The hard half is holding it once every group that is not in the first release finds out, each with a reasonable case for why theirs should be.

Four tests before committing to a slice
01 Value — is this case frequent or painful enough to matter?
02 Feasibility — can the people behind the scenes actually complete it, every time?
03 Risk — can the controls and service expectations be met at this scope?
04 Learning — will it answer a real question about the rest of the product?
Use it when A first release has to be smaller than the ambition, and someone has to decide who waits.
05

The five-line bet

What evidence would change our minds?

Most roadmap items are not built to be disproved. They are built to be delivered, and once something has a budget line the organisation's energy goes into making it happen rather than checking whether it should. Five lines, written before it starts, are what separate a bet from a plan.

Worked example
Outcome
Fewer avoidable support contacts.
Assumption
People make contact because they cannot see where their request stands.
Evidence
Reasons for contact, observation of the journey, results from a limited status-view pilot.
Review date
Six weeks after the pilot opens.
Decision
Expand, revise, or stop.

The review date is the line that gets dropped, and it is the one that makes the rest real: it is a commitment to whoever funded the work that somebody will come back and say whether it did what it was meant to. And if the true cause turns out to be something else — unpredictable resolution times rather than poor visibility — contacts may rise rather than fall. That is a good outcome, as long as the plan is allowed to respond to it.

Use it when Anything significant is being funded, or a roadmap is being agreed for a period.
Worksheet 05 · Five-line bet Stays in your browser
06

The stop condition

What will we decide at the end of this pilot?

If the only honest ending to “we will use the evidence to decide whether to ___” is show people what the technology can do , it is a demonstration with a budget rather than a pilot. The criteria have to be agreed while everyone is still optimistic, because after the demo goes well nobody in the room wants to be the person writing down what would make them stop.

Bound it
— One case, one document or request type
— Named sources of truth, each with an owner
— A person reviewing before anything moves downstream
— A defined fallback for what does not fit the pattern
— A baseline taken from how the work runs today
Measure the whole task
Accuracy
And separately, the errors that actually cause harm downstream.
Correction effort
How much the reviewer changes before it is fit to pass on.
Total handling time
Two seconds to produce can be four minutes to verify and repair.
Decide in advance Expand if it clears the value and risk criteria · Revise if one specific, fixable thing is in the way · Stop if it fails, or a risk appears you are not willing to carry.
Worksheet 06 · Stop condition Stays in your browser
07

The four lenses

Which of these are we actually reporting?

Four different questions get compressed into one word in most product reviews, and the compression is where an organisation starts believing things that are not true. Reporting tends to stop at released , because it is the easiest to evidence and arrives soonest — and it gets read as valuable.

Four questions, four kinds of evidence
Done
Does the increment meet the quality bar the team agreed to? Evidence: a quality check.
Released
Is it available to the people it was built for? Evidence: availability.
Adopted
Are those people using it for the intended task? Evidence: real task usage.
Valuable
Is it moving an outcome anyone cares about? Evidence: the outcome itself.
Note Four lenses, not four gates. Value can be tested long before a broad release, and quality work never finishes. Drawn as a funnel, this promises something the model does not deliver.
08

The adoption diagnosis

Why is nobody using it?

Low usage is a symptom, and more training is a treatment for exactly one of its causes. None of the four show up in a usage dashboard — somebody has to watch a person do the task and ask why they opened a spreadsheet instead.

Cause → matched response
Awareness
They do not know it exists, or when to use it. A better entry point, not a course.
Workflow
They cannot use it at the moment of need without entering the same thing twice. Change the workflow.
Trust
What it shows is not accurate or current enough to act on. Fix the data. Nothing else will do.
Value
It does not beat the workaround they already have. The capability itself is now the question.
After any change Measure task completion and the intended outcome, not clicks. More clicks can mean more friction.
Worksheet 08 · Adoption diagnosis Stays in your browser

Take it into the room

Printing gives you the four worksheets with whatever you have typed into them, on their own pages, without the commentary. Leave them blank and it prints as a set of forms to fill in by hand.

On the sources. “Done, released, adopted, valuable” is a teaching frame of my own, not a Scrum model. The 2020 Scrum Guide defines the Product Owner's accountability for value and the Definition of Done as a quality commitment; the four lenses sit on top of that. Definition of Ready is not a required Scrum commitment, and release to production is not a universal Definition of Done requirement.

Every example here is illustrative. No client work, engagement or result is described.

Puja Pandey · pujapandey.com