I'll start with what you already know but nobody writes about.

You spent three weeks on a project. You ran the research. You mapped the flows. You iterated through four rounds of design. You tested with users. You refined based on findings. You collaborated with engineering to get the implementation right. You stayed late to fix the edge cases nobody else noticed.

The product ships. The metrics improve. The VP sends a congratulatory Slack message.

The PM gets tagged. You don't.

In the quarterly business review, the PM presents the outcomes - the same outcomes your design decisions produced - as "what we achieved this quarter." The slides don't mention design. Your name doesn't appear. The narrative is about "product execution" and "strategic prioritisation," and somehow the three weeks you spent solving a problem that nobody else could even frame correctly has become a PM success story.

If you're a designer working in an Indian organisation - or honestly, most organisations anywhere - you've lived this. Maybe not every project. But enough times that the pattern is unmistakable.

And here's what makes it worse: you know that the PM who just took credit couldn't have produced the work. They couldn't have run the research. They couldn't have mapped the flows. In many cases, they couldn't even articulate the problem clearly until you articulated it for them. And yet the credit flows upward to their name, not yours.

This Isn't a Bug. It's the Operating System.

The PM isn't "stealing" your credit. The organisation is giving it to them. By default. By design. By structure.

ProductPlan - one of the largest PM resources in the industry, written for PMs - states it plainly: "As a product manager, you will often be the one praised for your product's successes - when it reaches customer or revenue milestones, when it wins industry awards, when a big customer signs on" [1]. They then advise PMs to share credit generously. Which means the default - the thing that happens when nobody makes an effort - is that the PM gets the credit. All of it.

This isn't because PMs are more skilled. The Product Focus 2026 Survey found that 34% of product professionals report having no clear primary metric [2]. A third of PMs can't connect their product to a business outcome - and they still own the narrative. They still sit in the business review. They still present the quarterly results. Because the chair they sit in faces the leadership table, and yours doesn't.

The credit imbalance operates on three structural advantages that have nothing to do with competence:

Proximity to leadership.PMs sit in roadmap meetings, strategy reviews, and business reviews. Designers are often not in these rooms - not because they can't contribute, but because the org chart doesn't route them there. When leadership thinks about "who owns this product," they think of the face they see in the strategy meeting. That face is the PM.

Narrative ownership.The PM writes the brief. The PM defines the success metrics. The PM presents the outcomes. The person who frames the story gets credit for the story - regardless of who did the work inside the story. If you let someone else write the narrative of your contribution, you've donated your credit before the project even shipped.

Organisational default.When a product succeeds, credit flows to whoever "owns" the product on paper. That's the PM by title. The design contribution is invisible unless the designer actively, deliberately, and consistently makes it visible. Most organisations don't create space for that visibility. And most designers don't create it for themselves.

Why Is Design So Easy in Their Heads?

This is the question underneath the credit problem. And the answer is uncomfortable for everyone involved.

PMs can claim they "did the design" in a way they'd never claim they "wrote the code." A PM who generates a few screens in Claude Design feels entitled to say "I mocked this up." That same PM would never open VS Code, write a backend service, and tell the engineering lead "I built the architecture."

Why? Because engineering is perceived as hard. Design is perceived as common sense.

This perception doesn't come from PMs alone. It runs through the entire stakeholder chain - from the CEO who says "just make it look clean" to the business head who approves a redesign over lunch on the back of a screenshot, to the VP who equates design with choosing colours. The perception that design is easy isn't a PM problem. It's an organisational literacy problem.

And AI has made it worse. UX Collective's trends analysis warned that "AI-powered tools will change everyone's perception of who is equipped to design, how long design takes, and - inevitably - how much design is worth paying for" [4]. When a PM generates a plausible-looking interface in ten minutes, the perceived distance between "PM with AI" and "designer with Figma" collapses. Not the actual distance - the work of understanding users, defining problems, evaluating usability, and making strategic design decisions hasn't gotten easier. But the perceived distance.

UX University put it even more directly: "Being good at making things look good is no longer a career. It is a feature. And it is a feature that a machine now ships for free" [5]. When the execution layer is commoditised, the only thing that separates a designer from anyone with Claude Design is the thinking underneath the screens. And if designers don't make that thinking visible, the perception that "anyone can design" becomes self-fulfilling.

Where Is Design Leadership in All of This?

This is the part that should make design leaders uncomfortable. Because the PM credit problem isn't just a PM problem. It's a design leadership failure.

In many Indian organisations - and this is something we've explored in depth in Design Leadership Is in Turmoil - design managers are doing one of three things. Occupying the position without exercising the authority. Struggling to define what their strategic role should even be. Or optimising for organisational comfort - staying agreeable, avoiding conflict, and deferring to whoever holds more power.

