What separates great PMs from good ones: the traits that actually predict success

You’ve read the job descriptions. You’ve seen the lists: strategic thinking, communication skills, stakeholder management, data-driven decision making. These traits describe every product manager. They describe none of the great ones.

Here’s the uncomfortable truth: the things that actually separate great PMs from competent ones are harder to name, harder to assess, and rarely show up on performance reviews. They’re not skills you can learn from a course or frameworks you can memorize. They’re closer to dispositions—ways of being in the role that either come naturally or require years of intentional practice to develop.

I’ve worked with hundreds of PMs over the past decade. I can usually tell within a few weeks whether someone will be great, good, or struggling. It has almost nothing to do with their resume.

The Missionary Problem

Marty Cagan nailed this years ago: great PMs are missionaries, not mercenaries. They believe in the problem they’re solving. They’d work on it even if it wasn’t their job assignment.

This sounds soft. It isn’t. Missionaries make different decisions than mercenaries at every fork in the road:

• When a feature ships and metrics don’t move, the mercenary moves on to the next project. The missionary digs in to understand why.
• When stakeholders push for a solution that won’t actually help customers, the mercenary documents the requirement and builds it. The missionary fights back, proposes alternatives, and accepts the political cost.
• When the roadmap gets reshuffled, the mercenary updates their slide deck. The missionary asks whether the new priority actually serves the mission better.

You can’t fake this. I’ve watched mercenaries try. They use the right language—”customer obsession,” “solving real problems”—but their decisions reveal them. They optimize for shipped features, not outcomes. They celebrate launches instead of impact. They move on too quickly when something doesn’t work.

The practical implication: you cannot be a great PM working on a problem you don’t believe in. If you’re a mercenary on your current team, either find the belief or find a different team. There’s no third option.

The Non-Negotiable That Most PMs Negotiate Away

Teresa Torres has spent years teaching product teams one core practice: continuous discovery. Talk to customers every week. Not quarterly. Not when you’re starting a new initiative. Every week, without exception.

Most PMs agree this matters. Almost none do it. They have reasons: “I don’t have time.” “We have a research team.” “I already know what customers want.” “I’m too senior for customer calls.”

Great PMs find a way. They schedule the interviews themselves. They sit in on support calls. They read every piece of customer feedback that comes in. They do this not because it’s a best practice, but because they’re genuinely curious about what’s happening in customers’ lives.

The difference shows up in product decisions. PMs who maintain continuous customer contact develop what I call intuition grounded in evidence. They can make fast decisions because they’ve heard the same pain point forty times. They can push back on stakeholder requests with specific customer quotes, not abstract principles. They can tell when a feature idea is solving a real problem versus a hypothetical one.

PMs who rely on secondhand research—analyst reports, research decks, internal opinions—develop a different kind of intuition. It’s informed by what’s easy to measure and what other people think is important. It misses the texture of real problems.

Here’s the test: when’s the last time you were surprised by something a customer said? If it’s been more than a month, you’re not talking to enough customers. If it’s been more than a quarter, you’re flying blind.

The Trait That Can’t Be Taught: Taste

Lenny Rachitsky has interviewed hundreds of top PMs. The pattern he keeps finding: great PMs have taste. They can look at a product, a design, a piece of copy, a pricing page, and know whether it’s good—without needing a framework or a customer test to tell them.

This makes people uncomfortable. Taste sounds subjective, elitist, unteachable. It’s all three. It’s also real.

Watch a PM with taste review a design mockup. They don’t just catch usability issues or point out edge cases. They notice that the emotional tone is wrong, that the hierarchy buries the most important information, that the whole approach feels like a compromise instead of a decision. They can’t always articulate why immediately, but they know something is off.

Watch a PM without taste review the same mockup. They check boxes: “Does it meet the requirements? Did we include the features we discussed? Are there any obvious bugs?” They might approve something mediocre because nothing is technically wrong with it.

Taste develops through exposure. PMs with great taste have used hundreds of products with a critical eye. They’ve studied what works and what doesn’t. They’ve developed opinions about details that most people ignore: error messages, loading states, onboarding flows, pricing psychology, email timing.

