The Upstream Designer's Playbook.
How product designers work with PMs, AI, and the deformation phase. Five dimensions on which value is moving — and the moves you can practise this week.
AI has not replaced designers. It has compressed the part of design that used to take the longest: producing screens. The bottleneck has moved upstream — to deciding what to build.
Designers who stay in the execution layer will find their PMs framing problems, generating prototypes, and asking design to make them "look right" afterwards. That is the inversion this playbook is built to prevent.
Five dimensions on which value is moving: problem framing, editorial judgment, influence and narrative, lived presence, and the new contract with PM and engineering. Each gets a principle, an anchor quote, a concrete move you can practise this week, and — where credible voices disagree — the disagreement itself.
A PM you work with opens Lovable or Figma Make on a Tuesday afternoon. By Thursday they have a working prototype of the feature they've been pitching for a month. They walk it into a review, it's rough but it runs, and someone says "can design make it look like ours?" The room agrees. The PM is now framing the problem and shaping the solution. You are now the skinner.
This is not a future risk. Your PMs have these tools today. The deformation phase is not coming for our craft from outside — it is being invited in by the people we sit next to. Our job is not to be faster at vibe-coding than them. It is to stay upstream of the prototype.
Problem framing.
You owe your PM your judgment, not your compliance.
As a design leader, one of my main challenges is trying to make the PMs better clients — helping them get more specific. Designers are going to draw the storyboards; if you don't give them a great script, they're going to have a very hard time.
Most requests arrive as the antibiotic already prescribed — "I need a dashboard for X", "add a settings page for Y". The deformation phase makes this more dangerous, not less, because the request now comes with a prototype attached. AI will generate the dashboard. It will not tell you a dashboard was the wrong intervention.
- You can name the user's underlying job in one sentence — before any artifact exists.
- You bring at least one reframe to every kickoff: 'the request is X, but the problem behind it might be Y.'
- You sit with the PM before the PRD is written, not after — and you co-shape the framing.
- You are willing to say 'we should not build this' — and you do, when the evidence supports it.
- Ten framings of a problem before a single artifact.
- You wait for the PRD. You wait for the prototype. You wait to be told.
- You frame your reframes as objections — when they should be served as a sharper version of the PM's own goal.
- You ask 'what do you want it to look like?' when the better question is 'what are we actually trying to solve?'
- You agree the dashboard is the answer because the PM said dashboard.
- You let the prototype become the problem statement by default.
A strategy doc isn't complete without wireframes. It's like working with an architect who doesn't provide a blueprint.
I just found if I got on the whiteboard and drew really badly, it gets you so fast to a shared vision. Designers spend all this time making wireframes — that's the lamest use of time ever.
Both are right about different things. Mehta is right that strategy without a visual is hot air. Wodtke is right that polished wireframes can be a way of delaying the conversation. The team move: get something visual in the room early, but rough on purpose. A whiteboard sketch in a PM meeting is upstream work. A Figma wireframe sent for review three weeks later is downstream work pretending to be strategy.
Becoming the "why are we building this?" person without ever proposing what to build instead. Reframing is half the move. The other half is bringing a sharper version of the problem with you. A reframe without a proposed direction is contrarianism, and partners learn to route around it.
Before any new project, fill in three lines. If line two and three differ from line one, you have a reframe. Bring it before the PRD is locked.
- 01
What was asked for — the literal request, in the PM's words.
- 02
What the user is actually trying to do — the job, in plain language.
- 03
What you would propose — your sharper framing, plus the question you would put to the PM.
Editorial judgment.
Not aesthetic taste any more. Choosing what gets built.
Someone has to decide what is actually going to get built and what actually matters. There's some sort of judgment around what to do next — and that, I think, is structurally yours.
The aesthetic-taste version of this skill — "my proportions are better than yours" — is exactly the part AI is closing fastest. The defensible version is sharper and harder: editorial judgment about what gets built in the first place. Aesthetic refinement is the floor. Editorial judgment is the ceiling.
- You can articulate, in one sentence, why this thing should ship and that thing should not.
- You kill your own options on purpose — including the ones that took you the longest.
- You can name the standard you are evaluating against — specific to this project, not generic.
- You use AI to widen the option space, then bring judgment to narrow it.
- You give other designers the same treatment you give yourself: candid, specific, oriented to the problem.
- 'I think this one feels better' — preference dressed up as judgment.
- Falling in love with the first AI output and shipping it.
- Picking the option that was most expensive to make, regardless of fit.
- Choosing the option closest to what the PM already wanted, to avoid friction.
- Treating curation as gatekeeping — judging without naming the standard.
The industry confuses production with taste. Tastemakers are the moat — not pixel generators.
The moat is real, but aesthetic taste will be commoditised by AI faster than people think. What's structurally yours is judgment about what to build — not whether the gradient is right.
If you are still defending the gradient as your value, you are defending the part AI is taking. Defend the editorial layer instead.
Taste laundering. AI tools make it tempting to generate twelve variations and pick the least bad without ever forming a position on what good would actually look like. That is not judgment. That is convenience dressed up as choice.
Before reviewing any set of options — yours, generated, or shipped to you in a prototype — write down two sentences.
- 01
The standard. 'In this project, good means [specific thing]. Not [generic thing].'
- 02
The kill criterion. 'I will reject any option that fails on [the one thing this project cannot afford to get wrong].'
Influence & narrative.
You build trust by killing things, not adding them.
One of the biggest things you can do to build trust is kill things, deprioritize things. Your executive is looking for you to be the deepest person in the room.
The one skill AI structurally cannot perform is convincing a human to change their mind. Influence is not a soft skill — it is the conversion mechanism between good thinking and the thing that actually ships. In the deformation phase the pile of plausible-looking AI output makes it harder than ever for the right idea to be visible. Your job is to be the voice that makes the right thing recognisable.
- You can write the argument before you make the artifact — problem, options, what you would do, why.
- You read what your PM actually needs to hear, not what you want to say.
- You bring positions to senior leaders, never open questions.
- You earn credibility by removing things from the roadmap — not by adding things to your portfolio.
- You change your mind in public when the evidence moves — and you say so clearly.
- Walking the meeting through your screens, hoping the design speaks for itself.
- 'Here are three options — what do you think?' — punting the decision back.
- Adding features to look productive instead of cutting them to look credible.
- Saving your real opinion for the Slack DM after the meeting.
- Treating influence as politics — when it is the craft of being understood.
"An executive's calendar is a strobe light. They go from finance to an interview to a people problem to a legal problem to your product review. The PM thinks 'I've been prepping for two weeks.' The executive hasn't thought about you since the last time."
Apply this to your director. Apply this to every senior stakeholder. They are not under-prepared for your meeting. They are correctly prepared for fifteen other meetings. The first 30 seconds of context reset is your job, not theirs.
Confusing volume with influence. The designer who speaks the most in the meeting is rarely the one who shifts the decision. The one who shifts the decision arrives with a written argument, listens twice as much as they talk, and frames their position as a better version of someone else's goal.
Before any meeting where a decision will be made, write a three-paragraph memo and send it ahead — or hold it in your back pocket if the culture isn't there yet.
- 01
The problem — in one paragraph, in the audience's language, with a 30-second top-of-meeting reset baked in.
- 02
The options you considered — including the ones you rejected, with the reasons.
- 03
What you would do — and what you want pressure-tested.
Lived presence.
You have a body, stakes, and a sense of enough.
The whole team has to really understand the product and the customers and the problems people are facing — and have that empathy. Not from a deck. From the channel.
AI has no 24-hour day, no users it has actually met, no career on the line. Your structural advantage is not that you are smarter or faster — it is that you are situated. The risk in the deformation phase is silent erosion: AI synthesis is so good that you stop sitting with the raw signal, and then one day your mental model of the user is two years old and you cannot tell why your reviews are getting weaker.
- You spend time, every week, in places AI cannot fully reach — support tickets, customer Slack, sales calls.
- You bring observations to design review that no model could have generated, because you were there.
- You have a point of view on what is enough for this project, and you defend it.
- You can tell, fast, when a vibe-coded direction smells wrong — and you can articulate why.
- You hold the long memory of the product — patterns, past mistakes, why-we-don't-do-that-anymore.
- Treating lived presence as a vibe — 'AI lacks soul' is not an argument, it is a comfort.
- Spending all your time in Figma and tools, where AI now competes with you.
- Outsourcing user empathy to research artifacts you never read.
- Believing seniority alone counts as pattern-recognition — when much of it is just nostalgia.
Romanticising the human. The argument is not "AI is bad, humans are good." The argument is that your situated knowledge — what you have actually seen, sat with, been responsible for — is structurally yours. Defend it by using it. The designer who quotes a real support ticket beats the designer who quotes a framework, every time.
Block one hour a week — same day, same time — for non-Figma user contact. Pick one and rotate. Bring one observation back into the next design review. That is your contribution that week.
- 01
Read 20 fresh support tickets and write down two patterns you saw.
- 02
Sit in the customer channel and read the last week of complaints, in raw.
- 03
Watch one user session, end to end, with no second screen.
- 04
Shadow a sales or CSM call.
The new contract.
How design and PM work together when the boundaries dissolve. If you read nothing else, read this.
As code becomes much cheaper to write, the thing that becomes more valuable is deciding what to write. All of the roles are merging. PMs are doing some engineering work, engineers are doing PM work, designers are PMing — and also landing code.
The old contract — PM writes the PRD, designer makes the screens, engineering builds it — is dissolving fastest of any part of the discipline. We are not Anthropic. But we share software with PMs who can now generate prototypes in a Tuesday afternoon. If we don't actively reshape the contract, the next version of it will be written by the person who shows up with the prototype first. That person will not be the designer by default.
PM has an idea, generates a prototype, brings it to a review, the review converges on "design will refine this." The designer's role becomes UI polish on a frame someone else already drew.
Within six months, the muscle for upstream framing atrophies. Within twelve, the team is staffed and reviewed as a polish function. That is the inversion we need to prevent.
- You are in the room before the prototype exists — pairing with the PM on the problem framing.
- You and the PM co-author the problem brief; you draft the user story, they strengthen outcome metrics and risk.
- When a vibe-coded prototype shows up, the response is 'useful for exploring — let's look at what it gets right and wrong against what we're trying to solve' — not 'I'll skin it.'
- The team produces a small number of shared objects — a rough prototype, a problem brief, a one-page memo — that everyone annotates.
- Design is visible in what the team doesn't build, not just in what it does.
- You wait for the prototype, then make it pretty.
- The PRD lands in your queue and you start drawing.
- You let the demo of a Lovable prototype become the de facto problem statement.
- You measure your contribution in screens shipped while the PM measures theirs in problems framed.
- 'I wasn't in that meeting' — when the meeting was where the contract for the next quarter got rewritten.
Performing the new contract without doing the work. Saying "design owns problem framing now" in a meeting does not make it true. Sitting with the PM in the room where the framing happens, weekly, with a written brief in hand — that is what makes it true. The contract is renegotiated through repeated practice, not declarations.
Three concrete renegotiations to attempt over the next quarter. Pick one and run it. Don't do all three at once.
- 01
Move yourself upstream of the PRD.
Ask your PM for a standing 30-minute slot, weekly, before any PRD is written. Bring three lines — what's been asked for, what the user is trying to do, what you would propose. Make this the room where the framing happens, with both your names on it.
- 02
Reframe the prototype conversation.
When a vibe-coded prototype lands, don't accept 'design will refine this.' Instead: 'this is useful — let me bring back a sharper problem brief next week, and we can compare what this prototype assumes against what we actually need.' The prototype becomes a probe, not a spec.
- 03
Co-author the brief.
For one initiative this quarter, write the problem brief jointly with the PM. You draft the user story and framing. They strengthen outcome metrics and risk. Engineering annotates feasibility. The artifact is shared, not handed off. The contract is in how the artifact gets made.
When all five are in place, the question "can design make it look like ours?" is never asked — because design and PM are already co-authors of the thing.
- 01You were already in the room before the prototype existed, framing the problem.
- 02You can name what is wrong with the prototype using a standard you wrote down before seeing it.
- 03You have a written memo on what we should actually build, and you can read the strobe-lit room.
- 04You can quote a real support ticket the prototype contradicts.
- 05The relationship with the PM is already such that this conversation happens before the prototype, not after.
The self-check.
Rate yourself 1–5 on each dimension. Not where you wish you were. Where you actually are.
What is your contribution that AI structurally cannot make?
Answer it in writing · Re-read in 90 days