They're not maintaining design respect. They're not fighting for design quality. They're not building momentum for the practice. They're 100% allocated to delivery - reviewing screens, managing timelines, approving assets - and calling it "design leadership" because the title says so.

When design leadership doesn't do strategy, PMs fill the vacuum. Not because PMs are power-hungry. Because the vacuum exists and someone has to fill it. The PM steps in, owns the direction, owns the narrative, and owns the credit - because nobody from design showed up to claim any of it.

And here's what engineering leadership figured out that design leadership didn't: engineering managers and CTOs built their seat at the table by owning delivery outcomes. They don't just manage engineers - they own system reliability, deployment velocity, technical debt, and infrastructure costs. They speak the language of business risk and operational capability. Do tech managers find PMs unnecessary and troublesome? Sometimes. But they've built enough structural authority that PMs can't overstep into engineering territory the way they overstep into design territory.

Design leadership hasn't done this. Most design leaders can't articulate design's contribution in P&L terms. They can't point to a dashboard that shows design's impact on retention, conversion, or operational efficiency. They talk about process, not outcomes. They showcase work, not value. And so when the PM walks into the room and says "here's what the product delivered this quarter," nobody asks "and what did design contribute to that?" - because design leadership never built the framework for that question to be asked.

Can Delivery Happen Without PMs?

This is a question designers whisper in corridors but never ask out loud. And the honest answer is: yes. In many cases, it can.

PMs primarily orchestrate. They coordinate priorities across stakeholders, manage the roadmap, facilitate cross-team alignment, and communicate upward. These are valuable activities. But they're not irreplaceable activities - especially not by someone whose only tool for orchestration is their position on the org chart.

If a design leader spoke genuine cross-functional language - if they understood engineering constraints, business objectives, operational capabilities, and customer needs with enough depth to facilitate those conversations themselves - the orchestration role becomes redundant. Not the strategic PM who genuinely shapes product vision. But the coordinator PM who manages the backlog and relays information between teams? That role exists because nobody else claimed it.

We've seen this in practice. Design leaders who own the relationship with engineering directly - who sit with the tech lead, negotiate scope, understand deployment constraints, and collaborate on solutions without a PM intermediary - ship better products, faster. The design-engineering handoff we explored in From Slicing PSDs to Shipping Front-End Code is increasingly direct. The PM layer in that workflow is becoming optional.

This isn't about eliminating PMs. Good PMs who genuinely own product vision and business strategy earn their seat. It's about recognising that the "PM as mandatory intermediary between design and everything else" model is a structural choice, not a natural law. And it's a structural choice that benefits PMs at the expense of design's authority.

The Anuradha Problem

Let me tell you about a pattern I see repeatedly, because it captures everything wrong with the current dynamic.

A designer I'm currently mentoring - 13 years of experience. She's methodical. She conducts research because she knows that designing without understanding users produces mediocre products. She takes the time to build empathy, to understand context, to ensure her solutions are grounded in real user needs.

Her PM has 2 years of experience. She's fast. She generates screens with AI. She presents confidently. And in a sprint review, she tells a 13-year veteran - in front of the team - that she's "too slow." That the research is "holding things up." That the team needs to "just ship it."

Why does a 2-year PM feel entitled to dismiss a 13-year designer's approach? Three reasons, and none of them are about competence.

First, speed is the visible metric.Organisations measure what they can see. How many features shipped this sprint. How quickly the screens were delivered. Time-to-deploy. These are all visible. What the senior designer is doing - building the empathy and understanding that prevents the product from shipping the wrong thing - is invisible until it's absent. Nobody measures "problems we avoided because the designer did proper research." They only measure "features we shipped."

Second, the PM's position protects her.In most org structures, the PM "owns" the product. When the PM says "we need to move faster," it's interpreted as a product decision, not a personal opinion. The designer pushing back is seen as "resistance to product direction." The hierarchy doesn't protect the person with the expertise. It protects the person with the title.

Third, nobody taught the PM what good design practice involves.She genuinely doesn't understand that the three days spent on research will save three weeks of rework later. She doesn't know because nobody in the organisation - no design leader, no design manager, no senior designer - has ever made the business case for research in terms she understands. The PM's ignorance isn't entirely her fault. It's a failure of design advocacy at every level above the designer doing the work.

How to Push Back When PMs Overstep

This is the part where most "designer empowerment" content says "have a conversation" or "align on shared goals." That's weak advice for a real problem.

Here's what actually works:

Make the cost of skipping design visible.When the PM says "skip the research, just ship it," don't argue about the process. Argue about risk. "If we ship without testing, there's a [X]% chance of rework based on the last three projects where we skipped research. Each rework cycle cost us [Y] weeks. The research takes 3 days. The rework takes 3 weeks. Which risk does the business want to take?" You're not defending your process. You're presenting a business calculation.

Document the prediction, then document the outcome.When you're overruled - and you will be - write it down. "PM decided to skip usability testing on the checkout redesign. I've documented my recommendation and risk assessment." Then when the rework happens - and it will - you have a timestamped record. Not to say "I told you so." To say "here's the pattern, and here's the cost, and here's what I recommend we do differently next time." Do this three times and the PM stops overruling you. Not because they respect your process. Because the data makes overruling expensive.

Stop asking for permission and start presenting direction.Don't wait for the PM to bring you a brief. Build one yourself. Go to the PM with: "Based on what I've observed from the last release - support tickets increased by 40% on the onboarding flow, session recordings show users dropping at step 3, and our NPS for new users fell 12 points - here's the problem I think we should solve next, here's the research I'd run to validate it, and here's a rough timeline." That's not asking for work. That's leading it. The PM can agree, disagree, or propose an alternative. But you've set the agenda. You're no longer waiting to receive it.

Escalate through evidence, not emotion.If a PM is consistently dismissing design, overriding research-backed decisions, and claiming credit for your work, the response isn't a confrontation. It's an evidence trail presented to whoever the PM reports to. "Over the last quarter, three design recommendations were overridden by PM. Here's what each recommendation was, what was done instead, and what the outcome was. In all three cases, the PM's direction led to rework costing [X] weeks. Here's my proposed working model going forward." This isn't complaining. This is a business case for changing the dynamic.

Build the engineering relationship directly.PMs maintain their intermediary position partly because designers don't talk to engineers enough. Start pairing directly with your engineering lead. Understand their constraints. Collaborate on solutions. When the PM's brief doesn't account for technical reality, you and the engineer can jointly push back - which is significantly harder to dismiss than a designer pushing back alone.

Five Shifts That Change the Dynamic Permanently

Not requests. Not better questions. Not "aligned conversations." Structural shifts in how you operate that make credit impossible to misattribute.

1. Sense and Shape Before Anyone Else

Don't wait for the brief. Be the person who brings the problem.

Why weren't you involved before the PM wrote the brief? Why didn't you build a strategic problem statement - grounded in user data, support tickets, analytics, and competitive analysis - before the PM even started thinking about the next sprint? Why are you waiting for someone to hand you the work when you could be the person who defines what the work should be?

Think about how PMs come up with their ideas in the first place. They don't invent them from nothing. They talk to business leadership, scan the market, review customer feedback, and check competitive moves. Then they write a brief and hand it to you as though the direction was always theirs. But every input they used to form that brief - the support tickets, the usage data, the competitive landscape - is available to you too. You just never went and got it.

A designer who walks into a planning meeting - not the PM's planning meeting, the cross-functional planning meeting where business, engineering, and product set direction - with a business-oriented problem statement changes the entire dynamic. "Our onboarding completion rate dropped 18% last quarter, correlating with 23% higher 30-day churn among enterprise customers. Here's the problem as I see it, here's the research I'd run to validate it, and here's what I think solving it is worth to the business." That's not presenting to the PM for approval. That's presenting to the room - business heads, engineering leads, everyone - as someone who owns direction.

This isn't a one-time move. It's a practice. Constant sensing - monitoring support tickets, tracking metrics, observing user behaviour, scanning competitive moves - so you always have a pipeline of problems worth solving. Not waiting. Not asking. Bringing.

2. Track and Own the Metrics

Don't log your impact for your own records. Own the measurement publicly.

At the start of every project, declare the metric you're designing against. "This redesign targets a 15% reduction in checkout abandonment." Put it in the project doc. Put it in Slack. Say it in the kickoff meeting. Then after launch, report the result - publicly, before the PM's quarterly review. "Checkout abandonment dropped 17% in the first two weeks post-launch, exceeding the 15% target we set."

When you own the metric from the start, you own the outcome at the end. The PM can still present it in the business review - but everyone in the room already knows who set the target and who reported the result.

3. Architect the Cross-Functional Relationship

Don't ask to be in the room. Make the room incomplete without you.

The reason PMs own cross-team coordination is because nobody else claimed it. But there's nothing stopping you from building direct relationships with engineering, content, marketing, and customer success - relationships that make you the natural connector, not the PM.

When the engineering lead comes to you directly with a constraint question - because you've built that relationship - the PM's intermediary role weakens. When marketing asks you for the design rationale because you've been sharing context with them throughout the project, the PM can't claim the narrative exclusively. When customer success forwards you a support ticket because they know you'll act on it, you have user data the PM doesn't.