The practical implication: if you want to develop taste, you need to spend time experiencing products outside your domain. Sign up for things. Click through competitors’ entire flows. Read design blogs. Form opinions about why certain products feel good and others feel off. Do this for years.

There’s no shortcut. This is why taste is so valuable—it can’t be crammed.

The Four Traits That Actually Predict Success

Here’s what I actually look for when assessing PM potential. These aren’t the traits you’ll find in job descriptions, but they’re the ones that separate the great from the good.

1. Comfort With Being Wrong in Public

Great PMs kill their own ideas. They propose a direction, discover evidence against it, and publicly change their mind. They do this without defensiveness, without treating it as a failure.

This is rarer than you’d think. Most people, especially smart people who’ve built careers on being right, protect their ideas. They rationalize negative data. They find reasons why the evidence doesn’t apply. They quietly abandon bad ideas instead of publicly acknowledging the mistake.

The PM who can say “I was wrong, here’s what I learned, here’s what we should do instead” earns more trust than the PM who’s never wrong. Because everyone knows the second PM is just better at hiding their mistakes.

When I interview PM candidates, I ask about a time they changed their mind about something important. The great ones have multiple examples ready, told without embarrassment. The weak ones struggle to find any.

2. Writing Clarity

Writing is thinking made visible. A PM who can explain a complex product decision in one paragraph understands that decision deeply. A PM who needs five paragraphs is still figuring it out.

Good writing isn’t about grammar or style. It’s about compression. Can you take a messy situation with competing priorities and unclear tradeoffs and distill it into something a reader can understand in sixty seconds?

Every product artifact is a writing test: PRDs, status updates, strategy docs, Slack messages, tickets. Great PMs produce artifacts that are shorter than you’d expect and clearer than they need to be. They don’t make their readers do the work of extracting meaning.

This matters because writing scales. You’re in every meeting you attend, but your documents represent you in every meeting you’re not in. The PM who writes clearly shapes decisions even when they’re not in the room.

3. Curiosity About Problems, Not Attachment to Solutions

Watch how a PM reacts when their proposed solution gets challenged. The attached PM defends it. The curious PM asks questions.

“Why do you think that won’t work?”

“What am I missing about the problem?”

“What would have to be true for your approach to be better?”

The curious PM treats their solution as a hypothesis. They genuinely want to find out if it’s wrong because being wrong now is better than being wrong after six months of development.

The attached PM treats their solution as their reputation. They’ve invested in it. They’ve socialized it. They’ve tied their credibility to it. Being wrong feels like failure.

This is why junior PMs often make better decisions than senior ones. They haven’t built up the political capital that makes them afraid to lose it. They’re still curious because they have nothing to protect.

4. Tolerance for Ambiguity Without Premature Resolution

Product management is mostly ambiguity. You don’t know what customers really need. You don’t know if the market will respond. You don’t know if engineering’s estimate is right. You don’t know if competitors will react. You don’t know if the strategy will change next quarter.

Bad PMs resolve ambiguity prematurely. They pick an answer, any answer, because the discomfort of not knowing is too much. They commit to a roadmap before they have evidence. They estimate confidently without data. They treat their assumptions as facts.

Great PMs hold ambiguity. They stay in the uncertainty, gathering information, waiting for the right moment to commit. They know the difference between decisions that need to be made now and decisions that can wait for better data.

This requires a specific kind of emotional regulation. You have to be okay with stakeholders asking “What’s the plan?” and answering “We’re still figuring it out.” You have to resist the pressure to fake certainty.

Most PMs collapse under this pressure. The ones who don’t make better decisions.

What Doesn’t Predict Success

Let me be specific about the things that don’t matter much:

MBA degrees. I’ve worked with great PMs with MBAs and great PMs without them. I’ve worked with terrible PMs with MBAs and terrible PMs without them. The correlation is basically zero. The MBA teaches frameworks and case studies. Product management happens in the messy space between frameworks.

