Good / Better / Best.

The pattern is familiar. Sales committed to a date. Engineering estimated against best-case scope. A supplier slipped, or a requirement landed late, or someone discovered that the new building does not have the cabling the design assumed. Now the deadline is two weeks out and the realistic delivery is six weeks of work.

The reflex is to push the team. Then to argue the deadline. Then to write a long email about which features are essential and which are nice to have. None of these work, because none of them give the customer a decision they can actually make.

"Essential vs. nice to have" is a binary the customer cannot price. They do not know what each feature costs in delivery time. They do not know what they would have to give up. They will hold the line on the full original scope, because that is what they bought.

Three versions of the same outcome, each with a price and a delivery date. The customer chooses one. That is the decision they can make.

• Good. The minimum viable version. Hits the date, hits the budget, the public moment can happen. Some of the bells, none of the whistles.
• Better. What you would build with another three or four weeks. Still on the practical critical path. The version most clients pick.
• Best. Everything that was originally specified, plus the obvious upgrades that became visible during discovery. Misses the date, or costs significantly more, or both.

Each option is priced. Each option has a named delivery date. Each option is internally consistent — it is not "the original spec minus a list of cuts", it is a coherent thing you can build, demonstrate and support.

Three reasons.

It reframes the conversation from "what is missing" to "what is being chosen". Customers feel loss aversion sharply when something is removed from a list they already approved. They feel agency when they pick between three named options.

It puts the cost of ambition back in front of the buyer. When the price difference between Good and Best is on a single page, the discussion about whether the late-discovered audio matrix is worth another twelve thousand pounds takes thirty seconds, not a fortnight.

It separates the project's commercial pressure from its technical work. Engineering knows what to build for each option. Sales knows what to sell. Procurement knows what to approve. The customer knows what they are getting. Nobody has to absorb someone else's ambiguity.

Five rows, three columns. The rows are not features. They are capabilities the customer will experience.

1. Outcome on the day. What the customer can demonstrate, show off, sell against, or open the doors with. Not "the system works", but "the lobby greets visitors with their host's name on the screen."
2. Coverage. Where it works, in what conditions, for which use cases. "Reception only" vs. "reception plus the four meeting suites" vs. "the entire 12th floor including the cinema room."
3. Resilience. What happens when something fails. "Manual fallback exists" vs. "system self-recovers in under a minute" vs. "fully redundant with monitoring and alerts."
4. Operability. Who runs it the day after handover. "Trained operator only" vs. "any reception staff member after a 20-minute briefing" vs. "fully self-service with documentation."
5. Future-proofing. What can be added later without rebuilding. The cheapest version often locks the customer into a dead end. Make that visible.

One line per cell. Same verb tense, same level of specificity, same scale of ambition across the row. If Good reads in concrete nouns and Best reads in marketing adjectives, you have not finished the matrix.

The most recent time we used this framework was for KPMG's 12th Floor Welcome Lobby at Canada Square. The previous partner had missed the deadline and spent the budget. The opening date was fixed. The brief was the size of a small concert hall.

Good was a working welcome system. The screens lit up, the visitor's host's name appeared, the doors opened. Coverage limited to the reception area. Resilience: manual fallback to a printed schedule. The lobby could open on time and the firm could host its first guests.

Better added the meeting-suite signage tied to the same booking system, presence detection so the screens dimmed when nobody was in the area, and a centrally managed content schedule so reception staff could change the welcome messaging without calling AV support. This is what got built.

Best added the cinema-room integration, the dynamic content rotation tied to the firm's marketing calendar, and the analytics layer that would have produced a dashboard nobody had asked for and nobody would have looked at. KPMG decided not to pay for it. That was the right call.

The lobby opened on time. The firm got the version of the system the firm actually wanted. The conversation about what to leave out took fifteen minutes in a single meeting, because the matrix was on the page.

The matrix only works when each option is a coherent system the team can actually build and the customer can actually use. Three reasons not to reach for it:

The constraint is regulatory or safety-critical. "Good" cannot be "non-compliant but fast". If the floor of the system is set by law, the matrix is binary, not three-way.

The customer does not have the authority to choose. If the buyer in the room has to escalate every option to a committee that meets in three weeks, the matrix does not buy you the schedule back. Solve the authority problem first.

You have not done the discovery. A Good/Better/Best matrix written before you understand the system is just three guesses dressed up as options. The matrix is the output of a delivery path assessment, not a substitute for one.