If you spend any time observing the high priests of modern product management on LinkedIn, you would be forgiven for believing the entire profession is merely a game of paint-by-numbers. They speak of RICE scoring, OKRs, and two-by-two matrices as if they were holy sacraments capable of delivering a perfect feature directly from heaven to the end-user. There is a neat diagram for every crisis and an acronym for every midday panic.
I have spent the better part of a decade steering product teams through various stages of corporate evolution — from a frantic two-man startup to a venture-backed furniture marketplace, a $3.8 billion Southeast Asian superapp, and a clinical mental health platform.
The single truth I have brought back from the front lines is this: the actual job of a senior leader looks almost nothing like the textbook version.
The job is judgment. Everything else is just overhead.
The architecture of the "no"
When I joined Fabelio as their first senior product hire, the corporate mandate was delightfully vague: "Build the organisation." In the textbook, this means establishing pristine sprint ceremonies and elegant roadmaps. In reality, it meant walking into a room full of exceptionally bright, highly caffeinated people, looking at a list of twelve urgent crises, and gently explaining that we were going to let nine of them burn to the ground so we could fix the remaining three properly.
As organisations scale, the complexity ceases to be technical; it becomes tribal. At Grab, operating across six countries, every regional team possessed immaculate, data-backed arguments for why their local feature deserved immediate engineering blood, sweat, and tears.
The hardest part of leadership is not killing bad ideas. Bad ideas are transparently foolish and politically safe to execute via firing squad. The real test of nerve is saying no to a good idea.
We once had a loyalty programme feature at Grab that possessed everything a PM dreams of: glowing user research, guaranteed short-term revenue, and an engineering team practically begging to code it. I killed it because shipping it would have consumed the exact bandwidth we required to overhaul a tedious, entirely unglamorous piece of onboarding data infrastructure.
Try explaining that to a room of executives during a Quarterly Business Review. You are essentially telling a group of people who are judged on immediate yield that you are passing on a bag of cash today so that the plumbing functions slightly better in eighteen months. The data cannot save you in that meeting. Your conviction has to carry the room.
Holding the line against the maelstrom
Every product ecosystem eventually encounters a period where the sheer velocity of the market threatens to overwhelm its standards. Investors demand hockey-stick graphs, executives want features to flaunt at conferences, and engineers simply want to see their code breathing out in the wild. The incentives of the entire corporate machinery point toward moving faster, regardless of the wreckage left in the wake.
In these moments, the product leader is often the solitary figure whose job is to stand in front of the train and say, "This isn't ready."
At Intellect, we faced a classic three-way resource war. On one side: a critical safety workflow — the CISP process — that was entirely manual and operations-driven, begging to be productised. On another: a bespoke integration with an insurer that would have delivered immediate, contractually guaranteed revenue. And in the middle: a redesign of the entire care flow to introduce stepped-care triage, routing users to the right tier of support based on clinical acuity.
The insurer integration was the crowd favourite. It had a number attached to it, a client waiting, and a commercial team pacing the halls. The CISP productisation was the loudest operational pain point — the ops team was drowning. But I chose the care flow redesign, because without a proper triage and stepped-care architecture, every future feature — every insurer integration, every safety workflow, every AI enhancement — would be built on a foundation that couldn't distinguish between a user who needed a self-care nudge and one who needed immediate clinical intervention.
No framework can calculate the cost of getting that wrong. You simply have to possess the taste to know where the line is drawn.
Navigating the courtly politics
Because product leadership involves the allocation of scarce, highly coveted resources — namely, engineering hours — it is inherently political. You are the referee distributing chips in a game where everyone wants to win, and those who lose your favour tend to possess long memories.
The fatal trap for a rising leader is to transform into a courtier — a slick political operator who optimises for internal harmony rather than product truth. It is remarkably easy to greenlight a mediocre feature simply because it placates an incensed Vice President, or to build alliances instead of software.
The alternative is not to be a naive purist who ignores organisational dynamics. You must understand the power structures, but you must use that understanding as a shield for the product, not a ladder for your career. At Grab, the only approach that survived the matrix architecture was radical transparency. If you tell people precisely what you are building, what you are abandoning, and the exact logic behind the choice, they may still grumble, but they will accept the verdict. Human beings can tolerate a decision they disagree with; what they cannot abide is the feeling of being managed.
Encoding the taste
Ultimately, the true metric of a product leader is not the quality of the decisions they make; it is the quality of the decisions made by their team when they are nowhere near the room.
When you are a three-person outpost, you are involved in every single design critique and spec review. It is micro-management born of necessity. But when the team swells past twenty, that approach becomes a choke point. The role has to shift from exercising judgment to encoding it into the environment.
This is the only context in which process actually matters. A great product specification template is not bureaucratic paperwork; it is a forcing function that compels a young PM to confront edge cases and ethical implications before they write a single line of code. A solid prioritisation matrix is not an oracle; it is merely a shared vocabulary that transforms an emotional argument into a rational debate.
The most agonising transition in a leader's lifecycle is moving from "I make the best decisions" to "I am building the system where others can make them." It requires you to watch a product manager make a call slightly differently than you would have, and to keep your mouth shut because the institutional wisdom they gain from ownership is worth far more than your marginal aesthetic correction.
The frameworks are not inherently wrong; they are simply scaffolding. RICE scoring is a useful sorting hat, and OKRs provide a general direction of travel. But none of them will tell you when to hold the line, when to capitulate, or how to survive the fragile journey from an abstract insight to a living piece of software.
The exceptional leaders are not those with the cleanest slide decks or the most intricate matrices. They are the ones who have developed an unmistakable taste for what truly matters, the courage to enforce it when it is deeply unpopular, and the humility to change their minds the moment the data proves them wrong.