Why 'Always Do the Right Thing' Is Bad Advice for Product Managers

"As a PM, you must always do the right thing" is a pretty bad advice.

TL;DR: The ideal PM burns out trying to do all the right things. The pragmatic PM builds trust first, then changes things. Solve problems the company acknowledges as problems. With the trust you earn, you can slowly improve the things you care about too.

The Story

A PM friend told me this recently. He joined a new company and tried to clean things up. He wanted all bug fixes to be properly logged in Jira so everyone had visibility and context. Note that Jira was already being used by the team. He was not introducing a new tool or a new process. He just wanted fixes to be tracked the same way features were.

Sounds reasonable, right?

Instead, he got shouted at by a VP. "Fixing things is more important than recording them." "Stop picking fights with engineers."

What actually happened? A senior engineer complained that the PM was making bugs visible to everyone via Jira, and the VP overreacted. The engineer did not want a paper trail of bugs. The VP did not want conflict. And the PM, who was genuinely trying to improve the process, became the problem.

Why Being Right Was Not Enough

My friend was objectively right. Tracking fixes in the same system where you track features is basic engineering hygiene. Any engineering leader would agree in principle.

But being right and being effective are two different things.

The organization did not see untracked fixes as a problem. The engineers had been quietly fixing things for years. Leadership was happy with the output. Nobody was asking for more visibility into bugs. So instead of being seen as someone improving the process, my friend was seen as someone exposing negative things.

This is the trap that catches a lot of new PMs. You walk in, see things that are clearly broken, and assume that fixing them will earn you credibility. It does not. Not if the organization does not agree that those things are broken.

The Pragmatic Approach

I told him he should step back and not escalate this beyond his manager. Yes, even though he was right. Because the most practical way to survive and grow as a PM is to see yourself as a problem-solver. Not just for customer problems. Internal ones too. But here is the key: solve only those problems that the company acknowledges as problems.

When you solve problems people care about:

• You get buy-in. Nobody resists a solution to their own pain point. If the team is struggling with release predictability, and you help fix that, you are a hero. If you try to fix something nobody complained about, you are a nuisance.

• You avoid unnecessary friction. Every organization has unwritten rules about what is acceptable to challenge and what is not. A new PM does not know these rules yet. Picking the wrong battle early can cost you months of trust.

• You build trust. Trust is the currency that lets you change things later. Once people see you as someone who delivers results on things they care about, they will listen when you suggest improvements to things they did not know were broken.

The Long Game

With that trust, you can slowly improve the things you care about too. My friend could have waited three months, delivered a few wins, and then casually mentioned: "Hey, I noticed some fixes are not in Jira. Would it help if we tracked them? I can set up the workflow so it takes engineers 10 seconds." Same suggestion, completely different reception.

The difference is not the idea. It is who is saying it and how much trust they have earned.

What This Means for Your Resume

This is also why your resume needs to show outcomes, not just process improvements. "Introduced Jira tracking for bug fixes" is a process change. "Reduced repeat bug rate by 30% by introducing fix tracking that identified recurring patterns" is an outcome. Hiring managers want to see that you solved problems that mattered, not that you had good ideas nobody asked for.

If you are curious how your resume communicates this, score it against PM best practices and see whether your bullets show outcomes or just process.

The Biggest Takeaway of My Career

The ideal PM burns out trying to do all the right things. The pragmatic PM sleeps well and gets things done.

This does not mean you compromise on quality or ignore real problems. It means you pick your battles based on what the organization is ready to hear, not what you think they should hear. You earn the right to change things by first proving you can deliver on what already matters.

The best PMs I have worked with were not the ones with the strongest opinions. They were the ones who knew when to push and when to wait. That timing is not a skill you learn from frameworks. It comes from reading the room, building relationships, and understanding that being right is necessary but never sufficient.