Good vs. Great Product Managers: 24 Ways the Top 1% Operate
If “Product Manager” were a video game, a good PM plays on Normal: ships features, keeps the trains on time, and can recite the roadmap in their sleep. A great PM plays on Nightmare‑Ironman‑No‑Checkpoints and still makes it look easy. They bend ambiguity into outcomes, elevate the team’s thinking, and somehow have customers quoting their product back to them.
This post unpacks the behaviors and mindsets that separate “good” from “top‑1% great.” It includes a shareable comparison chart, practical habits, and, yes, research and quotes—because your VP will ask “Source?”
The data (and a few quotable north stars)
Most ideas don’t work as intended. Microsoft’s experimentation leaders reported that, across thousands of online experiments, about one‑third of ideas improved key metrics, one‑third were neutral, and one‑third made things worse. Translation: great PMs build learning loops, not legend stories. (Harvard Business Review)
Customer time is shockingly rare. A Pendo survey found 74% of product pros spend fewer than five hours per month with customers—far below Pragmatic Institute’s recommendation of eight hours per week. Great PMs buck the norm. (Pendo.io)
Weekly customer touchpoints are the bar for discovery. Teresa Torres defines continuous discovery as “at a minimum, weekly touchpoints with customers by the team building the product.” If you’re not hearing from customers weekly, your intuition’s warranty expires fast. (Product Talk)
Design quality correlates with business results. McKinsey’s multi‑year “Business Value of Design” study showed companies in the top quartile outperformed peers on revenue growth and TSR—evidence that taste and craft are not “nice‑to‑haves.” (McKinsey & Company)
Team climate matters more than team résumés. Google’s Project Aristotle found psychological safety was the most important dynamic of effective teams. Great PMs create it; good PMs unknowingly drain it. (Rework)
Writing clarifies thinking. Amazon institutionalized six‑page narrative memos; “We don’t do PowerPoint… Instead, we write narratively structured six‑page memos,” wrote Jeff Bezos. Great PMs write to think, not just to update. (About Amazon)
The job, simply stated. Marty Cagan: the PM’s job is to discover a product that’s valuable, usable, feasible (and viable)—and to involve engineers early or you’re “only getting about half their value.” (Silicon Valley Product Group)
“People think focus means saying yes… It means saying no to the hundred other good ideas… Innovation is saying no to 1,000 things.” —Steve Jobs. When in doubt, practice “no‑fu.” (Goodreads)
The shareable comparison chart: Good PM vs. Great PM (Top 1%)
Pro tip: Drop this in your team wiki, laminate it for your standup, or “accidentally” leave it open when your favorite stakeholder walks by.
Dimension
Good PM
Great PM (Top 1%)
North Star
Measures success by shipped features and velocity.
Anchors work to a North Star Metric that captures customer value and ties inputs to outcomes. Can explain how today’s task moves the NSM—without needing an espresso first. (Amplitude)
Customer Contact
Schedules interviews… when it’s time to write a PRD.
Weekly touchpoints with users (min.), co‑observes with design & engineering; discovers surprises in context. (Product Talk)
Discovery
Runs a survey; calls it a day.
Treats discovery as a habit. Uses Opportunity Solution Trees, rough prototypes, and cheap tests to reduce value/usability/feasibility/viabilityrisks early. (Silicon Valley Product Group)
Experimentation
Prefers “strong opinions, strongly defended in meetings.”
Builds fast, trustworthy experiments because “only ~1/3 of ideas help.” Learns in weeks, not quarters. (Harvard Business Review)
Design & Craft
Ships “MVPish” and moves on.
Sweats first‑mile/last‑mile details; knows quality compounds financially (MDI). Makes empty states and error states lovable. (McKinsey & Company)
Team Dynamics
Treats engineers like code vending machines.
Works as a Product Trio (PM + Design + Eng) from day 0; engineers co‑create and innovate. Psychological safety isn’t a poster; it’s the meeting norm. (Product Talk)
Strategy
“Our strategy is… roadmap Tetris.”
Can draw the market map, wedge, and bet—in Sharpie. Explains what would falsify the bet.
Saying “No”
Says yes to keep the peace; inherits chaos.
Practices “disagree and commit” and uses no‑if‑yes framing (“Yes—if we drop X and hit Y outcome”). (amazon.jobs)
Writing
Slides with 8‑point font and 32 arrows.
Clear, narrative docs that survive the meeting. Channels Amazon’s memo ethos to force clarity. (About Amazon)
Metrics
Adds analytics after GA says “404.”
Instruments events before build; defines leading indicators and guardrails (e.g., activation, change‑failure rate proxies).
Prioritization
Argues frameworks by acronym.
Uses any framework (RICE, cost of delay) pragmatically—but chooses based on causal logic and constraints.
Stakeholders
Runs status theatre.
Co‑authors decisions: “Here’s the problem, options, trade‑offs, and the bet.” Leaves a paper trail of decisions and rationale.
Meetings
10 people, 0 owners, 90 minutes.
Fewer, smaller, written pre‑reads. Meetings are for decisions; Slack is for updates.
Time Use
Calendar Tetris grandmaster.
Guards maker time for deep work and customer time; automates status. (Also knows when to cancel a meeting—heroic act.)
Roadmaps
Output‑heavy, feature‑dense.
Outcome‑driven, time‑boxed themes with space to learn; OKRs are outcomes, not task lists. (What Matters)
Risk
Treats risk as a slide.
Names the four risks explicitly and designs tests for each. (Bonus: sleeps better.) (Silicon Valley Product Group)
Technical Depth
Avoids the engine room.
Gets curious about architecture, latency, data models. Doesn’t overrule engineers—asks better questions.
Go‑to‑Market
Tosses over the wall.
Partners early with marketing, success, sales enablement; drafts the API and the one‑pager.
Backlog
Graveyard of unloved tickets.
Ruthless pruning; closes JIRA with the same joy others close rings on an Apple Watch.
Learning Loops
Postmortems as blame sessions.
Blameless postmortems; metrics + narrative + action items. Turns surprises into system improvements.
Ethics & Privacy
“Legal will catch it.”
Designs for consent, minimization, and explainability from the start. (Future‑you says thanks.)
Accessibility
“We’ll add alt text later.”
Targets WCAG compliance by default; tests with real users.
Humor
“Our funnel is a slide.”
“Our funnel is a hole if we don’t instrument it.” (Then fixes it.)
Outcome
Ships a lot of stuff.
Changes customer behavior and moves business metrics—reliably.
Five moves to go from good → great this quarter
Block weekly customer time—non‑negotiable.
Pencil it in like a dentist appointment you can’t wiggle out of. Invite your designer and your tech lead; aim for weekly touchpoints (Torres). Keep it scrappy: 30‑minute calls, short field observations, or live support ride‑alongs. You’ll find problems you “wouldn’t even know to ask about” and your ideas will get sharper. (Product Talk)Adopt a North Star + inputs (and use it to say no).
Commit to one metric that represents value to users; list 3–5 input metrics your team can actually move. If a request doesn’t obviously influence an input → it waits. (Amplitude’s playbook is a great starter.) (Amplitude)Write narratives, not decks.
Try the Amazon move for your next big decision: a 1–3 page narrative with context, options, trade‑offs, and the recommendation. Start the meeting with a quiet read. It’s eerie how much this raises the IQ of the conversation. (“We don’t do PowerPoint… we write narratively structured six‑page memos.”) (About Amazon)Turn opinions into experiments.
Remember the 1/3‑1/3‑1/3 rule. For any medium bet, outline: hypothesis → success metric → guardrail metric → smallest test. Pre‑commit to what triggers a rollback. Your future postmortem self will send you cookies. (Harvard Business Review)Include engineers in discovery.
The little secret in product: engineers are often your best single source of innovation—if they see the problem early. Invite them to interviews, whiteboard the constraints, and ask “What would be easy but high‑leverage?” (Cagan’s point, repeatedly.) (Silicon Valley Product Group)
Behaviors of the top 1% you can spot from the hallway
They make trade‑offs legible. The great PM doesn’t just decide—they expose the decision calculus in plain language so others can challenge assumptions before code is written. (Your legal counsel will clap silently.)
They cultivate psychological safety. They thank dissenters; they model “I don’t know.” Teams share half‑baked prototypes without fear—which is how the best ideas show up early. (Google’s Project Aristotle made this painfully clear.) (Rework)
They manage upwards with outcomes. Exec says “We need Feature X.” Great PM replies, “We can achieve Outcome Y two faster ways—trade‑offs inside.” (Cue the CFO smiling.) (What Matters)
They remove ambiguity with writing. Even a two‑paragraph pre‑read turns stakeholder chaos into a solvable math problem. Amazon didn’t ban slides for aesthetics—they did it because writing is thinking. (About Amazon)
They’re calm in the chaos. Andy Grove’s famous mantra—“Let chaos reign, then rein in chaos”—is their posture. They invite exploration, then converge decisively. (Wikiquote)
They care about craft because dollars care about craft. The MDI findings aren’t just design‑team folklore; better design practices correlate with stronger growth and TSR. Great PMs budget time for polish (and for removing features). (McKinsey & Company)
They say “no” as an act of love. Jobs’s line about saying no to a thousand things is not bravado; it’s resourcing. Every yes spends your team’s attention. Every no buys clarity. (Goodreads)
A quick self‑assessment (printable, merciless, effective)
Score yourself 0–2 on each item (0 = “not me,” 2 = “obviously me”). If you hit 30+, you’re trending great.
I had four or more user touchpoints this month, with an engineer present in at least two. (Product Talk)
My roadmap is outcome‑driven and laddered to a North Star; I can defend every theme’s causal chain. (Amplitude)
I ran at least one experiment that could have rolled back something we believed. (The humility rep.) (Harvard Business Review)
I shipped at least one decision via narrative memo instead of a deck. (About Amazon)
Our product trio co‑created a solution this month; engineers weren’t “surprised” in sprint planning. (Product Talk)
I explicitly listed value/usability/feasibility/viability risks for the top initiative and how we’re testing them. (Silicon Valley Product Group)
I said no (or “yes‑if”) to at least one misaligned request and documented why. (amazon.jobs)
We improved one UX detail (first mile/empty state) that reduced friction and measurably helped a metric. (McKinsey & Company)
I created psychological safety on my team by thanking a dissenter and adopting their suggestion. (Rework)
I pruned backlog items that didn’t move inputs (RIP, dear tickets). (Amplitude)
I instrumented at least one funnel before building the feature.
I wrote down one assumption that would falsify our strategy and shared it with leadership.
If your score is low, congrats—you found your growth edges. That’s a gift, not an indictment. Product is a long game; we level up by systems, not sprints.
“But my company is a feature factory…”
Many are. John Cutler’s classic “feature factory” essay struck a nerve for a reason. If your org celebrates output and forgets outcomes, start small: define a North Star, run one honest experiment, and narrate the learning. You can’t flip a factory overnight, but you can start a lab next to it. (Medium)
Closing thought
Great PMs aren’t clairvoyant; they’re compounded learners. They start with the customer, translate strategy into outcomes, use writing to sharpen thinking, pull engineers into discovery, and run experiments because they know most ideas are innocent until proven useful. If you adopt just three practices from this piece, make them these:
Weekly customer touchpoints with your trio. (Product Talk)
A North Star + inputs to say no with confidence. (Amplitude)
Narrative decisions and cheap experiments—because the data says humility wins. (About Amazon)
Now, go forth and rein in some chaos. (Innovation requires saying no to a few things today—like that “urgent” 10‑person status meeting.) (Goodreads).