Charisma. Some great PMs are charismatic. Some are awkward introverts who prefer to communicate in writing. The charismatic ones are easier to promote but not necessarily better at the job. Sometimes charisma is a crutch—it gets stakeholder buy-in without doing the hard work of actually being right.

Framework knowledge. Knowing RICE and MoSCoW and HEART and whatever prioritization framework launched last month doesn’t make you better at prioritization. Great PMs use frameworks as communication tools, not decision-making tools. The decision comes from judgment. The framework helps explain it.

Years of experience. Some PMs get better every year. Some PMs have one year of experience repeated ten times. Experience only helps if you’re learning from it, and most people learn much less from experience than they think.

Kill the “Mini-CEO” Metaphor

You’ve heard it: the PM is the CEO of the product. This metaphor produces bad PMs.

CEOs have authority. They can hire, fire, allocate budget, set compensation, reorganize teams. PMs have almost none of this. The PM who acts like a mini-CEO—making demands, expecting compliance, pulling rank—gets pushed back by engineers who don’t report to them, designers who have their own opinions, and stakeholders who actually do have authority.

The better metaphor: the PM is the editor of the product. They don’t write the code or design the interfaces. They shape the overall narrative. They decide what gets cut. They notice when the pieces don’t fit together. They’re responsible for the final product without doing most of the work.

This requires a different set of skills than being a CEO. Influence instead of authority. Persuasion instead of command. The ability to get credit for outcomes without claiming credit for work.

PMs who internalize the editor metaphor work better with their teams. They ask more questions and give fewer orders. They’re more curious about why someone disagrees than focused on winning the argument. They understand that their job is to make the product better, not to make the decisions.

The 2025 Baseline: AI Literacy

I’ll be direct: AI literacy is no longer a differentiator for PMs. It’s table stakes. If you can’t have an informed conversation about what LLMs can and can’t do, you’re missing context that affects almost every product decision.

This doesn’t mean you need to train models or write code. It means you need to understand the constraints: hallucination rates, latency tradeoffs, fine-tuning costs, privacy implications. It means you’ve spent time using the tools, breaking them, understanding their failure modes.

Every PM roadmap in 2025 includes some AI component, even if it’s “we’re not doing AI.” The PM who can’t engage with these decisions intelligently is operating with a blind spot.

But AI literacy won’t make you a great PM. It will keep you from being left behind.

What This Means for Hiring

Most PM hiring processes assess the wrong things. They test for framework knowledge, communication polish, and case study performance. They miss the traits that actually matter.

If I were designing a PM interview loop, I’d focus on:

• A writing sample produced under time pressure. Give them a messy situation and 45 minutes to write a one-page recommendation. See how clearly they think.
• A deep dive on a time they were wrong. Not just “what happened” but “how did you realize it” and “what did you do next.” Look for genuine comfort with being wrong.
• A product critique without frameworks. Show them a product and ask what’s good and bad about it. See if they have taste or just pattern-matching.
• Customer interview roleplay. Watch how they ask questions. Are they curious? Do they follow up on interesting threads? Do they ask leading questions that confirm what they already believe?

These assessments are harder to run than standard interviews. They require interviewers who can evaluate judgment, not just check boxes. They produce results that are harder to compare across candidates.

But they predict success better than anything else I’ve tried. For specific questions to use, see [INTERNAL_LINK: PM interview questions].

The Path Forward

If you’re trying to become a great PM, the bad news is that most of these traits take years to develop. The good news is that they can be developed.

Start with the customer contact. This week, schedule a conversation with someone who uses your product. Not to validate your roadmap. Just to understand their world better.

Then look at your last major decision. Were you attached to your solution, or curious about the problem? Would you have changed your mind if the evidence pointed the other way?

Finally, write something. Take a complex product decision you’re facing and explain it in one paragraph. If you can’t, you don’t understand it well enough yet.

These practices compound. A year from now, you’ll have intuitions you can’t develop any other way.

If you’re earlier in your career and still working toward your first PM role, the same principles apply—focus on building these traits rather than collecting credentials. See [INTERNAL_LINK: breaking into product management] for more on that path.

Frequently asked questions