Pretty much every strong product leader I've worked with — or just admired from a distance — has been impatient.
Not in an annoying way. More like a constant, low-level restlessness. A we-could-be-moving-faster energy that pushes them to question the status quo, try things, and get things out the door. It's a kind of productive dissatisfaction that's fairly hard to fake and, I'd argue, fairly hard to do without.
I think impatience is one of the most underrated traits in product management.
But the line between useful and destructive is thinner than most people realise.
When impatience is a good thing
Amazon literally codified this. Their Bias for Action leadership principle says: "Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking."
The word "calculated" is doing a lot of work there. It's not about being reckless — it's about choosing not to wait for perfect information when imperfect information and a real-world test would teach you more, faster.
In practice it shows up as a few things: putting something in front of real users before you're ready, because waiting only means building more on assumptions. Asking why a process exists instead of just following it. Making the call when the decision is reversible, rather than waiting for a certainty that isn't coming.
Andy Jassy put it plainly: "Speed is not preordained. Speed is a choice." Impatient leaders get this instinctively. Pace is something you create.
Marty Cagan writes about this in Empowered — the teams that do the best work aren't handed a feature list, they're given real problems to solve. Getting there means ditching the false comfort of a pre-defined roadmap. That takes a real willingness to be dissatisfied with the status quo.
When it goes wrong
The problem is it doesn't always stay directed at processes and systems. Sometimes it turns toward people.
Micromanagement is the most obvious version. An impatient leader who's stopped trusting their team to move fast enough starts hovering — checking in constantly, overriding decisions, telling people not just what to do but exactly how to do it.
The research on this is fairly stark. Micromanagement consistently ranks among the top three reasons people quit, and the majority of micromanagers have no idea their behaviour is the problem. It also creates a trap: the more you micromanage, the less autonomy and judgment your team gets to develop, which makes it even harder to trust them, which makes you micromanage more. Round and round.
Shreyas Doshi — former product leader at Stripe, Google, and Twitter — captured a version of this perfectly on LinkedIn. He describes what happens when an executive publicly punishes a team for missing a launch date: every other team sees it, and from that point on they all start padding their schedules. The company ends up moving slower than before — the exact opposite of what the executive wanted. As he puts it: "you will almost certainly get the opposite of that if you do these things." The lesson being that impatience expressed as pressure doesn't create urgency. It creates self-protection.
Disrespect is subtler but just as corrosive. It shows up as cutting people off, dismissing ideas that haven't had a chance to breathe, treating urgency as a licence to be short with people. The message it sends — even when unintentional — is your pace is not acceptable and I don't have time for you.
Kim Scott nails this in Radical Candor. She calls it "Obnoxious Aggression" — when you challenge people directly but don't show you actually care about them as people. It might feel decisive in the moment. But it quietly kills the trust and psychological safety that good teams run on.
Impatience-as-disrespect is completely self-defeating. You're damaging the very thing you need in order to go fast.
So what do you actually do with it?
When I feel that impatient energy rising, the question I try to ask is simple: is this directed at a problem, or at a person?
Impatience with slow processes, unclear priorities, meetings that shouldn't exist, problems that haven't been properly defined — that's useful. Impatience with a specific person's pace or judgment is usually worth pausing on. It tends to say more about a breakdown in trust or clarity than it does about the person.
The most practical thing I've found is to get honest about whether I've actually set people up to move fast in the first place. Amazon's reversible/irreversible decision framing is genuinely useful here — for anything you can undo or iterate on, move fast and let your team make the call, and save your involvement for the things that are genuinely hard to walk back.
But more often than not, when a team is moving slowly, the problem isn't supervision — it's that the goal isn't clear enough. Channelling impatience into clearer problem framing tends to work a lot better than channelling it into watching how someone does their job.
Cagan makes this point well. Empowering a team doesn't mean stepping back and hoping for the best — it means creating the context and clarity that lets people move fast without you needing to be in the room. And before you push back or redirect someone, Kim Scott's check from Radical Candor is worth running: am I doing this because I care about this outcome and this person, or am I just frustrated? If it's the latter, the intervention probably isn't going to land the way you want.
I don't think impatience is something you should try to reduce. The product leaders I've most respected have all had it. But the ones who could actually build something — who kept good people around long enough to ship things that mattered — had figured out where to point it.
That's the harder thing to learn.