Skip to content
DWKD
Lesson · The full series

Cut a roadmap in half without losing the outcome

You will learn

Roadmaps do not grow because teams lack discipline. They grow one defensible item at a time. A method for cutting that survives the people who asked.

Fluent 20 min Product

Roadmaps do not grow because teams lack discipline. They grow because every item on them was agreed to by somebody with standing, one at a time, in a different room, and each one was reasonable when it was added.

That is why cutting by judgment fails. Judgment puts you in a negotiation with eleven people who each have one item and a good reason for it, and you will lose eleven times. What works is a method that does the cutting before the conversation starts, so the conversation is about the outcome instead of about whose feature survived.

Write the outcome first, in one sentence, with a number and a date

Before you look at a single item, write what has to be true when this is done. Not a theme. Not “improve the booking experience”. A sentence somebody could check.

“By the end of March, a scheduler can confirm a booking without opening a second system, and confirmation time falls from six minutes to under two.”

That sentence is the instrument. Every item on the roadmap now gets tested against it rather than against its own merit — and this matters, because almost every item has merit. Merit is not the question. The question is whether this outcome fails without it.

If you cannot write the sentence, stop. You do not have a roadmap that can be cut; you have a list of work, and the right next move is to find out what it is for. That conversation is uncomfortable and it is much cheaper than building the list.

Four questions that do the actual cutting

Run every item through these, in order, and write the answers down where other people can read them.

Does the outcome fail without this? Not “is it valuable”. Fail. If the scheduler can still confirm a booking in under two minutes without it, it is not in the half you keep, however good it is.

Is this the cheapest way to get this part of the outcome? Items frequently survive because of the need underneath them, not because of the thing proposed. A configuration screen and a hard-coded default both satisfy “the rule can change”. One of them is four days.

Who asked for it, and would they notice in March if it were missing? These come apart more often than anybody expects. Ask the person directly. A surprising share of items are things somebody mentioned once and has since stopped caring about, kept alive entirely by the document.

What breaks if this happens in the second half instead? Most of the time the answer is nothing, and “later” is a much easier conversation than “never”. Save “never” for the items that genuinely conflict with the outcome.

Anything that survives all four is not a favorite. It is load-bearing.

That is the opening. The rest of the lesson — the remaining sections, the exercise and the check-your-understanding questions — is behind the gate below.

This lesson requires full access.

Create an account to explore the published free lessons. This lesson requires full access; signing up does not purchase access or enroll you in Academy.