Great PMs Don't Agonize

“What makes a great Product Manager?”

I get asked this a lot. Students, new PMs, people switching careers, my family at Thanksgiving when I’m explaining my career again. Everyone wants to know what separates the PMs who thrive from the ones who burn out or “retire” to a customer success job.

I used to give the standard answers. Great PMs are data-driven, customer-obsessed, strong communicators. Credible with engineers, persuasive with executives. These aren’t wrong, but they’re table stakes. And at some point I realized that when I thought about the builders I actually admired, the people I’d watched ship things that mattered, none of those traits were what made them different.

Here’s the answer I actually give now: great builders don’t agonize.

Not that they don’t feel it. The ambiguity, the lack of authority, the chaos of dependencies, the politics of prioritization. I feel all of it. Great builders just don’t treat it as a problem to escape. They’ve stopped waiting for everything to become clear, because it never does.

The map never matches the terrain.

There is always a gap between intent and practice. Between the strategy deck and what’s actually getting built. Between what the process map says and what happens when you sit next to someone and watch them do their job. Between what a customer says in an interview and what they do when no one’s watching.

Early in my career, as a mechanical engineer, I worked on a team building a new ethernet jack for apartment building installations. It was toolless: you’d seat the wire and close two small doors with your fingers to terminate the connection. No punch-down tool required.

On a site visit, I watched an installer rip the bag open with his teeth, throw the instructions on the ground, shove the wire in, and close the doors with a pair of pliers. Same motion he’d used on every jack for the last ten years. We started getting failure reports weeks later. We hadn’t tested this scenario, and the internal wiring harness wasn’t designed for this much force, and the terminations were failing. We’d engineered away the need for tools, and it didn’t matter, because the installer’s hands already knew how to do the job the old way. And no one reads the fucking instructions.

This is the norm. In every organization I’ve worked in or around, manufacturing companies, startups, enterprise SaaS, government, the distance between documented intention and lived practice is always there. Always shifting. Never zero.

I used to think the answer was to close the gap. Do more research, write clearer specs, build better dashboards, tighten the feedback loop. Eventually, if you get enough data, intent and practice converge.

I’ve never seen that actually happen.

What I have seen, what most of us do once we’ve been around long enough to know better, is worse. We perform certainty we don’t have. We call research “de-risking” as if uncertainty is a line item you can zero out. We present roadmaps as commitments instead of bets. We build dashboards around metrics that make our decisions look good rather than metrics that would tell us if we’re wrong. When something we ship doesn’t move the needle, we quietly move on or find a vanity metric that tells a better story. The entire system runs on an unspoken agreement to pretend the uncertainty isn’t there.

And that performance is where most of the agonizing comes from. Not the ambiguity itself, but the effort of maintaining the fiction that you’ve got it under control.

There’s a term from bladesmithing that captures what the good builders actually do instead.

The temper line is the visible boundary on a blade where hard steel meets soft steel. The hard edge cuts. The soft spine absorbs shock. Neither works alone: all hard and the blade shatters, all soft and it can’t cut. The craft isn’t in making the whole blade one thing, it’s in controlling exactly where the transition happens.

The gap between intent and practice, between documented knowledge and lived reality, isn’t a problem to solve. It’s the temper line. It’s permanent terrain that you develop craft around.

I’m framing this around PMs because that’s where I live, but it’s not a PM-specific skill. Engineers make this move every time they decide what to abstract and what to leave concrete. Designers make it when they choose what to specify and what to leave to intuition. Anyone building product navigates this boundary, PMs just happen to live on it full-time.

Great PMs embrace the temper line. They don’t agonize because they’ve stopped trying to make everything hard (quantified, documented, de-risked) or keep everything soft (open-ended, aspirational, constantly generating new options). They’ve gotten skilled at managing the boundary: knowing what to sharpen, what to leave flexible, and when to move between the two. The roadmaps, the sprint planning, the stakeholder alignment are just tactics for working in different parts of the boundary. The job is to navigate the ambiguity, stay clear eyed about the uncertainty and keep people building effectively despite all of it.

Manufacturing figured this out decades ago. Toyota’s entire production philosophy was built on a conviction that you can’t understand work by reading about it. Documentation compresses reality by nature. The production floor shows you what actually happens, and the difference is where the useful information lives. The engineers I worked with in manufacturing walked the floor to see what was actually happening; most of tech still acts like the dashboard is ground truth.

The gap is where the unexpected insights actually live.

I watched support staff at a previous company turn case titles into a task management system. Their ticketing tool had no internal notes, no way to track where they were in a case, so they started renaming support tickets. Instead of “Case #2024-1847, Billing Inquiry,” it became “Call back about refund dispute” or “Check account history, this one’s tricky.” It worked great until customers started logging into the portal and seeing their case titled “Watch out, this person’s hard to talk to.” Nobody designed that system. Nobody trained anyone to do it. The gap between what the tool provided and what the work required produced a solution that was simultaneously ingenious and completely broken.

At a previous startup, we built compliance analytics for a regulated industry and tried to sell the data to adjacent platform companies. It fell flat because they saw themselves as intermediaries, not enforcers.

We spent months having those dead end conversations. Then someone on a prospect’s operations team mentioned offhand that they’d used our data to spot a partner they’d just onboarded and seeing the compliance history would have saved them days of manual validation.

We’d spent hundreds of hours trying to sell them compliance monitoring. The actual opportunity, partner verification, was something no amount of upfront research would have surfaced. It only existed because someone used our prototype in a way we never intended. We’d built it open-ended, loose enough to let people poke around. That looseness benefited us, even if we didn’t explicitly plan for it.

If we’d “de-risked” the prototype by tightening it around our original pitch, hardening it, in temper line terms, we’d have killed the discovery. The gap between what we built and what someone actually did with it produced the most valuable insight of the entire effort.

So when someone asks me what makes a great product manager, that’s the real answer. It’s not the toolkit, the skills or background. It’s the ability to embrace life on the boundary, effectively operate in it, and not fucking agonize.

This is the first in a series about the boundaries between structured and unstructured knowledge in product development.