The One-Slide Argument
Do not argue that design is valuable. Nobody is going to be talked out of a belief by an assertion of worth, and the defensive posture concedes the premise.
The template
The One-Slide Argument
Your CEO read that design is a bottleneck. This is the slide, the numbers to fill in, and the handling for the five objections you will get. The frame is not defense. It is capacity the company is currently wasting, and that framing is the entire difference between a conversation you win and one you survive.
The frame
Do not argue that design is valuable. Nobody is going to be talked out of a belief by an assertion of worth, and the defensive posture concedes the premise.
Argue this instead: the company can now generate more options than it can choose between, and choosing badly is more expensive than generating slowly ever was. Design is the function that closes that gap. Underinvesting in it does not save time, it converts speed into rework.
That argument works because it is about the company's constraint, not about your team's feelings.
The slide
One slide. Four blocks. No more.
┌─────────────────────────────────────────────────────────┐
│ THE SHIFT │
│ We can produce <N> credible directions in <T>. │
│ We choose between them the same way we did in 2023. │
├─────────────────────────────────────────────────────────┤
│ THE COST, LAST TWO QUARTERS │
│ Rework after ship: <hours / people / $> │
│ Reversed decisions: <count> │
│ Time in quality review: <hours per week> │
├─────────────────────────────────────────────────────────┤
│ THE MECHANISM │
│ Constraints written before generation. │
│ Quality scored against a rubric, not a meeting. │
│ Failure states owned before launch. │
├─────────────────────────────────────────────────────────┤
│ THE ASK │
│ <specific, small, dated> │
│ Reviewed at <date> against <one number>. │
└─────────────────────────────────────────────────────────┘
The numbers to gather first
Do not build the slide until you have these. An argument about capacity with no numbers is an argument about feelings with a chart.
Rework after ship. Engineering hours spent changing something that shipped, because it was wrong rather than because the plan changed. Get this from engineering, not from your own estimate. It is almost always higher than anyone expects and it is the number that moves the room.
Reversed decisions. Count of decisions made and then undone in the last two quarters. Your decision records give you this directly, if you keep them. If you do not, this is the argument for starting.
Time in quality review. Hours per week across everyone who attends design reviews, multiplied out. Presented next to what those reviews produce.
Generation capacity. How many credible directions the team can produce in a week now, versus two years ago. Engineering and design both have a view. This is the number that establishes the shift is real rather than rhetorical.
One caution: use your own numbers only. Industry statistics get challenged in the room and the challenge derails the meeting. Your rework number cannot be argued with, because it is theirs.
The ask
Small, specific, dated, and reviewable. Three that work:
"Two weeks to write constraint sets for our three highest-traffic surfaces, then we measure rework on those surfaces for a quarter." Cheap, concrete, falsifiable.
"One design engineer." Frame as enforcement capacity: the person who turns design decisions into checks that run automatically. This lands better with technical leadership than another designer, and it is often the higher-leverage hire.
"Design in the room when the bets get made, not after." Costs nothing, and if the answer is no, you have learned something important about the next twelve months.
Do not ask for headcount as the opening ask. It converts a strategy conversation into a budget conversation, and budget conversations are decided elsewhere.
The five objections
1. "AI can do design now." Agree with the true part immediately, because arguing it costs you credibility. Yes, it produces interfaces, and that is why the constraint moved. The question is who decides which of the twelve is right and writes that down so it executes consistently. That is not a tooling question.
2. "Design slows us down." Ask where the delay actually occurs. If reviews are at the end and rework is high, design has been operating as QA, and the fix is to move it earlier, not to reduce it. Point at the rework number.
3. "Engineering can do it." They can produce it, and increasingly they do. Ask who currently owns what the product refuses to do, and what happens in the thirty seconds after it is confidently wrong. Usually the answer is nobody, and that gap is the argument.
4. "Can we just use a template or a system?" Templates cover states somebody anticipated. Generated products spend most of their time in states nobody drew. That is the whole reason the specification changed shape.
5. "Show me the ROI." This is a fair question and the numbers block answers it. Rework hours avoided, reversals avoided, review hours recovered. Give the number, name the review date, and offer to be measured on it. Offering the measurement is what makes the ask credible.
How to run the conversation
Fifteen minutes, not forty. One slide, three numbers, one ask.
Lead with their constraint, not your function. Open with the generation capacity number and the rework number in the same breath. That pairing is the argument, and everything else on the slide is support.
Then stop talking. The instinct is to keep making the case. The stronger move is to let the two numbers sit next to each other for a moment.
The one thing to do this week
Get the rework number from engineering. One question, one Slack message: how many hours in the last two quarters went into changing something after it shipped because it was wrong. You cannot build this slide without it, and you will probably not need the rest of the slide once you have it.
From "The Case You Will Have to Make", chapter 26 of The Design Operating Model. falkster.com/design/the-case-you-will-have-to-make