Turn Every Request into a Capability Ticket

This is the full playbook from “Prioritize Work by What It Earns for the Business.” The book prints a shorter version at the end of that chapter, and this page keeps every step and every example.

Use this template the next time a request lands on your desk with no reasoning attached, only a person who wants it built. Don’t skip a step because the answer looks obvious. The obviously important request is the one most likely to run on assumed value instead of demonstrated value.

1. Write the capability statement. Complete this sentence: “With our product, a customer can [do something specific] that they could not do without us.” If you can’t complete it cleanly, stop: the request isn’t defined well enough to prioritize. Build it now and you build an activity, not a capability.
2. Assign the economic category: Retain, Expand, Deliver More Cheaply, or Acquire. If more than one applies, name the primary one. Choose the category the strongest evidence supports, not the one that makes the request sound most urgent.
3. Attach a number and a confidence level, using the arithmetic of the category. For Retain, multiply the customers at risk by the average revenue and by the remaining lifetime. For Expand, multiply the expansion opportunity by the expected uplift. For Deliver More Cheaply, multiply the hours saved by the loaded cost and by the accounts affected. For Acquire, use the qualified pipeline blocked by the unimplemented change. Mark each figure High, Medium, or Low confidence; in a prioritization meeting, a labeled guess beats an unlabeled one.
4. Run test one before test two. Price what it costs you to build and to operate this capability. Compare the payback period with your target for that delivery type. If it fails the target, stop, even when the customer wants it badly, and say so plainly instead of building it to avoid the conversation.
5. Confirm the customer’s side of the ledger with a number, only after test one passes. Does the capability let them earn revenue they did not have, protect revenue they were about to lose, or cut their own cost measurably? Put an approximate figure on the answer and label its confidence as in Step 3. If the answer is no, or the figure is too small for the customer to notice, the capability will not retain them, whatever it costs you to build.
6. Sort the queue by category first, number second. Retain before Expand, Expand before Deliver More Cheaply, Deliver More Cheaply before Acquire. Inside a category, sort by the smaller of the two value figures: yours from Step 3 and the customer’s from Step 5. Both sides must hold, and the conservative bound is the honest one. A capability worth a million dollars to you and almost nothing to the customer is a retention claim that fails at the first renewal conversation.

Try this with AI.

“Here is next quarter’s ordered queue, with a category and a dollar figure on each item. Attack the order: which item is ranked on status rather than evidence, and which number would I least be able to defend to a CFO? Use only a tool my organization has approved for internal roadmap and cost data.”

Put every meaningful backlog item through these six steps for one planning cycle. The argument about whose feature matters more, which nobody can win because it’s a status contest, turns into an argument about whether a specific number is correct, which people can win, because a number can be checked. An eleven-hundred-item backlog with no shared unit of value is eleven hundred unresolved status arguments in the form of a spreadsheet.

All of the playbooks are listed on the playbooks page.