Great PMs Don't Agonize
What separates the builders who thrive from the ones who burn out: they've stopped trying to close the gap between documented and real, and learned to work inside it.
“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 (not to mention boring). 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 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 certainly 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.
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. He’d been installing jacks for at least a decade, and had always used tools to terminate. We started getting failure reports weeks later. We hadn’t tested this scenario, the internal wiring harness wasn’t designed for that 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.
The design was explicit knowledge we had documented, tested, spec’d, and created instructions for. The installer’s muscle memory was tacit knowledge from ten years of the same motion, invisible to anyone who wasn’t standing on that job site. The field failures came from where the two collided.
But ignoring this boundary is too often 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, and it’s always moving.
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, and we present bets as commitments. We build dashboards around the metrics that make our decisions look good and leave off the ones that would tell us 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.
Most of the agonizing comes from that performance, from the effort of keeping up the fiction that you’ve got it under control.
Bladesmiths have a term for what the good builders do instead.
The temper line is the visible boundary on a blade where hard steel meets soft steel. The hard edge cuts and the soft spine absorbs shock. Neither works alone: an all-hard blade shatters, and an all-soft one can’t hold an edge. The smith’s craft is controlling exactly where the transition happens.
The gap between intent and practice is the temper line. It’s permanent terrain, and the work is developing craft around it.
I’m framing this around PMs because that’s where I live, but the skill is broader than PM work. 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 work on 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). What they’ve gotten good at is knowing what to sharpen and what to leave flexible, and moving between the two. Roadmaps and sprint planning are tactics for working different stretches of that boundary. The job underneath them is keeping people building while staying clear-eyed about how much is still uncertain.
Manufacturing figured this out decades ago. Toyota built its production philosophy on the conviction that you can’t understand work by reading about it, because documentation compresses what happens on the floor and the useful information is in what got compressed out. The engineers I worked with in manufacturing walked the floor to see what was happening; most of tech still treats the dashboard as ground truth.
The gap is also where the unexpected insights come from.
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, and nobody trained anyone to use it.
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, and compliance monitoring cast them as 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 look into a partner they’d just onboarded, and that seeing the compliance history earlier 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, without planning for anything like this.
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. We pivoted to it: partner verification became the startup’s second product, we signed a contract for it, and it caught fake restaurants trying to onboard onto a major food-delivery platform. When we left, it made up about 20% of our revenue.
So when someone asks me at Thanksgiving what makes a great product manager, the real answer is the installer with the pliers. Somewhere between what you shipped and what people do with it, there’s a boundary that never closes. Great builders live on it and don’t fucking agonize.
This is the first in a series about the boundary between soft and hard knowledge in product development: what your gut has learned, and what you can write down and check.