The Pragmatic PM
This is Part 4 of a series exploring product management as a system — not as a set of practices.
Operating Well From Where You Actually Are
The previous article ended on an observation worth sitting with: the gap between the FAANG ideal and the operating mode reality does not announce itself. It accumulates — in practices that lose their function, in ownership that does not hold, and in a growing sense that the problem is you.
It is not.
But naming the gap is only useful if it changes something. This article is about what changes.
The Wrong Question
Most conversations about FAANG product management and how to apply it elsewhere start from the wrong place. They ask: how do I apply this?
That question assumes the practices are the point. That if you can run the OKR cycle correctly, write a PRD that survives review, or frame a decision as a controlled experiment, you are doing it right.
You are not. Or rather — you might be doing the form correctly while losing the function entirely.
The right question is different: what is this principle actually trying to do, and what form can that take given what I actually control?
That reframe changes everything. Because it separates three things that most PM writing treats as one:
A principle is the intent — the problem the practice exists to solve. Data-driven decisions exist to reduce the role of opinion and preference in choices that affect users. Experimentation exists to reduce uncertainty before committing resources. Ownership exists to make accountability traceable so learning can accumulate.
A practice is the implementation — the specific form the principle takes under particular conditions. A/B tests. PRDs. OKRs. Working backwards memos. These are not the principle. They are what the principle looks like when the conditions fully support it.
A condition is what makes the practice work. Data-driven decisions require data that exists, is accessible, and arrives within the decision window. Experimentation requires scale, infrastructure, and the ability to roll back. Ownership requires decision authority that actually sits with the PM.
When you copy the practice without the conditions, you do not get a weaker version of the principle. You get something that looks like the principle but produces none of its function. The form is present. The intent is gone.
Translation vs Survival Adaptation
There are two things a PM can do when the conditions do not exist.
The first is translation — finding a different form for the same intent. The Operator mode PM who cannot run an A/B test but can pull twenty recent support tickets, map the pattern, and use that pattern as the constraint for their design decisions. The Negotiator mode PM who cannot let data resolve a stakeholder disagreement but can pre-negotiate decision rules before the data exists — agreeing in advance on what outcome would mean proceed, what would mean stop, so that the decision is made before the politics enter. The Pioneer mode PM who has no users yet and therefore no behavioral data but can design a weekly learning goal — “this week we learn whether customers will pay for X” — and treat that learning as the unit of progress, not features shipped.
In each case, the practice changes completely. The intent — reduce uncertainty before committing, connect decisions to evidence, make accountability traceable — is preserved.
The second is survival adaptation — keeping the practice name while letting the function die. The OKR that is written because the organisation requires it but is never used to make a decision. The experiment that cannot fail because the change was already committed. The ownership that exists in the job description but not in the authority structure. The PM says “we are data-driven” but the data is ignored when it contradicts the stakeholder’s preference. The form is present. The function is gone.
The difference between these two paths is observable. Translation changes how decisions are made. Survival adaptation changes how the work is presented.
The difference is not in how well the practice is executed. It is in whether the decision it produces is any better.
Most PMs do neither consciously. They operate somewhere in between — improving their execution of the mode they are in, working out what to keep and what to discard, without recognising that a different kind of move was available. Not because they lack the capability. Because translation was not a concept that was ever offered to them as a frame.
What Translation Looks Like From Inside Each Mode
Translation is not a generic skill. It takes a different form in each operating mode because each mode has different constraints and different available moves.
In the Operator mode, the conditions that FAANG practices assume — decision authority, measurable user outcomes, fast feedback loops — are largely absent. The PM does not choose what gets built. The roadmap came from above. The available data is operational: delivery timelines, ticket volumes, sprint velocity. The translated version of “data-driven decisions” is not a dashboard or an experiment. It is the discipline of asking, before every scope trade-off: which of these items has the clearest connection to a user problem we have actually heard about? Not a formal test. Not a metric. Just that question, asked consistently, used as a tiebreaker. The intent — decisions connected to user reality rather than internal preference — is preserved. The practice is unrecognisable by FAANG standards. The function is the same.
In the Negotiator mode, the conditions that fail are different. Data exists but it does not settle disagreements — stakeholders have legitimately different goals that cannot be collapsed into a single metric. The translated version of “let evidence decide” is not better data or more rigorous analysis. It is the practice of pre-negotiating decision rules before the data arrives. “We cannot agree on what success looks like right now. So let’s agree on what outcome, 30 days after launch, would mean we proceed versus stop. We commit to that rule now, before anyone knows who will be right.” That is the principle of evidence-based decision-making translated into a context where the standard practice would produce political theater instead of honest learning.
In the Experimenter mode, the conditions are closest to the ideal. Most FAANG practices can be applied here. But the specific failure in this mode is different — not missing conditions, but over-reliance on what can be measured. The translation needed here is a boundary: explicitly categorising decisions as testable versus requiring judgment versus representing a strategic bet. The PM’s job is not to run experiments on everything. It is to know which decisions an experiment can actually answer — and to own the ones it cannot, without hiding behind “we need more data.”
In the Architect mode, the conditions that fail are structural: long feedback loops, indirect outcomes, tight coupling across teams. The translated version of customer obsession is not a user journey map or a behavioral metric. It is a rule: no platform capability gets built until it has been manually implemented in at least two consuming contexts. This prevents premature abstraction — the trap of designing an elegant system around a problem that has never actually been encountered in practice. By requiring real usage before systemisation, the PM ensures the abstraction solves a genuine constraint rather than becoming a permanent one imposed on every team that builds on top of it.
In the Pioneer mode, no quantitative data exists yet. The translated version of “data-driven” is assumption mapping with explicit confidence levels — writing down each critical assumption, rating how confident you are in each one, and designing the smallest possible action that could move a low-confidence assumption to medium confidence before any code is written. The intent is identical to running an experiment: reduce uncertainty before committing resources. The form is a whiteboard exercise and a phone call, not a randomised controlled test.
Locating Yourself Before Translating
Translation requires knowing where you are. Not the mode your job description implies. Not the mode you aspire to. The mode you are actually in, based on what is actually happening in your day-to-day work.
Three questions cut through the stated operating model to the real one.
The first: when a decision that matters gets made, who actually makes it — and what inputs do they use? Not the formal process. The last three decisions that shaped your product. Who decided? What did they look at? That answer tells you where decision authority actually sits, regardless of what the org chart says.
The second: how long between a change you make and a signal about whether it worked? Days, weeks, months, or never? That gap defines what kinds of learning are even possible from where you stand. It also tells you which FAANG principles require translation and which ones require you to simply accept that the function is unavailable right now.
The third: what am I actually held accountable for — outputs or outcomes? Not what the performance review criteria say. What feedback have you received when things went well or badly? If you were praised for shipping on time rather than for whether the thing you shipped worked, you are in Operator mode regardless of your title.
These questions do not produce a label. They produce a constraint map — a clear-eyed view of what can and cannot be influenced from where you stand. And a constraint map is the prerequisite for translation, because you cannot translate a principle into a form that works under your actual constraints until you know what your actual constraints are.
One more distinction matters here: the difference between a structural constraint and a situational one.
A structural constraint comes from the organisation’s design, the product’s architecture, or the market reality. It persists across personalities and circumstances. Decision authority sitting above you is structural if it has been true across multiple leaders and is embedded in how the organisation is funded and governed. Long feedback loops are structural if they come from the nature of the product — a regulated system, an enterprise sales cycle, a hardware dependency.
A situational constraint comes from current circumstances — temporary resource limitations, a team still building trust, a manager who prefers control but is open to change. These are real constraints. But they are not permanent. They can shift with deliberate action, time, or context change.
The most common misclassification runs in both directions. PMs treat situational constraints as structural — they stop trying to change something that could actually be changed with enough clarity and patience. And PMs treat structural constraints as situational — they exhaust themselves trying to change something that is fixed by design, interpreting their failure to move it as a personal shortcoming rather than an accurate reading of the system.
A useful heuristic: if the constraint has existed across multiple leaders, across multiple projects, and everyone in the organisation treats it as “just how things work here” — it is structural. Work within it. If it appeared recently, if others acknowledge it as temporary, if a different set of circumstances would remove it — it is situational. It is worth applying effort to.
What the Organisation Will Not Do For You
Organisations optimise for execution within existing structures. They hire people for specific purposes and expect those purposes to be fulfilled well. The development of translation thinking — the ability to separate principle from practice, to assess conditions honestly, to find the adapted form that preserves intent — is not designed into the PM role. It is not part of onboarding. It is not what performance reviews measure. It is not what job descriptions describe.
This is not a criticism of organisations. It is simply an accurate description of how most of them work. The return on investment of developing a PM’s mental model of product management at a systems level is real but diffuse and long-term. Organisations rightly focus on the more immediate and measurable.
The implication is that the PM who develops translation thinking does so outside the formal role — independently, often triggered by something external: reading more deeply, preparing for a job change, finally having the distance to look back at a previous context clearly.
This is the pattern: the mismatch accumulates quietly while the PM is inside it. The adaptation happens, but it is survival adaptation — the form is preserved, the function quietly changes. The full picture only becomes visible from outside — when the PM is no longer in the context and can finally see it as a system rather than just a set of daily constraints.
That is not a failure. That is how most learning about complex systems works. The distance is necessary.
What It Produces
A PM who can name their mode, assess their actual conditions honestly, and translate principles rather than copy practices operates differently — not because their authority changed, not because the organisation changed, but because the reference point changed.
The most immediate effect is reduced misattribution. The PM can distinguish between “the system is not designed for what I am trying to do” and “I am not capable of doing this.” These two diagnoses have different implications. One points to a structural constraint that needs to be worked within or slowly changed. The other points to a skill gap that needs to be addressed. Confusing them — which is the default when there is no vocabulary for operating modes or translation — is how years of accumulated competence can be misread as a track record of inadequacy.
The second effect is more accurate judgment under constraint. A PM who understands translation does not try to run experiments when the conditions for valid experimentation do not exist. They do not claim outcome ownership when the authority structure does not support it. They do not perform rituals that have lost their function. They direct their effort toward what the principle is actually trying to produce — and find the form that can produce it, given what is actually available.
This does not move a PM out of their operating mode. An Operator remains an Operator. The constraints imposed by the organisation’s structure, the product’s architecture, the market context — those do not shift because the PM has developed a better framework. The mode is fixed by the system, not by the PM’s understanding of it.
What changes is what the PM does within it. And that, over time, is the thing that compounds.
The Question That Was Always There
The FAANG model is real. The principles behind it — customer obsession, evidence-based decisions, fast learning loops, traceable accountability — are not FAANG inventions. They are what good product management looks like when the conditions fully support it. They are worth understanding, worth using as a reference point, worth carrying as a lens.
But carrying a lens and copying a practice are different things. The PM who has understood the FAANG model at the level of principles — not practices, not artefacts, not vocabulary — has something more useful than a template. They have a diagnostic. They can look at any context and ask: what enabling conditions are present here? Which principles can be applied directly? Which ones require translation? Which ones are simply unavailable right now, and therefore need to be named honestly rather than performed?
That question — asked clearly, answered honestly — is the pragmatic PM’s primary tool. The goal is not to recreate the FAANG model in every context. It is to preserve the function of its principles wherever you are.
Most PMs were never missing capability. They were missing a way to see what they were already doing.
Most PMs never knew there was a difference between applying FAANG thinking and translating it. The question was always there. The vocabulary was not.
Now it is.