There is a specific kind of silence that happens when you realise someone has just done your job for you — and nobody in the room thinks that's a problem.
I felt it for the first time in a stakeholder meeting where features had already been listed, flows had already been decided, and I was sitting there — alongside my team — quietly asking myself: so why exactly are we here? If the product concept is already locked, if the user interaction has already been defined, maybe what you need is just someone to make it look good. A UI decorator, not a designer. Maybe, in the age of AI, you could just prompt your way to a front-end and hand it to the developers.
That thought — as uncomfortable as it was — is what made me realise something had to change. Not just in how others saw my role, but in how I was showing up to protect it.
The Project
We were building customised software for a multinational dealing with infrastructure problems at scale. The hook was satellite data analysis — using geospatial technology to speed up a manual process that their teams had relied on for years. On paper, it was exciting work. In practice, it was one of the most pressure-filled projects I had been part of.
The client had a simple expectation: accuracy. Their manual teams could achieve 100% accuracy. Our algorithm was delivering 87%, and we were pushing hard to get it to 90%. Every client call ended the same way — "that's still not good enough. My manual team gets it right every time. I'd rather wait two extra days and have certainty than trust your software." They weren't wrong. And they were getting impatient.
Inside the company, everyone was trying to solve the problem simultaneously — and separately. The tech team was refining the algorithm. The product team was adding front-end features: tools to highlight anomalies, ways for users to flag errors, feedback mechanisms to help the model improve. The business leads were in back-to-back calls trying to reset client expectations. We were all working hard. We were barely working together.
A project that should have taken a month stretched to six. The parallel effort drained the team. Confidence dropped. By month four, the dominant feeling wasn't momentum — it was dread. Every iteration felt like a band-aid. Nobody said it out loud, but we all knew: we had lost the thread of what we were actually trying to solve.
The Decision No One Asked Me to Make
When teams are exhausted and timelines are collapsing, someone usually steps in and makes a call. In this case, it was the business lead.
"Here is what the client wants. Here is the feature. Here is how the user will interact with it. Cut the scope to this. Build it."
It wasn't a conversation. It wasn't even a brief. It was a directive — delivered to a team that had run out of energy to push back. My designer had already come up with two or three thoughtful mockups. They had questions. They had considered failure scenarios. None of that made it into the room. The decision had already been made. The message was: set your thinking aside and execute.
They did. Not because they agreed, but because the room had no space left for debate. And I — the product design lead — let it happen. Partly because I too was exhausted. Partly because I told myself: maybe this is what the client actually needs right now. Partly because I didn't want to be the one adding friction to an already fractured team.
The product manager could have stepped in. They didn't. And I, honestly, could have stepped in. I didn't either.
The Demo
Two weeks later, after the engineering team had built and shipped the feature, we walked the client through a demo.
The client looked at the screen and said:
"What do I have to click?"
"Why do I need to click so many times?"
"What does this even mean?"
We didn't have answers. I stepped up to defend the feature — trying to wrap it in design language, making it sound considered and intentional. I knew it wasn't. The words came out, but they felt hollow. After months of effort, after an entire engineering sprint, we were standing in a room defending a decision nobody had actually thought through.
And the feedback, as it always does in these moments, landed on the design team. We hadn't thought it through. We hadn't considered the user. We had made it too complicated.
Except we had never been asked to think it through. We had been asked to build what we were told.
The Conversation I Needed to Have
After the demo, I pulled the business lead aside. I wasn't looking to assign blame. I was looking to name the actual problem — because if I didn't name it then, it would just happen again on the next project.
I said: "Your job is to challenge my decisions. My job is to make them. When you make them on my behalf — without my team being involved — and they fail, the failure still lands on us. That's not fair, and it's not effective. If that's how this works, then there is no real role for a product designer in this project."
It was uncomfortable. It needed to be.
What I also had to sit with, privately, was my own part in it. I had stayed silent when I shouldn't have. I had told myself the team needed calm more than it needed pushback. But in doing that, I had let my team's work get bypassed — and then watched them take the blame for it. That's not protecting your team. That's abandoning them with a smile.
Design leadership isn't just about being in the room. It's about knowing when the room is about to make a mistake — and being willing to say it out loud, even when the energy is against you.
What I Took Away
When a whole team goes quiet, it's not a personality problem — it's a signal. It means something in the system is broken: ownership is unclear, trust is low, or the pressure has gotten so high that people have stopped believing their input matters. Demotivation isn't weakness. It's a warning light. As a design leader, it's your job to read it.
The PM-PD relationship isn't about harmony. It's about clarity. Who owns the problem definition? Who owns the user journey? Who has the final say on the interaction? When those lines blur — especially under pressure — decisions get made by whoever speaks loudest, not whoever thinks most carefully. That's how you end up building the wrong thing very efficiently.
And finally: it's not enough to be right. You have to be present. Decisions don't wait for the right meeting or the right moment. They happen in hallways, in rushed Slack messages, in "let's just do this and move on" conversations. If design isn't there — actively, consistently, with a point of view — someone else will fill that space. Every time.
If You're in That Meeting Right Now
If you're sitting in a meeting where the feature is already decided, the flow is already mapped, and nobody has asked what the user actually needs — ask it anyway. Not to slow things down. Not to be difficult. To do the job that no one else in that room is doing.
If you've been blamed for a decision you didn't make — that's not a personal failure. That's a system failure. And it usually means no one has clearly defined where the PM's thinking ends and the designer's thinking begins. That clarity doesn't appear on its own. You have to ask for it, name it, and sometimes fight for it.
The designers who move into leadership aren't the ones who stay quiet to keep the peace. They're the ones who learn to speak precisely — about ownership, about process, about what happens when design is removed from decision-making. Not loudly. Not combatively. But clearly, and without apology.
Your role isn't to execute someone else's vision. It's to make sure the right questions get asked before the wrong thing gets built.
Take that job back.