Design Doesn't Need a Seat at the Table. It Needs to Set One.
There’s a meeting happening right now where a designer is making the case for why design should be involved earlier.
The Product Manager is nodding with the expression of someone already calculating the go-to-market plan. The Tech Lead has already moved on to solutions and is quietly wondering if they can bypass the architecture review entirely.
At the end of it all, nothing changes.
This is the design advocacy loop. It runs constantly, in every organization. It is demoralizing, and honestly? It mostly doesn’t work.
Here’s the thing nobody says out loud: If you’re still fighting for a seat at the table, you’ve already lost the argument. Not because design doesn’t matter. But because fighting is the wrong tactic. The teams that actually get early involvement don’t get it by asking louder; they get it by showing up useful before anyone thought to invite them.
The Problem With "Advocating for Design"
When designers talk about advocacy, what they usually mean is: we’re being brought in too late, our work isn’t being taken seriously, and we have to justify why our lane is our fucking lane.
That is a real problem. But the framing makes it worse.
Advocacy puts design in a reactive posture. You are always asking for more, always defending the same ground. The alternative isn’t louder advocacy—it’s becoming an active contributor to planning instead of a passive recipient of decisions that were already made without you.
The shift is subtle, but it changes everything. When you show up to a planning conversation with persona context, journey maps, and a clear read on where the experience gaps are, you don’t need to advocate for inclusion.
You’re already included. Because you’re already useful.
What "Getting Upstream" Actually Looks Like
The instinct when design keeps getting excluded is either to escalate or to prove value through polished deliverables after the fact. Neither works.
I know. I’ve tried.
It’s like begging for The Silmarillion right after someone already bought you the Lord of the Rings trilogy. They give in, they buy it, and then it sits on your shelf collecting dust because the thing you fought hardest to get was the thing you needed least in that moment.
That is what late-stage design advocacy looks like. You win the argument. You get included. And then you deliver something beautiful that nobody uses because the real decisions were made two weeks ago.
What works is getting upstream—and arriving with something worth having.
A brief note attached to the work item itself—who is affected, what the experience risk is, what’s unknown—is more valuable at planning time than a high-fidelity prototype nobody has context for yet.
A rough sketch shared when scope is still uncertain invites collaboration.
The same sketch shared after sprint planning invites critique.
The moment you spot a cross-initiative dependency or an unvalidated assumption that’s going to bite someone in the ass three sprints from now, that is the moment to surface it. Not after planning. Not after stories are written. Right then.
Early flags are worth ten times what they cost as late surprises.
The Trust Problem Nobody Talks About
Underneath all this is a hard truth: Cross-functional alignment is a trust problem dressed up as a process problem. Teams that collaborate well have learned through repeated experience that the other function will show up reliably, surface issues honestly, and not use early access as a mechanism to expand scope at someone else’s expense.
Design earns that trust the same way everyone else does: by being useful, predictable, and honest.
Useful means showing up with context and artifacts that actually help other people do their jobs, not just things that "demonstrate design’s value." (There is a difference, and everyone can feel it.)
Predictable means following through. If design commits to flagging risks early, flag them early. If design commits to a gate, hit it.
Honest means saying when scope is too large for the time available. It means naming unvalidated assumptions that actually matter instead of absorbing ambiguity silently and delivering late.
Nothing destroys trust faster than a team that says everything is fine right up until it isn’t. Your goal isn’t to be liked; it’s to be the team that makes everyone else’s job a little clearer.
Introducing New Practices Without Torching Relationships
Showing up "useful" is the behavior shift, but eventually, you have to codify that utility into the way the team actually functions.
The hardest part of alignment isn't the work—it’s introducing a new practice to people who are already underwater and skeptical of "process overhead." Framing matters as much as mechanics here.
The last time I introduced a new planning touchpoint to a PM team, I led with this:
"This doesn’t change ownership or add new responsibilities. It exists to help design do its job effectively and to give everyone more shared context going into planning."
Explicitly naming what you are not doing removes the defensive reaction before it starts. Nobody fights to participate in something if they know it won’t quietly absorb their time or shift who owns what.
To make this land:
Treat rituals as experiments: "We’ll refine this as we go" signals you aren't trying to install a permanent bureaucracy.
Keep asks small: At planning time, you don't need a fully formed brief. You just need the problem, the audience, and the intended outcome.
What Good Alignment Actually Feels Like
You know it’s working when the downstream friction starts to drop. The rework. The late surprises. The assumptions that nobody wrote down because everyone thought someone else had them covered.
Good alignment isn’t a meeting cadence. It’s a shared understanding of what each function needs from the others, and when:
Product brings the business intent early enough to shape, not just execute.
Engineering gives honest signals on feasibility while there’s still room to adjust.
Design brings persona context and experience risk flags.
When all three show up that way, planning stops being a handoff and starts being a conversation.
One Thing You Can Do Today
Pull up the last three projects your team was brought into after scope was already defined. Look at what they have in common.
That is where the gap is. That is where you start showing up earlier, with something in hand, before anyone thought to ask.