Build these relationships deliberately. Not to undermine the PM. To make design structurally connected to every function - so the credit flows to where the connections are, not just to where the org chart points.

4. Kill the Information Asymmetry

The PM's power over the narrative exists because of information asymmetry. They know what leadership wants. They know the business targets. They control what flows up and what flows down. Break that asymmetry.

Get access to the business dashboards yourself. Ask finance for the customer acquisition cost. Read the quarterly earnings call transcript. Understand what the CEO told the board. When you know what leadership cares about, you can connect your work to it directly - without waiting for the PM to translate.

Write internal updates that connect design decisions to business outcomes. Not "I redesigned the settings page." Instead: "The settings redesign reduced support tickets related to account configuration by 34% in the first month, saving approximately 120 hours of customer success time - equivalent to ₹X in operational cost." Send this to the team, to your design manager, and CC the PM. You're not competing for the narrative. You're creating a parallel narrative that can't be absorbed into "what the product team achieved."

5. Establish the Precedent

Every time you take a stand - bring a brief, own a metric, report an outcome, push back on an overruled decision - you're establishing a precedent. Not just for this project. For how design operates in your organisation.

The first time you bring a business-oriented problem statement to a planning meeting, it'll feel awkward. The PM might push back. By the third time, it's expected. By the sixth time, the PM starts waiting for your input before setting the sprint direction. The precedent changes the dynamic - permanently.

This is what transforms credit from something you request to something you've already claimed. When your contribution is woven into the project from problem definition through outcome measurement, the credit isn't given to you by the PM's generosity. It's established by your own track record, visible to everyone who matters.

But Designers Have to Be Honest Too

The PM credit problem is real. The structural disadvantage is real. But designers contribute to their own invisibility, and pretending otherwise is dishonest.

How many designers finish a project, hand off the designs, and move on to the next brief? Who never circle back to measure what happened? Who never write a single line documenting business impact? Who wait for someone - their manager, their PM - to notice and acknowledge their contribution?

The DesignWhine analysis of UX community discussions across 2026 found that designers consistently report being "responsible without having authority, and accountable for user outcomes without having enough influence over the decisions that create those outcomes" [3]. That frustration is legitimate.

But if you designed it and didn't measure it, shipped it and didn't report the impact, solved a problem and never told anyone in business terms what it was worth - the PM didn't steal your credit. You left it unattended. And unattended credit gets claimed by whoever's closest to the leadership table.

The Bigger Picture

This blog is about credit. But it's really about whether design operates as a strategic function or a service function in your organisation.

When design is a service function, designers receive briefs, execute them, and hand off deliverables. Credit flows to whoever defined the brief - the PM - and the designer is interchangeable. When design is a strategic function, designers define problems, shape direction, own metrics, and connect their work to business outcomes. Credit flows to whoever created the value - and the designer's contribution is undeniable.

The difference between these two states isn't just about organisational maturity. It's about individual behaviour. You can't control your org's maturity. You can control whether you sense problems or wait for briefs, whether you own metrics or ignore them, whether you build cross-functional relationships or let the PM mediate everything, whether you kill the information asymmetry or live inside it.

That's what we build at Xperience Wave - the capability to operate as a strategic contributor, not a service provider. Whether you're navigating a hostile PM dynamic, building influence in an immature org, or preparing for a design leadership role where you ensure no designer on your team ever loses credit again - the foundation is the same: stop being the best-kept secret on your product team. Book a strategy call if you want to talk about where you stand.

Sources & References

[1] ProductPlan. (2026). "Conflict Management Recommendations for Product Managers." Acknowledges PMs are "often the one praised for your product's successes." productplan.com
[2] Product Focus. (2026). "2026 Survey of the Product Management Profession." 677 respondents, 40 countries. 34% report no clear primary metric. productfocus.com
[3] DesignWhine. (2026). "Leaving UX Design in 2026: Why Designers Want Out." Analysis of public community discussions, March-September 2026. designwhine.com
[4] UX Collective / Trends. (2025). "The State of UX in 2025." trends.uxdesign.cc
[5] UX University. (2026). "Beautiful Design Is Now Worthless." newsletter.uxuniversity.io
[6] Mind the Product. (2025). "Reducing Friction Between Product Managers and Designers." mindtheproduct.com

About the Author

Shaik Murad is Co-founder and Head of Product & Design at Xperience Wave, a UX design studio based in Bangalore, working across designer mentorship, UX services for businesses, and a design community of 1,000+ designers.

- Murad, Co-founder & Head of Product & Design, Xperience Wave