The short version. We sometimes treat career stagnation as an exotic intellectual deficiency. It rarely is. Most of what holds potentially exceptional product people back is not a missing skill but a useful virtue left to run wild.

Product managers usually get stuck when the behaviours that once made them successful stop serving them. Early in a career, saying yes creates wins, shipping fast proves competence, and staying loyal builds trust. At the next level, those same behaviours can become traps: yes becomes avoidance of trade-offs, shipping becomes a substitute for impact, and loyalty becomes a flattering name for stagnation. The work of career growth is subtraction — fewer commitments, fewer visible-but-meaningless outputs, and fewer comforting stories about why you are staying.

I did not set out to keep a tally. But somewhere around the fortieth coaching conversation it became hard to ignore that I was, with small variations, having the same conversation I had had the week before, and the week before that. Different people, different companies, different time zones — and underneath, three problems, recurring with the same regularity as a Singaporean bus timetable.1

For quite a while, I took this as evidence that I was a limited coach with three pieces of advice. The realisation came a bit later. These problems keep recurring because they are simply three faces of the same problem, and it is a strange one, because it does not announce itself as a weakness.

Most product problems are a virtue that grew past its station. The person who cannot say no is, on examination, helpful. The person who mistakes activity for impact is diligent. The person who has stayed in the same seat for four years is loyal. We do not hire against helpfulness, diligence and loyalty; these are actually traits that get someone the job. Then, left unchecked, they become the exact things that cap the career, and growth. The solution usually is unlearning some parts of the virtue, which I'm calling subtraction. This seems a bit unnatural, mostly because every earlier rung of the ladder paid out for the opposite.2

What follows are three examples. None of them is real in the sense that you could find them on LinkedIn. Each of them is real in the sense that I have met them a dozen times.

The one who cannot say no

Why do product managers struggle to prioritise and say no?

Let's call this person the helpful one. They run product at a mid-sized company, and arrive with that particular state of exhaustion that comes not from hard problems but from too many easy ones. Their roadmap has fourteen priorities. When pointed out that fourteen priorities is a contradiction in terms, they laugh in the way people laugh when you have named something they already knew and were hoping you would not.

Here is how they got there. Sales asked for a feature, and they said yes, because sales had a deal. The company won the deal — it worked out. The CXO had a thought in the shower, and they said yes, because he is the CXO. The team got praised internally — it worked out. An engineer wanted to rewrite a service, and they said yes, because the alternative was an argument. Every individual yes was reasonable. Every individual yes took them to a win, or a perceived win.

Collectively it has turned them into a routing layer for other people's whims and certainty — a human ticket queue with a job title.3

The standard product advice is very clean on this: weak prioritisation is rarely a failure of frameworks and almost always a failure of nerve. Strong product managers, the saying goes, protect focus; weak ones collect requests.

But what coaching surfaces is the bit underneath that bit. These people do not collect requests because they lack a scoring model. They collect them because saying yes is how they have "won" their whole life, and a no feels like a small concession they have to commit on purpose, many times a week. Sometimes, a no is also about making a decision — and it's comfortable to let the chips fall where they may, and take the near term win.

A roadmap is not a list of the things you will do. It is a list, written in the negative, of the things you are refusing to do — and if it refuses nothing, it is not a roadmap, it is a wish.

This is partly why bad ideas accumulate so easily. A suggestion takes seconds to make and hours, sometimes weeks, to properly refuse. After all, "the amount of energy needed to refute bullshit is an order of magnitude bigger than that needed to produce it."4

I cannot tell them to say "No" more. I can ask instead what they are protecting, and who pays when they fail to protect it. This is the trick coaching plays that advice cannot — it lets them arrive at the answer themselves. No one loves hearing this question. And then, very often, they raise the objection that undoes most of what we have discussed.

Everyone assumes the fourteen priorities are theirs to cut. A great many product managers are not in that position at all. They report into a leader, an engineer, or a founder who still thinks in commits, and the roadmap descends from above as a finished object — discovery optional, outcomes unmeasured, the PM quietly redefined as the person who renders someone else's certainty into a Gantt chart. Telling that person to disappoint more people is like telling a passenger to hit the brake.

So the first conversation is not really about saying no. Two product managers have the same symptom, which is a roadmap they do not believe in. But both have opposite diseases. One has more room than they are using, and "they won't let me" is the more comfortable story, because a real no is scary and being in a cage, at least, is not your fault. The other one has no room at all.

Before you can decide which features to refuse, you have to know whether refusal is yours to give. Most of the despair in product work is a structural problem wearing the costume of a personal one. The cure for the first one is nerve; the cure for the second is not.

The one who mistakes motion for progress

What is the difference between output and outcome in product management?

I call this person the busy one, no sarcasm, because they are genuinely good at the thing they are good at. They ship every fortnight. Their board is clean, their tickets closed, their stand-ups are crisp. The team loves it.

Then you ask them a question: what changed for a user last quarter because of something you built.

There is usually a pause. This pause is the whole essay. They can tell me what shipped with total fluency: a redesigned settings page, a new onboarding step, three integrations and so on. They cannot, without effort, tell me what any of it actually did. They are running sprint to sprint and quietly trusting that it adds up to the things that are hard to measure at the end of a quarter.

This is the oldest trap in the trade, and the people who fall into it are not lazy. They are the diligent ones, the feature factory's most willing employees, because diligence loves a closed ticket. Output is visible. Outcomes are less so. A reasonable person optimises what they can see, and the org cheerfully goes along. Shipped features are after all easy to put in an all-hands. Behaviour change is slightly more difficult to track.

