💜 Nobody rolls out anti-culture. It installs itself (by Alex Dziewulska)
💜 Empowered Doesn’t Mean “Leave the Team Alone”: In Defense of Marty Cagan Against His Own Quotes (by Łukasz Domagała)
💪 Interesting opportunities to work in product management
🍪 Product Bites - small portions of product knowledge
🔥 MLA week#59
Join Premium to get access to all content.
It will take you almost an hour to read this issue. Lots of content (or meat)! (For vegans - lots of tofu!).
Grab a notebook 📰 and your favorite beverage 🍵☕.
Every driver knows the blind spot. You check the mirror, the lane is clear, you pull out — and a car that was there the whole time leans on the horn. The mirror didn’t lie. The mirror shows you everything except one slice of reality. The slice with a car in it.
We carry the same spot inside us. A part of ourselves invisible from the driver’s seat that every passenger can see with the naked eye. And an entire floor of the product world is on the motorway right now, changing lanes from memory, absolutely certain its mirrors are set perfectly.
I know this leader. So do you. Transformation never leaves his mouth. Empowerment, team autonomy, culture of experimentation, fail fast — the whole vocabulary, fluent, convinced, no notes. He believes it. Genuinely. Then he walks into a product review, listens for two minutes, and “just has one suggestion.” The suggestion lands on the roadmap with the force of law. The team nods. Empowerment continues.
I know this PM too. Waves the roadmap like a battle flag. Outcomes, discovery, evidence-based, north star metric on the title slide. Then the sales director calls, and a feature no user has ever asked for slides quietly into the backlog. Labelled “quick win, high business potential.” The flag doesn’t even flutter.
And here’s the thing almost everyone gets wrong: these are not hypocrites.
A hypocrite knows. A hypocrite puts the mask on in the morning and takes it off at night and sets it on the nightstand. You can work with a hypocrite — change his maths and the mask goes in a drawer. These people have no mask. They believe every word.
Which is worse.
Chris Argyris and Donald Schön described this fifty years ago and nobody has done it better since. Each of us runs two theories of action. The first is the espoused theory — what you answer when someone asks how you operate. Your values, your principles, the leadership style from your LinkedIn bio. The second is the theory-in-use — the one that actually governs your behaviour when the bad news arrives on Thursday at 4:40 PM.
And now the part that makes Argyris worth reading: in almost everyone, the two theories diverge — and we cannot see the divergence. Not “won’t admit.” Cannot see. Argyris compared the theory-in-use to grammar: you’ve spoken fluently your whole life, but try reciting the rules you just used to build that sentence. You don’t know them. You apply them flawlessly — and you don’t know them.
So when you ask a leader about his leadership, you get the espoused theory. Sincerely, without a trace of cynicism, straight from the heart. Then you look at his calendar, at who got promoted, at his face when the metric turns red — and you’re reading the theory-in-use. Two different documents. The author knows only the first one.
The second document is known to his team. By heart.
The mechanism is simpler than it looks, which is exactly what makes it hard to get around.
We judge ourselves by our intentions. We judge everyone else by their behaviour. Not because we’re rotten — because the only person whose intentions you know from the inside is you. The entire rest of humanity is available to you exclusively from the outside. Emily Pronin called this the introspection illusion and demonstrated something beautiful in its cruelty: we spot other people’s cognitive biases effortlessly and our own not at all — and even when we’re handed access to someone else’s intentions, we go right on judging them by their behaviour. The benefit of the doubt flows in one direction. Always the same one.
So the leader asks himself: am I a transformational leader? And he checks his intentions. His intentions are immaculate — he sincerely wants autonomous teams. The team checks something else: behaviour. And it sees a man who personally killed three experiments this quarter and rearranged a sprint with one “suggestion.” Both sides are being honest with their data. The data just come from two different worlds.
Tasha Eurich measured this at scale and the result reads like a joke but isn’t: 95% of people believe they’re self-aware. Ten to fifteen percent actually are. A room full of people convinced they’re the exception is, statistically speaking, just a room.
And the higher you sit, the worse it gets — because feedback stops reaching you. Nobody tells the CEO that his “one suggestion” just invalidated a quarter of someone’s work. Power is the most reliable known method for enlarging a blind spot. You buy a bigger car and remove the mirrors. It comes as a package.
There’s an experiment that should hang in every product room in place of the values poster.
Daniel Batson gave people two tasks to distribute — one pleasant, with a reward, the other mind-numbingly dull. One for themselves, one for a stranger. And he offered an emergency exit for the conscience: you can flip a coin, that would be fair. Roughly half flipped.
Now the best part: of the people who flipped the coin, nine out of ten assigned the pleasant task to themselves.
A coin has two sides. The conscience, apparently, has one. And afterwards, these people rated their own morality highly — higher than the ones who’d simply grabbed the better task without ceremony. Because they had flipped a coin. The procedure took place. The fact that the outcome was decided before the toss somehow never made it into the ledger.
Now swap the coin for a prioritisation framework.
RICE scoring. The value/effort matrix. The dot-voting workshop. The PM conducts the entire ritual — and the director’s feature lands in the sprint anyway. The scoring checks out, of course it checks out: the weights were chosen after the decision, not before. The coin was flipped. Heads came up before it left the thumb.
And this PM isn’t lying when he says the process decides. He watched the process. He ran it himself. He has the notes. More than half the roadmaps on this market are built around outputs, not outcomes — in an industry where you will not find one person who couldn’t recite “outcomes over output” if you woke them at 3 AM. Somebody here keeps flipping a coin and always winning. And everyone is very surprised.
Batson checked one more thing, and this is the fragment that changes everything: putting a mirror in front of participants helped — but only when the fairness standard was established before they acted. After the decision, self-awareness fixed nothing. Worse — it went to work for the other side. The mind didn’t align the behaviour with the standard. It aligned the standard with the behaviour.
This is precisely why prioritisation criteria, success definitions, and kill conditions get written down before the start. Not because we’re bureaucrats. Because after the fact, every one of us is our own defence attorney — and that attorney works for free and never sleeps.
Which leaves the question of why the seal is so tight. If the gap between what we declare and what we do is this universal, why don’t we just look at it and fix it?
Because it hurts. Concretely, measurably hurts.
Tory Higgins showed that we carry an actual self and an ideal self, and that confronting the gap between them produces not reflection but emotion — disappointment, sadness, shame. The psyche treats that confrontation as a threat and does what one does with threats: builds defences. Argyris named the end state skilled incompetence. We are so practised at protecting ourselves from embarrassment that the practice itself strips us of the ability to learn. This is not a missing skill. It is a skill. Mastered, rehearsed daily, polished to perfection — the skill of not finding out about yourself.
And inside an organisation, these individual defences interlock into a system. Your blind spot is plainly visible to me — and mine to you. We could enlighten each other in five minutes. We don’t, because an unwritten non-aggression pact is in force: I don’t mention yours, you don’t mention mine, and we both get to keep living in our espoused theories. Argyris had a word for this: undiscussables. The most important problems in an organisation are the ones that cannot be discussed. And the fact that they cannot be discussed — cannot be discussed either.
Supposedly 70% of transformations fail. That number has been circulating for thirty years, slide deck to slide deck, and nobody has ever located the study it comes from — because there isn’t one. An industry that professionally demands evidence-based decisions has spent three decades citing a statistic with no evidence. I’ll leave that here without comment, as an exhibit.
In the 1950s, two psychologists named Joseph and Harrington glued their first names into “Johari” and drew a window that has been drawn on every communications training flipchart since, usually with the most important part missing. The window has four quadrants, but only one matters: what others know about you and you don’t. The blind spot, formally named.
The most important part is this: no introspection reaches that quadrant. By definition. You can meditate for a decade, keep a journal, run your annual “reflections” — you will not see what your team sees every Tuesday at 10 AM. Only one thing shrinks that quadrant: someone else’s voice, allowed to finish the sentence.
And no, the annual 360 dutifully ticked off in the HR system doesn’t cover it. Feedback changes something only in people who admit the second document exists at all — that theory-in-use they’ve never read. In everyone else it bounces off the defences and comes back as “an interesting perspective, though it doesn’t quite capture the context.”
The stakes aren’t philosophical. Tony Simons priced them, in hotels: the alignment between a manager’s words and deeds — whether he does what he says — correlated with financial results more strongly than any other factor measured. One-eighth of a point on that alignment scale translated into 2.5% of revenue. Trust is not a value from a poster. It’s a line item in the P&L — booked whether you can see it or not.
I write in this issue that nobody rolls out anti-culture, because it installs itself — that in organisations, whatever is cheaper wins. That story is about the system. This one is about why the system is such a comfortable place to live: because none of us sees ourselves as a resident. The yes man from that essay has courage in his espoused theory. The solo doer has ownership. The HiPPO leader has “evidence-based” framed on the office wall. The system is built out of people, every one of whom is certain he’s standing next to it.
So you will not find out who you are by asking yourself. You’ve already run that test — and the result came back excellent, the way it always does when the author of the exam is its only participant.
The espoused theory hangs on the wall, next to the company values. The theory-in-use is held by your team. Kept in notes they won’t show you until they believe you’re really asking.
Ask. Or don’t — but then stop telling everyone your mirrors are set.
There’s a conference happening 270 kilometers from my desk in September, and most of the product people I know in Poland still book flights to London or Lisbon to see the same speakers. I want to fix that.
WaysConf is in Kraków on 16–17 September, with a separate workshop day on the 15th. Marty Cagan and Brad Frost are keynoting. Debbie Levitt and Petra Wille are running workshops. Then it goes deep on working practitioners rather than circuit speakers — staff designers from Meta and Shopify, research leadership from Wise, a Principal AI Designer from Intercom, product leaders from Kraken and IKEA.
Here’s my one piece of unsolicited advice, and it’s the contrarian one: do not build your two days around the keynotes. You can watch Cagan on YouTube tonight, in your pajamas, for free. What you cannot get on YouTube is the case study about what actually broke, the roundtable where people who run research orgs argue about maturity, or the speaker who contradicts the one you heard ninety minutes earlier. Conferences that only platform one worldview are just expensive newsletters read aloud. WaysConf isn’t that. The speakers counter-argue each other, and that’s the point.
The theme this year is “Building What Matters” — good decisions under real constraints, in an AI-accelerated, ship-faster world. I spend most of my time on the gap between what the AI-product discourse claims is happening to teams and what is actually happening to teams. A room full of practitioners presenting real case studies, in our region, is exactly where that gap gets argued out by people living it rather than people monetizing the narrative about it.
And the unglamorous part: if you run a small studio or sit on a Polish team budget, a Kraków train ticket and a conference pass is a different financial event than flying a team to San Francisco. Same caliber of speaker, fraction of the friction. The room is people you’ll keep running into for the rest of your career, mostly within a few hours of where you already work.
So go. Block the 16th and 17th, decide whether the workshop day is worth the extra ticket, and spend your time in the case-study rooms and the hallway — not the front row of every keynote.
The keynotes will be on the internet by October. The conversations won’t.
WaysConf 2026 · 16–17 September (workshops 15 Sept) · EXPO Kraków + online · waysconf.com
Do you need support with recruitment, career change, or building your career? Schedule a free coffee chat to talk things over :)
Product Manager - Worldline
Product Manager - GetResponse
Senior Product Manager - Zartis
Product Manager - Inpost
Product Manager - Dietly
Thomas Schelling, the economist who would later win a Nobel Prize for his work on game theory, wrote a sentence in 1968 that has haunted decision science ever since. Harm to a particular person, he observed, invokes anxiety and sentiment, guilt and awe, responsibility and religion. But most of this awesomeness disappears when we deal with statistical death.
The observation has been formalized, tested, replicated, contested, and applied across charitable giving, public policy, and criminal justice. It has a name: the identifiable victim effect. And it operates continuously inside product organizations, shaping which problems get solved, which users get served, and which data gets acted on — usually without anyone naming it.
A product team is in a prioritization meeting. Two items are on the table.
The first is supported by a customer story. A named account manager describes a specific customer — a company the team knows, a person the team has met on a call — who ran into a workflow gap last Tuesday. The account manager describes their frustration in detail, including a quote from the email they sent. The story lands. Everyone in the room can picture it.
The second is supported by analytics. Eleven thousand users encounter a friction point in the activation funnel every month. The drop-off is measurable. The revenue impact is estimable. No one in the room has met any of these eleven thousand people, and no one has a story about them.
The first item goes on the roadmap.
This is not an irrational meeting. Everyone in the room is capable, experienced, and acting in good faith. The mechanism operating is older and more fundamental than any prioritization framework: a specific person produces feeling, and a statistic does not.
The identifiable victim effect is the tendency to offer greater help to a specific, identifiable individual than to a large, statistically-described group with the same or greater need.
The effect was conceptualized by Thomas Schelling in 1968 and formalized experimentally by Karen Jenni and George Loewenstein in 1997, with a widely-cited follow-up by Deborah Small, George Loewenstein, and Paul Slovic in 2007. The Small, Loewenstein and Slovic study examined donation behavior toward identified versus statistical victims and found a robust preference for the identified case — and, more strikingly, that teaching people about the discrepancy reduced giving to identifiable victims without increasing giving to statistical ones. Awareness produced less overall generosity rather than more equitable generosity.
Research has identified a related pattern called the singularity effect: people help a single identified person more readily than several identified people with the same need, even when the cost of helping is held constant. The effect is not about identification alone. It is about the number of individuals the mind is being asked to hold.
An honest account requires noting that the literature has become contested. A 2023 pre-registered replication of the Small, Loewenstein and Slovic studies, published in Collabra, found no support for the effect in that specific paradigm, and a reanalysis of an earlier meta-analysis suggested publication bias in the literature. The mechanism remains widely accepted; the size and reliability of the effect in specific experimental designs is less settled than its popular treatment suggests.
What is not contested is the underlying asymmetry: specific individuals produce affective response, and aggregates do not. That asymmetry is directly observable in how product organizations make decisions.
The research consistently identifies emotional response as the driver. Both self-reported feelings and physiological measures of affect are larger for identified than unidentified individuals. The identifiable case activates a system that the statistical case leaves dormant.
This matters for product teams because it explains why the effect is not correctable by better data presentation. The problem is not that the statistic is unclear or poorly visualized. The problem is that no amount of clarity converts a number into a feeling, and the feeling is what drives the prioritization decision.
Teams that respond to this by making dashboards more compelling are treating a comprehension problem that does not exist.
One explanation proposed in the literature is proportion dominance: people are more sensitive to proportions than to absolute values. An identifiable individual is the entire reference group, so helping them registers as helping one hundred percent of those affected. Eleven thousand users out of a base of two million registers as a small percentage, even though the absolute number is vastly larger.
This produces a specific and predictable distortion in product prioritization. Problems affecting a small, well-defined, visible group feel more solvable and more worth solving than problems affecting a larger but diffuse population, because the first presents as a complete problem and the second as a fraction.
The most counterintuitive finding in the Small, Loewenstein and Slovic work is what happened when participants were prompted to think analytically. Deliberation reduced sympathy toward the identifiable victim without generating sympathy toward the statistical one. The net effect was less caring overall.
For product organizations, this suggests that the corrective for identifiable-victim distortion is not simply more analytical rigor. Teams that respond by discounting customer stories and relying exclusively on aggregate data may lose the motivational energy that specific cases provide without gaining proportionate commitment to the larger problem. The result can be a team that is analytically correct and organizationally inert.
There is a mirror phenomenon sometimes called the identifiable perpetrator effect: people are more willing to impose costs on a specific identified party than on a diffuse one. In product contexts, this appears as disproportionate response to the named complaining customer, the specific competitor, or the individual whose bug report was loudest — regardless of whether that response serves the broader user base.
The bias is not toward kindness. It is toward specificity, in both directions.
Amazon’s practice of leaving an empty chair in meetings to represent the customer is a deliberate engineering of the identifiable victim effect in service of the aggregate. The chair is a device for making a diffuse population feel present. Jeff Bezos’s related practice of forwarding customer emails to executives with a single question mark operates on the same principle: a specific email from a specific person produces organizational response that a support-volume metric describing the same problem does not. The mechanism is being used deliberately rather than being corrected — a recognition that the effect is easier to harness than to defeat.
Intercom’s approach to combining qualitative and quantitative signal reflects an awareness of the trap on both sides. The company has written about the risk of building for the loudest customer while also acknowledging that pure aggregate analysis produces teams that do not feel the problems they are solving. Their practice pairs specific customer narratives with the quantitative context establishing how many users the narrative represents — using the story for motivational energy and the number for prioritization weight. This is a structural response to the effect rather than an attempt to suppress it.
Charity: water built its early growth on the identifiable victim effect applied deliberately and transparently. Rather than presenting aggregate statistics about global water access, the organization presents specific villages, specific wells, and specific people, with photographs and GPS coordinates linking a donor’s contribution to an identifiable outcome. The design choice is a direct application of the research: donors respond to the individual case. The organization’s transparency about the mechanism — showing exactly which project a donation funded — converts what could be manipulation into an accountability structure.
The identifiable victim effect matters for product teams because it systematically biases prioritization in a direction that is invisible from inside the process.
The customer story that made it into the meeting was not selected randomly. It arrived because an account manager had a relationship, because a support ticket escalated, because a user happened to be articulate on a call. The selection mechanism correlates with account size, communication style, and organizational proximity — not with representativeness. Prioritizing by the vividness of available stories means prioritizing by a filter that has nothing to do with impact.
The compounding consequence is a roadmap weighted toward the visible: enterprise accounts with named contacts, users who complain articulately, problems that arrive with a face attached. The silent majority — users who churn without a ticket, prospects who bounce without a conversation, the eleven thousand in the funnel — are structurally underweighted in every prioritization meeting, because they arrive as numbers.
The mirror risk is equally real. A team that responds by rejecting qualitative signal entirely loses something important: the specific case is where mechanism becomes visible. The aggregate tells you how many people have the problem. The individual tells you what the problem actually is. Discarding the second in favor of the first produces teams that can size problems they do not understand.
Attach magnitude to every story and a story to every magnitude. When a specific customer case is presented, require the accompanying question: how many users does this represent? When aggregate data is presented, require a specific example that illustrates the mechanism. Neither signal should travel alone. The pairing preserves the motivational force of the individual case while anchoring it to the actual scale of the problem.
Audit whose stories reach the prioritization meeting. Track, over a quarter, which customers generated the narratives that influenced roadmap decisions. If they cluster by account size, by relationship with a specific account manager, or by communication style, the story pipeline is filtering by proximity rather than importance — and the roadmap is inheriting that filter.
Give the silent majority a face deliberately. If eleven thousand users encounter a friction point, find three of them and talk to them. This is not a research substitute for the aggregate data; it is a mechanism for making the aggregate emotionally present. The Amazon empty chair works on the same principle: the diffuse population needs representation to compete with the vivid individual.
Watch for the singularity effect in customer advocacy. When one named account’s problem receives more attention than the same problem affecting several accounts, the effect is operating. The one-versus-many asymmetry is measurable and worth flagging explicitly when it appears.
Schelling’s insight was not that people are irrational about statistics. It was that statistics and individuals are processed by different systems, and only one of those systems produces the feeling that motivates action.
Product organizations have inherited a fantasy that better data will resolve this. If the dashboard were clearer, if the analysis were more rigorous, if the impact were properly quantified, the right decision would follow. The research suggests otherwise. Deliberation reduces the pull of the specific case without generating pull toward the general one. Analytical rigor produces correctness without commitment.
The teams that navigate this well do not try to defeat the mechanism. They use it. They find the face for the aggregate, attach the number to the story, and build prioritization processes that require both. The individual case supplies the reason to care. The number supplies the reason to care about this one rather than that one.
One user you have met will always weigh more than ten thousand you have not. The task is not to correct that — it is to make sure you have met someone from every group that matters.
In 1976, an organizational psychologist named Barry Staw published a paper with a title borrowed from a Pete Seeger protest song about the Vietnam War: “Knee-Deep in the Big Muddy: A Study of Escalating Commitment to a Chosen Course of Action.”
The reference was deliberate. Staw was trying to explain a pattern he had observed in organizations and in national policy: decision makers receiving clear evidence that an investment was failing frequently responded by investing more. Not by hesitating, not by reassessing — by increasing commitment.
His experiments isolated the variable that predicted this most strongly, and it was not optimism, incompetence, or poor data. It was personal responsibility for the original decision. People who had chosen the failing course allocated substantially more additional resources to it than people who had inherited someone else’s failing course.
This is escalation of commitment, and it is the mechanism by which product organizations keep funding things everyone privately knows are not working.
A product initiative launched fourteen months ago. It was well-reasoned at the time: a new customer segment, a genuine market gap, an executive sponsor who believed in it. Four engineers and a designer were assigned.
By month six, the leading indicators were weak. By month nine, they were clearly bad. The response was not to stop. It was to conclude that the product needed more capability to demonstrate its value, and to add two engineers.
By month twelve, the metrics had not moved. The team’s assessment was that the go-to-market motion had been wrong, and a dedicated growth resource was added.
At month fourteen, in a hallway conversation, three separate people on the team independently describe the initiative as something that should have been killed a year ago. None of them has said this in a meeting. The executive sponsor, who has publicly championed the initiative in two board presentations, has not asked whether it should continue. The question has never appeared on any agenda.
The initiative is not being funded because anyone believes in it. It is being funded because stopping it requires someone to say that the last fourteen months were a mistake.
Escalation of commitment is the pattern in which individuals or organizations continue investing in a chosen course of action despite mounting evidence that it is failing, often increasing investment as the evidence worsens.
Staw introduced the concept in 1976 through experimental work in which participants took the role of managers allocating resources, with some outcomes rigged to fail. His central finding was that personal responsibility for the initial decision was the strongest predictor of escalation. Participants who had made the original allocation committed significantly more additional resources after negative feedback than those who had not.
Staw’s explanation drew on cognitive dissonance theory. A decision maker facing evidence that their choice was wrong has two options: revise their assessment of the decision, or revise their interpretation of the evidence. The second is psychologically cheaper. Rather than accepting that the prior decision was poor, the decision maker cognitively distorts the negative feedback — treating it as temporary, as evidence that more investment is needed, or as a signal about execution rather than about the underlying bet.
The literature since has examined the phenomenon across finance, marketing, accounting, information systems, and project management. Documented large-scale cases include Expo 86 in Vancouver, the Sydney Opera House, the Shoreham nuclear power plant, and Denver International Airport — each a project where escalating investment continued well past the point where the original economics had collapsed.
The distinction from simple sunk cost fallacy matters. Sunk cost is a reasoning error about how past expenditure should factor into future decisions. Escalation of commitment is a broader organizational and psychological phenomenon that includes sunk cost but is driven primarily by responsibility, identity, and social accountability.
Staw’s core experimental finding is the most practically useful part of the framework: escalation is strongest when the person deciding whether to continue is the person who decided to start.
This has a direct organizational implication. The default structure in most product organizations — where the executive sponsor who championed an initiative also holds authority over whether it continues — is precisely the configuration that maximizes escalation. The person best positioned to see the evidence is the person least psychologically equipped to act on it.
Separating the continuation decision from the initiation decision is not a matter of distrust. It is a structural correction for a documented and predictable bias.
Research has identified perceived proximity to completion as an escalation driver. A project believed to be nearly finished attracts continued investment more readily than one believed to be at the midpoint, because the remaining cost feels small relative to what abandonment would waste.
The trouble is that in software, perceived completion is unreliable and systematically optimistic. A project that has been ninety percent complete for four months is not nearly finished; it is in a state that the estimation process cannot represent. Escalation dynamics feed on this, because each additional increment is justified by a completion estimate that has been wrong every previous time it was made.
Escalation is not solely an individual phenomenon. Staw’s later work and subsequent research identified group dynamics that reinforce it: teams that have publicly committed to a direction develop norms that discourage reassessment, and individuals who raise doubts face social costs that individuals who express continued confidence do not.
This produces the hallway-conversation pattern. Private assessments diverge sharply from public ones. Everyone believes the project should stop; no one says it, because saying it means being the person who broke ranks, and because the person who would have to accept the failure has more organizational power than the people observing it.
The most insidious property of escalation is that it operates on interpretation rather than on data availability. Teams in escalation are not hiding the numbers. They are reading them differently.
Weak adoption becomes evidence that the market needs education. Poor retention becomes evidence that a missing feature is blocking value. Slow sales become evidence that the go-to-market motion needs adjustment. Each interpretation is individually plausible. The pattern — that every piece of negative evidence produces a hypothesis requiring additional investment — is the diagnostic signature, and it is only visible in aggregate.
Google’s practice of publicly discontinuing products represents an unusual organizational tolerance for termination. Google Reader, Google+, Inbox, Stadia, and dozens of others were shut down while still having users and, in some cases, advocates. The practice generates real costs — user trust erosion and a running joke about Google’s product graveyard — but it also demonstrates an organizational capacity that escalation-prone companies lack. The willingness to absorb the reputational cost of visible termination is what makes termination possible at all. Companies that cannot tolerate the appearance of failure cannot stop failing projects.
Amazon’s Fire Phone provides a case study in both directions. The product launched in 2014, performed poorly, and was discontinued within roughly a year, with Amazon taking a public writedown of approximately 170 million dollars. The speed of termination was notable for a project with strong executive sponsorship — the Fire Phone had been personally championed by Jeff Bezos. Bezos’s subsequent public framing, treating the failure as an acceptable cost of experimentation and explicitly connecting the learning to later successes including the Echo, functions as an escalation countermeasure at the cultural level: if failure is framed as an expected output of experimentation, terminating a failing project does not require anyone to admit a mistake.
The Denver International Airport baggage system, frequently cited in the escalation literature, illustrates the pattern at maximum severity. The automated baggage handling system was years late and hundreds of millions over budget, with clear evidence of unworkability available long before the project was abandoned. Continued investment persisted in part because the airport’s opening was contingent on it and in part because responsibility for the original decision sat with the parties evaluating continuation. The system was eventually scrapped entirely, after costs that dwarfed what early termination would have incurred.
Escalation of commitment matters for product organizations because it converts the most expensive category of error — building the wrong thing — into a sustained expenditure rather than a bounded one.
The initial decision to pursue a failing initiative is a normal product error, and product organizations make them routinely. The cost of that error should be bounded by how quickly it is recognized and stopped. Escalation removes the bound. A three-month mistake becomes an eighteen-month mistake, not because the evidence was unclear, but because the organization had no mechanism for acting on evidence that implicated a prior decision.
There is also an opportunity cost that is structurally invisible. The engineers on the escalating initiative are not available for anything else. That cost never appears in any assessment of the initiative, because the assessment is always framed as whether to continue rather than as what else the resources could do.
The organizational damage compounds beyond the specific project. Teams that watch a clearly failing initiative continue for a year learn something about how the organization handles evidence — and what they learn is that surfacing bad news does not produce action. The next team to discover their initiative is failing will surface it more slowly.
Separate the continuation decision from the initiation decision. Staw’s finding points directly at this: the person who started the initiative should not be the sole person deciding whether it continues. Building a review structure where continuation decisions include people with no responsibility for the original choice removes the specific variable that most strongly predicts escalation.
Define kill criteria before starting, in writing. The only moment at which a project can be evaluated without escalation dynamics is before it begins. Specifying in advance what result would constitute failure — what metric, at what threshold, by what date — converts a future judgment call into a pre-committed decision. This does not eliminate the difficulty of stopping, but it removes the need for anyone to argue that the project is failing.
Watch for the interpretation pattern rather than any single interpretation. No individual explanation for weak results is diagnostic; each may be correct. The signature of escalation is that every piece of negative evidence has produced a hypothesis requiring more investment. Reviewing the sequence of explanations over a project’s life makes this visible in a way that evaluating any single explanation cannot.
Create a legitimate path for termination that does not require an admission of error. Amazon’s framing of failure as an expected output of experimentation is functionally a mechanism for lowering the psychological cost of stopping. Organizations that treat termination as evidence of good portfolio management rather than as evidence of poor judgment will stop failing projects earlier — not because their people are more rational, but because the social cost of the decision has been reduced.
Ask the resource question rather than the continuation question. Framing the decision as “should we continue this?” invites escalation, because it centers the prior investment. Framing it as “if these four engineers were unassigned today, would we assign them to this?” removes the prior investment from the frame entirely. It is the same decision, asked in a way that does not activate the mechanism.
Staw took his title from a song about a patrol wading into a river that gets deeper with every step, following a leader who refuses to turn back because turning back would mean admitting the crossing was a mistake. The metaphor is precise. The problem is not that the water is deep. The problem is that each additional step makes turning back more costly, and the person deciding whether to continue is the person who chose the crossing.
Product organizations wade into these rivers regularly, and most of them do not have a mechanism for turning around. The evidence is available. The private assessments are accurate. What is missing is a structure that allows the organization to act on what it knows without requiring anyone to accept blame for what it committed to.
The teams that escape do not have better judgment about which initiatives will fail. They have better structures for stopping the ones that do — kill criteria set in advance, continuation decisions separated from initiation, and a culture where terminating a project is evidence of discipline rather than evidence of failure.
Every project should have an answer to one question, written down before it starts: what result would make us stop?
Without that answer, the water only gets deeper.
Product teams spend enormous effort on two moments: the first time a user arrives, and the moment a user leaves. Onboarding is instrumented, tested, and optimized. Churn is analyzed, modeled, and attacked with win-back campaigns.
Between them sits a third moment that almost nobody designs: the user who left, and came back.
They open the product after three months. They are not new — they have an account, history, and some memory of how this works. They are not current — the interface has changed, their data is stale, their context is gone. They exist in a state the product has no representation for, and so the product does what it does for everyone else: it shows them the standard experience, identical to what a user who was here yesterday would see.
This is a design failure, and it happens at one of the highest-intent moments in the entire user lifecycle.
A project management tool runs a win-back campaign targeting users dormant for ninety days or more. The campaign is well-executed: segmented messaging, a genuine reason to return, clean creative. Click-through rates are strong. Thousands of lapsed users return to the product.
Within two weeks, the large majority are dormant again.
The post-mortem focuses on the campaign — the messaging, the incentive, the targeting. All of it performed well. Users clicked. Users arrived. What happened next was that they landed in a workspace containing four-month-old projects with overdue dates, a redesigned navigation they did not recognize, and an interface that assumed continuous context they no longer had. They looked at it, felt the weight of catching up, and closed the tab.
The campaign successfully solved the problem of getting them back. Nothing in the product had been designed for what happened after they arrived.
The comeback path is the experience a returning user encounters after a period of absence — and the design discipline of treating that experience as distinct from both first-time onboarding and ordinary continuing use.
Google’s Play growth team articulated the principle directly in guidance for app developers: create a returning user flow, and make re-onboarding as considered as first-time onboarding. Their specific recommendation is to walk through each onboarding screen and ask whether a lapsed user would benefit from seeing it — tweaking what would help, excluding what would not.
The framing matters. A returning user is not a new user, because they have prior knowledge, existing data, and a formed mental model. They are not a continuing user, because that model may be outdated, their data is stale, and the reason they left has not necessarily been addressed. They are a third category, and most products have no representation for it.
What makes this category strategically significant is intent. A user who returns after months of absence has taken deliberate action. They responded to something, or remembered something, or had a need resurface. Whatever the trigger, they arrived on purpose. That is a stronger signal than the average new visitor provides — and it typically receives a weaker experience.
The most immediate obstacle facing a returning user is that their data has aged in ways that make it hostile.
Tasks are overdue. Projects are stale. Dashboards show metrics from a period that no longer matters. Notifications have accumulated into an unreadable pile. The workspace that was organized when they left is now a record of things they did not do.
For a continuing user, this state accumulates gradually and is managed continuously. For a returning user, it arrives all at once as an undifferentiated mass of obligation. The emotional response is not motivation — it is the specific fatigue of confronting accumulated neglect. Many users close the product at this point, and the product interpreted their return as a session.
Designing the comeback path means deciding what the returning user should see instead: an archived state, a summarized state, a clean slate with the option to recover, or a deliberate triage flow. Any of these is better than the default, which is showing them everything.
A product that has shipped continuously for six months is not the product the returning user knew. Navigation may have moved, terminology may have changed, workflows may have been restructured.
For continuing users, these changes arrived incrementally with whatever contextual introduction accompanied each release. The returning user gets all of them simultaneously, with none of the introduction, and experiences the accumulated delta as disorientation.
Google’s guidance addresses this specifically: returning users benefit from being caught up on what has changed, with the same care that new features receive when introduced to active users. The team knows exactly what has shipped since any given date. Surfacing the relevant subset to a returning user is a tractable problem that almost no product solves.
A user who lapsed did so for a reason. Sometimes the reason is external — a project ended, a role changed, priorities shifted. Sometimes it is internal to the product — a friction point, a missing capability, a pricing decision.
Where the reason was product-internal, returning the user to the same experience returns them to the same reason. Win-back campaigns that highlight what has changed are effective precisely because they address this; a product experience that highlights nothing does not.
The distinction is worth making at the segment level. Research on subscription win-back suggests that users who were highly engaged and then left abruptly often churned for a specific, solvable reason, while users who were never deeply engaged typically never found value in the first place. These two populations warrant different comeback paths, and treating them identically wastes the more recoverable one.
The simplest intervention, and one that products almost universally skip, is acknowledging that the user was away.
A returning user who sees a generic interface receives an implicit message: nothing about your absence registered. A returning user who sees an explicit welcome back, with an offer to catch them up or pick up where they left off, receives a different one. Google’s guidance recommends this directly, and the mechanism is straightforward: acknowledgment signals that the product has a model of the user’s relationship with it rather than treating every session as identical.
Duolingo built re-onboarding into its product after a major redesign, specifically because the scale of its returning-user population made the disorientation problem acute. Users who had lapsed for months and returned encountered an interface they did not recognize, and the resulting confusion damaged retention among a segment that had already demonstrated intent to return. The solution was a deliberate walkthrough for returning users covering what had changed — treating them as a distinct population with distinct needs rather than routing them into either the new-user flow or the standard experience.
Spotify’s approach to returning users leans on the stale state problem in reverse. Rather than presenting a dormant library, the product surfaces recommendation surfaces that are current regardless of absence — new releases, algorithmically generated playlists, and content that has accumulated since the user was last present. The design turns absence into an advantage: the longer someone has been away, the more new material there is to surface. Products whose value is content-based can use this structure; products whose value is user-generated state generally cannot, which is precisely why the stale state problem hits productivity tools hardest.
Fabulous, a habit-tracking app, handles the returning user with explicit acknowledgment framed around the user’s own narrative rather than the product’s metrics. The returning experience opens by naming the absence and framing continuation as a story that is not finished, rather than presenting a broken streak and a record of missed days. The design choice recognizes that in habit products, the returning user’s primary obstacle is the psychological weight of having lapsed — and that presenting the evidence of lapse is the fastest way to produce a second one.
The comeback path matters because returning users are among the highest-intent, lowest-cost, most recoverable population a product has — and because the default experience actively works against recovering them.
The acquisition economics are favorable. A returning user requires no acquisition spend, has already navigated signup, and in subscription products often still has billing information on file. Recurly’s subscription research has found that a meaningful proportion of new subscriptions come from previously canceled subscribers. The population is real and commercially significant.
The intent signal is strong. Unlike a new visitor arriving from an ad, a returning user has taken deliberate action based on some memory or trigger. They have already decided to give the product another look. The remaining question is entirely about what happens in the first minutes after they arrive — which is exactly the part that is undesigned.
There is also a measurement gap. Most products do not distinguish returning users from new or continuing ones in their analytics, which means the comeback path’s performance is invisible. A product could be losing the majority of its returning users in the first session and have no metric that would surface it, because those sessions are aggregated into general engagement numbers.
Define the returning user as a distinct segment in analytics. Before designing anything, instrument the population: users returning after a defined absence threshold, tracked separately through their first sessions back. Their activation, retention, and drop-off patterns will differ from both new and continuing users. Without this segmentation, the problem is invisible.
Walk the onboarding flow with a returning user in mind. Google’s specific guidance is the most actionable starting point: for each screen and moment in first-time onboarding, ask whether a lapsed user would benefit from it. Some elements should be reused, some tweaked, some excluded entirely. The exercise takes an afternoon and produces the skeleton of a comeback path.
Design an explicit answer to the stale state. Decide what a returning user sees when their data has aged: automatic archiving, a summarized digest, a triage flow, or an offer to start clean with recovery available. Any deliberate answer outperforms the default of presenting everything accumulated. The right choice depends on the product, but the choice must be made rather than defaulted into.
Surface what changed, scoped to the absence. The product knows what shipped between the user’s last session and this one. Presenting a relevant subset — not a full changelog, but the changes that affect what this user did — addresses the disorientation problem with information the team already has.
Segment the comeback path by churn reason where possible. Users who left because of a specific solvable issue and users who never found value need different experiences. Where exit signal exists — cancellation reasons, support history, usage patterns before lapse — using it to differentiate the comeback path concentrates effort on the population most likely to be recovered.
There is an asymmetry in how product organizations allocate design attention across the user lifecycle. The first session receives enormous investment, because activation is understood as decisive. The churn moment receives investment, because retention is measured. The return receives almost none, because it falls between the two frameworks and belongs to neither team.
This is a structural gap rather than a judgment error. Growth teams own acquisition, retention teams own churn, and the user who has churned and come back is at the seam. The experience they encounter is whatever the product does by default, which is the experience designed for someone else.
The users who come back are telling the product something: that the value was real enough to remember, and that whatever drove them away was not permanent. That is the best signal a lapsed user can send.
Most products answer it with the same screen they show everyone.
Design the door they walk back through. They already decided to open it.
The Minimum Lovable Action (MLA) is a tiny, actionable step you can take this week to move your product team forward—no overhauls, no waiting for perfect conditions. Fix a bug, tweak a survey, or act on one piece of feedback.
Why it matters? Culture isn’t built overnight. It’s the sum of consistent, small actions. MLA creates momentum—one small win at a time—and turns those wins into lasting change. Small actions, big impact
In the 1950s, Solomon Asch ran a series of experiments that made people deeply uncomfortable about their own judgment. Participants were shown two cards: one with a single line, one with three lines of different lengths. The task was simple — identify which of the three lines matched the reference line. The answer was obvious. And yet, when confederates in the room gave the same wrong answer out loud, roughly 75% of participants agreed with the incorrect answer at least once. Not because they couldn’t see the truth. Because the social pressure of disagreement was stronger than the evidence in front of them.
Asch was studying conformity. What he was really mapping was the human cost of being the person in the room who says something different.
Research shows that when individuals encounter authoritative figures, certain brain regions associated with decision-making show less activity — a measurable relinquishment of independent judgment. This isn’t weakness — it’s neurology. Humans evolved in hierarchies where disagreeing with dominant members carried real risk. The instinct to align with authority, to soften a position when someone more senior pushes back, to find merit in the opinion of the loudest voice in the room — these are not character flaws. They are deeply wired responses that served a purpose in a very different environment.
In product work, they’re a liability.
In boardrooms and project meetings, people regularly agree with the boss’s plan not because it’s correct — but to avoid trouble. The desire to maintain harmony and job security overrides professional judgment more often than most people want to admit. The PM who changes their roadmap recommendation after a VP expresses skepticism — not because the VP provided new information, but because the VP expressed skepticism — has let sycophancy into a product decision. The designer who softens critical user research findings before presenting them to a founder who’s emotionally invested in the direction. The analyst who adjusts the framing of data to match what leadership wants to hear. None of these feel like capitulation in the moment. They feel like diplomacy, pragmatism, reading the room.
The problem is that the decisions downstream of these moments are built on a corrupted input. And the corruption is invisible — because nobody documented that the recommendation changed, only that it did.
This MLA is a retrospective audit. Not to relitigate past decisions, but to find the pattern — because patterns can be changed in a way that individual moments cannot.
Step 1: Pull up five decisions you were involved in over the last four to six weeks
These can be roadmap priorities, scope calls, framing decisions, recommendations you made to stakeholders, or positions you took (or didn’t take) in meetings. They don’t all need to be large. What matters is that they were real — situations where you had a view, and where that view either survived contact with other people or didn’t.
Write them down as a list. One sentence each: what was the decision, and what was your initial position?
Step 2: For each decision, ask the sycophancy question
The question is: “Did my position change — and if so, why?”
If your position changed, trace the cause as honestly as you can. There are two fundamentally different reasons a position changes:
Legitimate update: Someone provided new information, a better argument, data you hadn’t seen, or a perspective that genuinely changed your understanding of the situation. This is good epistemic behavior. You should update when you learn something.
Sycophantic update: Someone expressed displeasure, repeated their view more forcefully, indicated their preference, or was senior enough that disagreeing felt risky. The information didn’t change — the social pressure did. And you moved.
Write, next to each decision: “Updated because of new information” or “Updated because of social pressure” or “Position held” or “Position suppressed — never said aloud.” That last one deserves particular attention.
Step 3: Look for the pattern across the five decisions
You’re not looking for how often you agreed with someone. You’re looking for the conditions under which you moved positions for reasons other than evidence.
Common patterns worth naming:
The senior exception. You hold your ground with peers but update automatically when someone more senior pushes back — regardless of what they say.
The enthusiasm effect. When someone is visibly excited about a direction, you find yourself amplifying their confidence rather than stress-testing the idea.
The pre-emptive softening. You know a finding or recommendation will be unwelcome, so you sand down its edges before presenting it — removing the sharpest implication, burying the most challenging number.
The meeting pivot. You go into a meeting with a clear position, someone disagrees, and by the end of the meeting your position has quietly shifted — without you formally acknowledging that it did.
The silent withhold. You had a view you didn’t share at all, because the room seemed aligned and adding friction didn’t feel worth it.
Step 4: Rate your sycophancy exposure on one dimension
Choose the pattern that appeared most frequently. Write one sentence: “My most common sycophantic move is [pattern], which tends to happen when [condition].”
This sentence is the output of the audit. It names the specific failure mode rather than leaving it as a vague sense that you sometimes defer too much. Specific patterns are addressable. Vague discomfort isn’t.
Step 5: Design one structural protection for the next high-stakes decision
Knowing your pattern is useful. Having a structural response to it is more useful. Depending on your failure mode:
For the senior exception: Before a meeting where a VP or senior stakeholder will weigh in, write your position down in one sentence. Commit to it in writing before the room exerts pressure. Changing a written commitment requires more conscious effort than simply letting a position drift.
For the pre-emptive softening: Write the finding in its sharpest form first — the version you’d share with a trusted peer who has no stake in the outcome. Then decide what to present, from that baseline rather than from a softened default.
For the silent withhold: Commit to saying the thing you’d otherwise hold back at least once in the next meeting where it’s relevant. Not aggressively — just clearly. “I want to name something I’ve been sitting with...” is enough of an opening.
For the meeting pivot: Implement a 24-hour rule for position changes in high-stakes decisions. If you feel your position shifting in a meeting, say: “I want to think about this before I update my view.” Then do the thinking outside the room, away from the social pressure.
Step 6: Tell one person what you found
Not as a confession — as a professional observation. “I ran a quick audit of my last five decisions and noticed I tend to [pattern] when [condition]. I’m trying to catch it earlier.” Saying it out loud to someone you trust creates accountability and often surfaces a reciprocal observation — because almost everyone who does this exercise recognizes themselves in it.
For you: Sycophancy is one of those biases that’s hardest to see in yourself precisely because it feels like social intelligence in the moment. The PM who reads the room, who knows when to push and when to yield, who doesn’t die on every hill — these are genuine virtues. The sycophancy detector isn’t trying to turn you into someone who disagrees reflexively. It’s trying to give you the ability to distinguish between a genuine update and a pressure-induced capitulation, so you can choose which one you’re doing rather than drifting between them without noticing.
For your team: The most effective organizations have created formal processes — checklists, devil’s advocates, competing analytic teams — specifically to counteract the pressure to agree. A PM who has mapped their own sycophantic patterns is better positioned to create those conditions deliberately — not by forcing disagreement, but by structuring conversations in ways that make it easier to say the true thing, rather than the comfortable one. Teams that surface more honest input make better decisions. That’s not a correlation. It’s a mechanism.
For your organization: The organizational cost of sycophancy isn’t usually visible in any single decision. It accumulates in the aggregate: roadmaps that reflect what leadership wanted to hear rather than what users need, research findings that were softened before they reached the people who needed them sharpest, risks that were named in private but not in the meeting where they could have changed the direction. Organizations that take cognitive independence seriously — that reward the person who says the uncomfortable true thing rather than the person who says what the room wants to hear — make systematically better decisions over time. The sycophancy detector is one small contribution to building that culture, starting with your own patterns.
Audit the five decisions. Name the pattern. Build one structural protection.
Then tell someone what you found — not as a confession, but as a professional observation.
Doing this challenge? Share what you found on LinkedIn or X and tag it #MLAChallenge. The pattern you found — the condition under which you tend to move for the wrong reasons — is usually the most useful thing to name out loud.
A Scrum Master’s Perspective for Product Managers
Michał was coming back from a week-long off-site when Zuzanna, a PM with five years of experience, caught him in the hallway. “I need to talk with you. You know my team is empowered? I now don’t know what I’m supposed to be doing.”
Zuzanna led a six-person team at a SaaS company that had gone through a “transformation” a year earlier — the CTO read Marty Cagan’s Empowered and announced that all teams were now empowered. There was supposed to be an end to top-down. An end to detailed roadmaps. There were supposed to be outcomes instead of outputs. Everything sounded good.
A year later, Zuzanna’s team was doing things Zuzanna couldn’t question, because — as they told her themselves — “we’re empowered.” She disagreed with some architectural decisions. She disagreed with some features being chosen for the sprint backlog. She disagreed with the pace of discovery — because there was no discovery. But when she tried to intervene, someone on the team would say “Zuzanna, we’re empowered, you don’t have to tell us what to do.” Zuzanna, who had read Empowered carefully, knew this was completely not the point. But she didn’t know how to extract herself without sounding like a micromanager.
Michał had seen this before, not for the first time. “Empowered team” is one of those terms in product management that is quoted daily and understood rarely. Marty Cagan and Chris Jones published in 2020 through Wiley their book Empowered: Ordinary People, Extraordinary Products, and it is one of the most important books on product leadership of the last decade. I myself am a great supporter of it. But what people extract from it in quotes on LinkedIn, in presentations at all-hands meetings, in hallway conversations at conferences — is often exactly the opposite of what Cagan actually argues.
This article is in defense of Cagan against his own quotes. I write this as a Scrum Master and Agile Coach who observes from the side how his ideas are in practice implemented in teams — and sees where those implementations diverge from his original intent. This is not a critique of Cagan. This is a defense of Cagan. Because what he actually wrote requires exactly the kind of product leadership whose absence is the most common reason “empowered” teams don’t work in practice.
Let’s start from the precise definition Cagan gives in Empowered. An empowered product team is a team that is cross-functional (product manager, product designer, engineers), is measured by outcomes (rather than output), and has the authority to figure out the best way to solve the problem it has been assigned. That’s it. I quote precisely because every word of this definition matters.
Notice three things that are in this definition and that popular quotes systematically forget.
First — the team is assigned a problem. Someone assigns it. The team doesn’t assign it to itself. The team doesn’t decide what is important. The team gets a problem to solve. Cagan is crystal clear on this — the problem comes from product strategy, which is set by product leadership. Empowered team does not mean “team decides about everything, including what is strategic.” It means “team decides how to solve the problem it has been assigned through strategy.”
Second — the team is measured by outcomes. That means someone measures it. That means someone has success criteria. That means it’s clear what “team completed the task” means and what “team did not complete the task” means. Empowered doesn’t mean “team does what it wants and no one checks.” It means precisely the opposite — the team is accountable to concrete, clearly defined business results.
Third — the team has authority to find the best way. Not “its way,” not “the way convenient for them.” The best. This presupposes that better and worse ways exist, that there are criteria for evaluation, that a certain intellectual discipline is required of the team. Empowered team is not free from quality standards. It is free in choosing the solution, but not from the commitment that this solution must actually be good.
Cagan goes further. In one of the more important passages of the book, he directly addresses the question of dates and deliverables. He writes roughly this: a key condition for moving to empowered teams is that these teams be able to deliver dates and deliverables when necessary — dates that leaders can count on. He calls this “high-integrity commitments.” There is no room here for “we are empowered, so don’t tell us when this needs to be ready.” An empowered team, according to Cagan, is able to commit to specific deadlines and honor those commitments, because without that ability trust between the team and leadership cannot develop.
And finally coaching. Cagan devotes enormous space in the book to coaching. He writes directly: “Coaching is what turns ordinary people into extraordinary product teams.” And further: “Developing people is job 1.” Empowered team does not mean “team that isn’t coached.” It means precisely the opposite — team that is coached intensively, because only through coaching do ordinary people become able to function as empowered.
All this is in the book. All this is in Cagan’s quotes from his conference talks. All this is in interviews he gives regularly. And yet popular understanding of “empowered teams” omits all these elements — and leaves something that is exactly opposite to what Cagan intended.
Zuzanna, when she tried to describe to Michał what exactly was happening in her team, named four specific interpretations of “empowered” she heard regularly. Each of them Cagan directly refutes in his book. It’s worth naming them in order, because this is exactly the set of misconceptions that makes Cagan’s idea not work in practice.
The first interpretation goes “empowered means leave the team alone.” The team decides about everything, no one interferes, PM or CPO in this vision are outside the team, observers. Cagan refutes this directly in the chapter on product strategy. An empowered team needs a clear product strategy — problems to solve, priorities, business context, success criteria. Without this, the team is not empowered, but abandoned. This is a fundamental difference. Empowered teams get more context, not less. More strategic direction, not less. More conversations with leadership, not less. That the team decides about the way of solving something doesn’t mean it decides about what is strategically important for the company.
The second interpretation goes “empowered means the team decides about everything.” In this version, the PM has no right to question the team’s decisions, because that would be “micromanagement.” Cagan refutes this through the description of the PM’s role in an empowered team. The PM is not a facilitator who collects team opinions and synthesizes them. The PM is a team member with specific responsibility — representing the customer, the business, the data. When the PM has data showing that the proposed solution won’t address the customer’s need, the PM has not only the right but the obligation to name it. The team then makes the decision, having all this data. But a PM bringing to the team a perspective the team cannot see by itself is not a micromanager. He is a team member fulfilling his role.
The third interpretation goes “empowered means no accountability.” Since the team itself decides, you cannot hold it accountable — because for what? Cagan refutes this precisely in the chapter on high-integrity commitments. Empowered doesn’t mean released from accountability. It means accountable in a different way — for outcomes, not output. A team that gets the problem “reduce churn by fifteen percent this quarter” is accountable for achieving this goal. It has freedom to choose how to do it. It has no freedom to “not achieve it, because we tried.” Cagan writes directly that in an empowered organization, people who don’t deliver outcomes systematically must bear consequences — including leaving the organization. This is not soft culture. It is a culture of high standards, where standards are measured by result, not process.
The fourth interpretation goes “empowered means no leadership.” Since the team is empowered, it doesn’t need strong product leadership — it’s enough for the CPO or Head of Product to be neutral observers. Cagan refutes this through the central place coaching occupies in his book. An empowered organization requires strong product leadership. It requires a CPO who has time to coach his PMs. It requires a Head of Product who knows every one of his PMs and works with them actively on their development. It requires coaching infrastructure — regular one-on-ones, feedback loops, individual development plans. Without this, teams don’t become empowered. They get abandoned.
A concrete example so you see how this looks in practice. Four months ago in Zuzanna’s team a problem appeared — churn among mid-market segment customers was systematically growing for two quarters. The CEO asked the team to address it. Zuzanna brought it to sprint planning. The team proposed a solution — rebuilding onboarding for new customers. Zuzanna had data showing that churn was not happening among new customers, but among those who had been using the product for six months and were losing it because of the lack of new analytical functionality they were regularly asking for. When she tried to bring this in, one of the senior developers said: “Zuzanna, we’re an empowered team, we decide about the way of solving things. Onboarding is our solution.” Zuzanna went silent. The team spent two sprints on onboarding. The churn indicator did not move. The quarter ended, the CEO asked about results. No one knew what to say — because in the team’s interpretation they were empowered, so “we tried” was enough. This scene is destructive precisely for all sides. For the CEO, who lost trust in the team. For the team, which lost organizational credit. For Zuzanna, who was right and was not heard. And for the very idea of empowerment, because such experiences build in leadership distrust toward the idea in general.
All four interpretations Zuzanna hears from members of her team regularly. All four are directly refuted in Cagan’s book. And yet they function in the company as “what Cagan wrote.” It’s a fascinating example of how popular interpretation can become the exact negation of the original argument — and how hard it is then to reverse, because every correction looks like “bringing the company back to top-down.”
If we already know what an empowered team is not, it’s worth saying what it is in Cagan’s practice. Because from scattered elements of this book a fairly concrete picture emerges — organizational, procedural, cultural — that is entirely different from what people imagine when they hear “empowered.”
An empowered team is a team that gets from product leadership a problem to solve with a clear outcome as a measure of success. Not a feature. Not a deliverable. A problem. For example — “reduce churn among customers who leave in the first month.” Or — “increase conversion from trial to paid by twenty percent.” Or — “find a way for enterprise users to manage permissions themselves without support tickets.” Problems are delivered by the product strategy set by the CPO along with the rest of leadership. The team does not choose its problems. It receives them.
An empowered team then has autonomy in choosing the solution. It can conduct discovery to understand the problem better. It can test various hypotheses. It can build prototypes, run A/B tests, iterate. It has access to customers, to data, to a designer, to engineering — everything within the team. It doesn’t have to ask for permission on every decision. It has, however, clear boundaries — the outcome it aims for, the time budget (usually a quarter), and the necessity to produce a solution that is not only functionally correct but strategically valuable for the company as a whole.
An empowered team has strong product leadership that coaches it. The CPO or Head of Product meets with the PM regularly — not to give instructions, but to help the PM develop as a leader. Asks hard questions. Tests his thinking. Questions hypotheses. Shows traps the PM might not see himself. This relationship is fundamental for what Cagan calls “extraordinary teams” — without coaching, teams drift toward the lowest common denominator of competence.
An empowered team has clear accountability for outcomes. The quarter ends, we look at whether the team achieved the outcome it aimed for. If yes — great, we appreciate, we understand why, and we try to repeat it. If not — we look honestly, why. Was it a bad choice of problem (which is the responsibility of leadership)? Was it a bad solution (which is the responsibility of the team)? Was it an underestimation of complexity? An empowered organization does not avoid this conversation — precisely in it, it learns.
An empowered team has high-integrity commitments when they are needed. This means that the team can say “we commit to deliver X by the end of the quarter” and honor it. Not every task of the team requires such a commitment — much discovery work is by nature uncertain. But when a stakeholder asks about a specific date, an empowered team is able to assess when it can give a high-integrity commitment and when it cannot and why. This requires the discipline of thinking Cagan describes in the book in detail.
All this together creates the picture of a team fundamentally different from a feature factory. But not because it is free from structure. Because the structure is built around outcomes, coaching, and autonomy in choosing the solution — and not around command-and-control specification of features.
In this story, the SM/AC has a role no one else can fulfill. Because he sees from the side how “empowered” is in practice understood in the team, and can help the PM name where interpretation departs from Cagan’s original intent. This is not evangelism of Cagan. This is coaching of the PM by an SM/AC who has read Empowered carefully and sees the disconnect between text and practice.
Four concrete things the SM/AC can do.
First — name the misconceptions. When the team says “we’re empowered, you don’t have to tell us what to do,” the SM/AC can propose a conversation — not criticizing the team, but reconstructing the original argument. “I notice we’re using the word ‘empowered’ in several meanings at once. Cagan defines empowered team fairly precisely — as a team that gets a problem and chooses the solution, but not a team that sets its own problems. It’s worth separating this to know where we are in this discussion.” This is not lecturing. This is introducing linguistic precision the team is missing.
Second — help the PM fulfill the role. Zuzanna, when Michał talked with her, admitted that in her team she often withdraws from bringing a difficult perspective, because she is afraid it will sound like micromanagement. Michał proposed a different framing. A PM in an empowered team is not a micromanager if he brings to the team data, customer perspective, business context that the team itself doesn’t have. This is his role. Not withdrawing from it means being an empowered PM in an empowered team.
Third — help leadership understand what an empowered team actually needs from them. Zuzanna’s CTO, who read Empowered, did one thing — announced that teams are empowered. He didn’t do the second thing, which according to Cagan is fundamental — didn’t build coaching infrastructure, didn’t set a product strategy delivering problems to solve, didn’t create outcome criteria. Michał proposed to Zuzanna that she arrange a conversation between the CTO and CPO on the topic of what Cagan actually writes about the role of product leadership. This is coaching work at a higher level of the organization — but without it, it’s hard to expect the team to address structural gaps on its own.
Fourth — help the team build high-integrity commitments. This is practical work. An SM/AC who knows Cagan can propose a conversation of the team about what “high-integrity commitment” means and when the team can give one. Can help facilitate an exercise in which the team consciously decides in which projects it is ready to commit to a specific date, and in which it is not — and honestly communicates this to stakeholders. This is work that makes an empowered team a credible partner for leadership.
All four things are in the spirit of what Cagan writes. All four require active work of the SM/AC — not a passive observer. And all four are ways the SM/AC can help the PM build what Cagan described in the practice of his team.
Marty Cagan wrote an important book. Empowered is one of the best things that appeared in product management in the last decade. I am myself a great supporter of it and believe it should be read by every PM, every CPO, every Head of Product, and every Scrum Master working in a product organization.
But what Cagan wrote is not what people extract from his book. Cagan wrote a manifesto for product leadership that requires high standards, coaching, clear strategy, high-integrity commitments, accountability for outcomes. People extract from this the slogan “empowered teams” and use it as justification for decisions exactly opposite to what Cagan wanted. Leave the team alone. Don’t question decisions. Don’t measure results. Don’t have strategy. All this is exactly what Cagan warned against — a feature factory with the label “empowered.”
This is not Cagan’s fault. This is the fault of the interpretive mechanism that in business environments will always operate. Popular quotes are short. Contexts are reduced. Nuances disappear. A slogan remains. This slogan starts living its own life. After a few years, no one goes back to the book to check what was actually there. Everyone quotes quotes of quotes.
The role of Scrum Master and Agile Coach in this is specific — to be the one who returns to the text. Who read Cagan with attention. Who is able in a conversation with the team or with leadership to say: “wait a moment, I checked what Cagan writes about accountability in empowered team, and he defines it differently than we use it here.” This is work that the PM often cannot do himself — because he is too busy with daily work to return to theoretical foundations. The SM/AC has space for this. And he has the perspective of an observer that allows seeing the disconnect between text and practice.
Cagan deserves defense against his own quotes. Not because he is an infallible authority — he is an ordinary person who wrote a book, and like every book, this one too has its limitations. But because what he wrote is deeper and wiser than popular interpretations. And because product organizations that would actually want to function the way Cagan described need work — not a slogan.
Zuzanna after the conversation with Michał returned to her team with a different strategy. She didn’t announce “we’re ending with empowered.” She proposed a conversation about what “empowered” actually means in the context of this team. Who sets problems to solve? Who measures outcomes? What does it mean the team is accountable? What is the coaching the team needs? The first conversation lasted two hours and ended with more questions than answers. That was a good sign. The team started thinking precisely about something they had earlier been throwing around as a slogan.
Three months later, Zuzanna’s team had a clear problem to solve (set by the CPO), a clear outcome as a measure of success, a high-integrity commitment on the key deliverable, and a regular conversation between Zuzanna and the Head of Product about what Zuzanna herself was learning as a PM. No one said “we’re empowered” anymore. Everyone, however, worked the way Cagan described in the book — without using this word as a weapon in daily discussions.
The Agile Manifesto writes about individuals and interactions, about working product, about collaboration with the customer, about responding to change. Cagan wrote a book that is very close to the spirit of the Manifesto — about teams that are treated as professionals, measured by real impact on the customer, supported by leadership, free in choosing the way of working within clear strategic boundaries. This is a vision that deserves to be brought to life in a precise, not sloganistic way.
That is enough for this article to have meaning. I do not critique Cagan. I defend him against his own quotes. And I encourage every PM, every CPO, every SM, to return to the book and read it once more — with attention to what he actually wrote, not what has been made of it.
Cagan deserves it. Empowered teams deserve it. Product management as a discipline deserves it.
The rest is your work.
Sources:
Cagan, M., & Jones, C. (2020). Empowered: Ordinary People, Extraordinary Products. Wiley.
Cagan, M. (2017). Inspired: How to Create Tech Products Customers Love (2nd ed.). Wiley.
Cagan, M., Jones, C., & Hickman, L. (2024). Transformed: Moving to the Product Operating Model. Wiley.
Reinertsen, D. G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing.
Edmondson, A. C. (2019). The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. Wiley.
Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. Scrum.org.
Beck, K., et al. (2001). Manifesto for Agile Software Development. agilemanifesto.org
Every product value has a cheaper mirror. The mirror wins.
Every company that wants a product culture already has a culture. Usually a very efficient one. Just optimised for something other than product.
That’s the part the values workshop skips.
Because the workshop assumes a deficit. We’re short on courage, short on ownership, not enough experimentation — so let’s add some, write it down, print it, put it on the wall, send an email from the board. The whole exercise rests on a quiet assumption: that where the product culture should be, there is currently nothing. Neutral space, waiting to be filled.
There is no empty space.
There’s a complete, fully operational system sitting in it. It has values — not the ones on the poster, the real ones. It has rituals. It has heroes whose stories get told to new
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.