Activity is what you can point to on a Friday afternoon. Impact is what you can point to a quarter or two later, if you are willing to be honest about the difference. Most dashboards, in my experience, are built to spare us that honesty.

The coaching move here is not to hand a framework. This person has all the theories. It is to ask what they would be willing to stop measuring. The diligence that makes them a great delivery manager is the precise thing keeping them a delivery manager.

Subtraction again is needed here. We do not need more output. We need the courage to let some of it go unbuilt so the other things can mean something.

The one who has stayed too long

When should a product manager leave their job?

This person is the loyal one. They have run the same product for many years. They know every edge case, every legacy decision, every reason the thing that looks wrong is actually load-bearing. When a new hire asks why the particular logic is the way it is, they are the only person alive who knows. They are, in the truest sense, indispensable. They also have not learnt anything new in months, and are worried this is related.

It is related. The more indispensable they become, the more the organisation arranges itself to keep them precisely where they are. The job, and the processes, weld themselves around them. The conventional wisdom says leave when you stop growing, but it also rarely mentions that the people most likely to stop growing are the ones too important to be let go.

The most useful person in the room is often the one who has stopped learning in it. Indispensability is not a compliment. It is a symptom, and the disease is that you have become the smartest person about a problem nobody is asking you to solve.

And here, again, the textbook advice hits a wall. Leaving when you stop growing assumes leaving is a door you are free to open. For a great many people, it might not be. They are on visas, or their equivalent in whichever city they have built a life in, and the pass is stapled to the job. The day the job ends, the clock starts. In a lot of places, a cancelled pass becomes a thirty-day visit pass, and thirty days is not long to find a role, re-sponsor a visa, and avoid uprooting a family that has a lease, a school place and a fragile new sense of home. The career-advice columns do not cost this in.

In the current tech market, the timing can feel openly hostile. The market has pulled off the trick of shedding people and posting vacancies in the same breath. Companies are cutting everywhere while the boards still have roles nobody quite seems able to land. More openings, fewer landings. We are in a freeze that is not announcing itself. So should they stay or go is the wrong question to ask, because going may simply not be on the table this quarter, or this year.

The conversation therefore has to change shape. It stops being about a heroic exit and becomes about honesty, which is way harder. The first thing to subtract is the story. If they are staying because the visa requires it, that is a real and respectable reason. Saying it plainly — "I am staying because I have to, not because I am still learning" — is itself the goal, because it converts a drift into a decision with a deadline. From there the subtractions get smaller and more doable: a sideways step into a part of the business they know nothing about, a deliberate shedding of the scope that makes them indispensable so somebody else can finally learn the billing logic, a year spent quietly building the savings and the case that make an eventual exit survivable.

As the play Hamilton puts it, "leaving is easy, staying is harder". I might have paraphrased that. A lot of the time the right move is to stop pretending that staying and growing are the same thing, while you do the unglamorous work of building yourself a door. We do not tell them to quit. That would be foolish, and possibly the reason they cannot make rent in February. I ask what they are staying for, and we try to notice how long it takes them to separate the honest answer from the flattering one.5

The fourth conversation

I used to find it slightly embarrassing that my coaching reduces, so often, to these three conversations. What I have since made my peace with is rather worse. That the three conversations are very often the same one.

Scratch the PM who cannot say no, and often enough, you find a leadership team that has no direction and lets the product team receive a backlog instead of a problem. Scratch the feature factory PM, and you find the same team measuring the work only by the part it can see — engineers occupied, features leaving the building. Scratch the loyal PM and you find an organisation that saw no reason to disturb a convenient arrangement that is working.

All these symptoms have one condition, and it's not the PM. It is a leadership team that never accepted that most of product work is the part you cannot watch happening — discovery, measurement, the coordination that keeps a launch from failing, the choreography of a rollout, building a business case for others, stakeholder alignment. None of it looks like much until it is missing.

This is, sadly, the conversation I rarely get to have, because the people who most need it are not the ones who book coaching. The PM arrives, thoughtful and slightly unsure, ready to work on themselves. The cause sits two floors up, un-coached and largely unaware, wondering aloud in the next town hall why the teams seem so flat.

I have had these three conversations perhaps fifty times now. I expect to have fifty more. The virtues that need cutting back are, after all, the ones worth having in the first place. Which is the whole trouble, and the reason a tally I never meant to keep keeps going up.

  1. A Singaporean bus timetable because, as we know, Indian buses don't work on a timetable. They are in fact the opposite of predictable. As far as I'm aware, buses outside Singapore don't have a timetable, and just arrive when they want to — like Gandalf.
  2. Subtraction is the only management technique that is both universally praised and never practised. It's like flossing, or candour with one's in-laws.
  3. There is no shame in being a queue. Queues are load-bearing; all civilisation runs on them. The trouble begins when the queue starts attending strategy offsites and calling itself a leader.
  4. Brandolini's Law (popularly known as the Bullshit Asymmetry Principle) is the bane of all corporate sanity. It takes mere seconds for an enthusiastic leader to type "what if we added a gamified layer to our checkout flow?" into Slack. Conversely, it takes three senior engineers, a data scientist, and an exhausted PM four weeks of historical metrics and structural modelling to prove why doing so will trigger immediate financial ruin.
  5. A door is not the same as an exit. An exit is a single dramatic act. The point of a door is that you need not walk through it. You only need to stop pretending the wall is a wall.
← All posts