💜 Everyone agreed. Nobody wanted it (by Jakub Sirocki)
💜 When a Product Manager Is Afraid to Tell the CEO the Truth: On Kim Scott's Radical Candor in the Polish Context — for PMs Who See More Than They Can Say (by Łukasz Domagała)
💪 Interesting opportunities to work in product management
🍪 Product Bites - small portions of product knowledge
🔥 MLA week#58
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 🍵☕.
There are two product industries in this country and they have never met.
One of them posts. It has harnesses and agent swarms and a new acronym every eleven days. It has AI product builders who ship four apps a weekend and a carousel explaining what that means for your career. It has adoption framed as salvation — not a tool, salvation, the actual religious shape of it, get on board or get left behind, with a countdown timer under the enrollment link.
The other one is at work. It is in a sprint review defending a scope change it did not make. It is rewriting a roadmap for the third time this quarter because a stakeholder who outranks everyone in the room changed his mind on a plane. It is filling in a performance self-assessment form that asks it to quantify its impact on outcomes it was never given authority over.
These two industries use the same vocabulary. They share conferences. Occasionally the same person moves between them, usually in one direction. And they are not describing the same job.
---
Today the first industry got a correction from the top and I doubt it will notice.
Marty Cagan published a piece admitting that his own prediction didn’t happen. A year ago he wrote The Era of the Product Creator — the tools have arrived, product creation is opening up, we’re going to see a wave of strong product creators. It got the reach you’d expect. It got quoted into a thousand decks. It gave the whole builder discourse its most credible source.
His follow-up says it turned out true only a little, and nowhere near what he’d hoped. He names the error as his own: he assumed more people thought like product people.
Then he hands the explanation to Benedict Evans, who put it in the cleanest possible form. AI changes the thresholds, not the problem. Writing the code was never the hard part. The hard part is knowing that a thing should exist and knowing how it should exist, and that is a different person.
Read it twice, because it is not a small admission. The most cited authority in the field ran the experiment in public, waited a year, and reported that removing the tooling constraint did not produce the outcome. The constraint was somewhere else the whole time.
Meanwhile the masterclass page still says product builders. The correction will get a fraction of the traffic the prediction got. Nobody who sold a course off the prediction is issuing refunds, and nobody is going to.
---
That is the part worth staying angry about, and it is not really about Cagan — he did the honest thing, in public, with his name on it, which is more than the machine downstream of him will ever do.
The problem is that discourse has no error-correction mechanism, and practice is nothing but error correction.
Practice gets corrected brutally and constantly. The feature ships and nobody uses it. The stakeholder pulls the budget. The performance review lands and the number is lower than you expected and someone explains to you, in a calibrated tone, that impact wasn’t visible enough this cycle. Every one of those is feedback with consequences attached. That is the entire lived texture of the second industry: getting corrected by reality on a schedule you don’t control.
Discourse gets none of that. A prediction fails and the failure produces no cost to anyone who profited from it. The content moves on. The next framework arrives before the last one has been evaluated. There is no quarter in which the harness people find out they were wrong, because there is no mechanism by which finding out would cost them anything. The prediction was the product. It already sold.
So you end up with an industry that talks constantly and learns nothing, advising an industry that learns constantly and is not permitted to act on it.
---
Here is what actually blocks the second industry, and I want to be specific, because vagueness is how this conversation stays comfortable.
Stakeholders who outrank you. Not stakeholders who disagree with you — that’s healthy, that’s the job. Stakeholders whose disagreement ends the discussion because of where they sit, not what they know. You bring evidence. He brings seniority. Seniority wins, and you go build the thing, and eighteen months later the thing fails and the retro asks what the team could have done better.
Scope creep that isn’t creep. Nothing crept. Somebody above you renegotiated the deal and didn’t tell you, and now the shape of your quarter is different and you’re the one who has to make the sprint math work. Calling it creep is a way of locating the problem inside the team, which is precisely why the word survives.
A performance process that measures the wrong thing with great confidence. You are assessed on outcomes. You are given no authority over the levers that produce outcomes. So the process quietly stops measuring outcomes and starts measuring legibility — whether you were visibly busy in a direction leadership already liked. Everyone knows this. Everyone fills in the form anyway.
None of these are tooling problems.
Not one. Give this person Claude, Cursor, a swarm of agents, an MCP for every system in the building, and a harness with a name that sounds like a Norse god. What changes? She generates the counter-proposal faster. She still can’t get it approved. She arrives at the meeting with a better artifact and loses the same argument to the same person for the same reason. The bottleneck was never her throughput.
The bottleneck is permission.
---
And permission is the one thing the first industry cannot sell you, which is exactly why it never mentions it.
Think about what a course would have to contain. Module 4: your VP is the problem and here is how you remove him. You cannot ship that. It doesn’t scale, it doesn’t fit a cohort, it isn’t the same in any two companies, and worst of all, it isn’t flattering. The buyer has to hear that the thing standing between her and good work is structural, that it will not yield to effort, and that no amount of personal upskilling touches it.
Nobody buys that twice.
Whereas throughput is a beautiful product. Throughput is individual, so the buyer is the hero. It’s measurable, so it feels like progress. It’s teachable in a weekend. It’s infinitely repackageable — every new model release resets the content calendar for free. And when it doesn’t work, the failure is legible as a personal deficiency: you didn’t prompt well enough, you didn’t adopt fast enough, you’re not technical enough yet. The product’s failure mode is the customer’s shame. That is not an accident of the format. That is the format.
So the machine sells speed to people whose constraint is authority, and when speed doesn’t help, it sells more speed, and the gap between the two industries becomes the renewable resource. The gap is not a market inefficiency waiting to be closed. The gap is the market. Closing it would end the business.
---
In Poland the acoustics are worse, and I want to name why rather than complain about it.
We import this discourse with a lag and amplify it on arrival. It arrives stripped of the argument that produced it and rebuilt as certainty, because the person importing it is not in dialogue with the source — he is repackaging a conclusion for an audience that can’t check. The nuance doesn’t survive the trip. What lands is the confident version.
And it lands on a workforce that is disproportionately in delivery. Backlog, tickets, someone else’s roadmap, a client relationship where the discovery already happened in another country. Which means the distance between what the discourse describes and what the job contains is wider here than where it was written — and the people feeling that gap are told, in Polish, by someone with a large following, that the gap is their own adoption problem.
They start their week already behind on a race that was never the race.
---
I’m not arguing for less AI. I run my own work on it, daily, deep, and I’ll defend that anywhere. I built the methodology and I use the tools and they are extraordinary at the thing they’re extraordinary at.
I’m arguing about sequence. Tooling multiplies whatever the organization already is. Point it at a team with authority and clarity and it compounds. Point it at a team whose decisions get overwritten from above and it produces overwritten decisions faster, with better formatting, in higher volume, until the burnout arrives dressed as productivity.
The teams I watch get real leverage from AI are never the ones who adopted hardest. They’re the ones who had permission first — a leader who actually delegated a decision, a scope that stayed still long enough to work inside, a performance conversation that measured something real. Then the tools multiplied something worth multiplying.
That’s the ordering. Authority, then throughput. It has never once run the other way, and no course will ever tell you so, because permission is not a SKU.
---
Cagan ran the experiment in public and reported the result honestly: remove the tooling constraint and the wave doesn’t come. He located it in how people think.
I’d put it one layer out. It isn’t only that most people don’t think like product people. It’s that most of the people who do are working somewhere that has already decided their thinking is advisory.
The tools got cheap. The permission never did.
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 - Techbridge
Product Manager - Comarch
Product Manager - Stellantis
Product Manager - Asana
Product Lead - Decskill
In 1885, a German psychologist named Hermann Ebbinghaus published the results of an experiment he had run on himself. For months he had memorized lists of nonsense syllables — DAX, BUP, ZOL — deliberately meaningless, so that prior knowledge could not contaminate the results. Then he tested his own recall at intervals, recording precisely when memories faded and how much effort relearning required.
Two findings emerged that have survived nearly a century and a half of replication. The first is the forgetting curve: memory decays rapidly and predictably after learning. The second is more useful. When the same total amount of study time is distributed across multiple sessions rather than concentrated into one, retention improves dramatically — not marginally, but by a margin large enough that the effect has been called one of the most robust findings in all of cognitive psychology.
It is called the spacing effect. It has been replicated across vocabulary learning, motor skills, medical education, and emotional conditioning. And virtually every product onboarding flow ever shipped violates it.
A B2B product ships a new onboarding experience. It is well-designed: eight screens, each explaining a core capability, with tooltips, a short video, and a checklist the user completes before entering the product. Completion rate is 78 percent. The team celebrates.
Three weeks later, support tickets tell a different story. Users are asking how to do things that were explicitly covered in onboarding. Feature adoption for capabilities introduced on screens four through seven is near zero. In interviews, users have no memory of ever seeing those screens — despite the analytics confirming that they did.
Nothing about the onboarding was badly designed. The content was clear, the visuals were good, the flow was tested. It failed because it delivered eight units of learning in one session, and a century of memory research predicts exactly what happens to information delivered that way.
The spacing effect is the finding that information is retained substantially better when learning sessions are distributed across time rather than concentrated into a single session.
Ebbinghaus documented it in 1885. The most comprehensive modern synthesis came from Nicholas Cepeda and colleagues in a 2006 meta-analysis published in Psychological Bulletin, reviewing hundreds of studies on distributed practice in verbal recall. The finding held consistently: for the same total study time, distributed sessions outperform massed sessions on delayed retention, and the advantage grows as the retention interval lengthens.
The mechanism is not a single process. Several contribute. Each spaced retrieval triggers a new round of memory consolidation, progressively strengthening the neural trace. Spaced encounters occur in different contexts, which produces richer contextual associations and more retrieval pathways. And the effortfulness of retrieving something partially forgotten is itself a consolidation signal — the difficulty is doing work that the ease of immediate repetition does not.
The practical implication is counterintuitive. Learning that feels harder in the moment produces better retention. Learning that feels smooth and efficient — everything explained clearly, in one comprehensible sequence — produces the fluency of understanding without the durability of memory.
The most consequential property of the spacing effect for product teams is that massed learning produces a superior in-session experience and an inferior downstream outcome.
A user who moves through a well-designed eight-screen onboarding feels informed. Each screen is comprehensible. The sequence builds logically. If asked immediately afterward whether they understood, they say yes — accurately. They did understand, in the moment.
The problem is that understanding in the moment and retaining across weeks are different outcomes produced by different processes. Massed learning is optimized for the first. Only distributed learning produces the second.
This means that the standard validation approach for onboarding — usability testing, comprehension checks, completion rates — measures the wrong thing. All of these instruments assess in-session comprehension. None of them predicts three-week retention, which is what actually determines feature adoption.
Research on optimal spacing has converged on a pattern: intervals that expand over time outperform fixed intervals. The first review should come relatively soon after initial learning, the second later, the third later still.
The logic follows from the forgetting curve. Each successful retrieval flattens the curve, extending how long the memory will hold before it needs reinforcement. Reviewing too soon wastes the reinforcement on a memory that was not yet decaying. Reviewing too late means the memory is gone and the encounter is relearning rather than strengthening.
For products, this maps onto a specific design pattern: capability introduction that returns to the same concept at expanding intervals — day one, day three, day ten, day thirty — rather than a single comprehensive introduction followed by silence.
A related finding, closely connected to spacing, is that retrieval practice produces better retention than passive review. Being shown something again is weaker than being prompted to recall it.
This has direct design consequences. A tooltip that re-explains a feature is passive review. A prompt that asks the user to perform the action themselves is retrieval practice. The second is more effortful, feels less helpful in the moment, and produces substantially better long-term retention.
The design tension is real: retrieval-based reinforcement will test worse in usability sessions, because it introduces friction that passive explanation does not. The trade is friction now for capability later.
Spaced learning distributes encounters across different contexts — different times of day, different tasks in progress, different mental states. This variation is not incidental to the effect; it is part of the mechanism. Memories encoded across varied contexts have more retrieval cues attached and are accessible from more situations.
For products, this argues for contextual reinforcement over centralized instruction. A capability introduced in the moment the user needs it, across several occasions when they need it, encodes more durably than the same capability explained in a dedicated onboarding screen disconnected from any real task.
Duolingo’s entire product architecture is a spacing effect implementation. The application uses spaced repetition to determine when previously learned material resurfaces, with intervals that expand as the user demonstrates retention. Crucially, Duolingo does not attempt to teach a language in a single comprehensive session — the product is built on the premise that short, distributed sessions outperform long ones, which is why the default engagement unit is a few minutes rather than an hour. The streak mechanic, frequently discussed as an engagement device, is also a spacing device: it enforces the distributed practice pattern that the underlying learning science requires.
Slack’s approach to feature introduction distributes discovery across the user’s early lifecycle rather than front-loading it. Rather than a comprehensive tour, capabilities surface contextually over the first weeks — the first time a user is in a situation where a feature applies, when a colleague uses something they have not tried, at moments when a workflow makes a capability relevant. The pattern trades the tidiness of a complete introduction for the retention advantage of distributed, contextual encounters. It also means the product never delivers a single moment where the user has been shown everything — which is a real cost, accepted deliberately.
Figma’s onboarding demonstrates the retrieval-over-recognition principle. Rather than explaining how tools work, the initial experience prompts users to perform actions themselves in a sandbox file. The user draws the shape, moves the object, applies the constraint. This is more effortful than watching a demonstration and produces measurably better subsequent tool usage. Figma’s approach also distributes capability introduction across the user’s early sessions rather than compressing it, with more advanced capabilities surfacing after the fundamentals have been used enough to be retained.
The spacing effect matters because onboarding is one of the highest-leverage surfaces in any product, and the dominant design pattern for it is architecturally guaranteed to underperform.
The standard model — a comprehensive introduction delivered in a single session at the start of the user relationship — is massed learning. It produces good completion metrics, good in-session comprehension, and poor three-week retention. Teams then observe low feature adoption and typically respond by improving the onboarding: clearer copy, better visuals, more thorough explanation. These changes improve the in-session experience without addressing the structural problem, so adoption does not move.
There is also a resource allocation implication. Investment in making onboarding more comprehensive has diminishing and possibly negative returns — more content delivered in the same session means more forgetting, plus increased abandonment from length. Investment in distributing the same content across time has compounding returns.
The broader point extends beyond onboarding. Any product that teaches — analytics tools, developer platforms, complex B2B software, anything with a learning curve — is running an education process whether or not it thinks of itself that way. Products that ignore the spacing effect are, in effect, running that education process using a method that has been known to be inferior since 1885.
Split onboarding across sessions rather than screens. The most direct application is to take the content currently delivered in one onboarding flow and distribute it across the user’s first several sessions. Introduce the minimum required for initial value on day one. Introduce the second capability when the user returns. This will reduce day-one completion metrics and increase week-four capability usage.
Design reinforcement at expanding intervals. For each core capability, plan a reinforcement schedule: initial introduction, a return at a short interval, another at a longer one. The reinforcement need not be heavy — a contextual prompt, a suggestion at the moment of relevance, a small nudge. The interval structure matters more than the intensity.
Prefer prompting action over showing explanation. Where possible, replace demonstrations with prompts that require the user to perform the action. This is retrieval practice rather than recognition, and it produces stronger encoding. Accept that it will introduce friction and test worse in comprehension-focused usability sessions.
Measure retention, not comprehension. Change the primary onboarding metric from completion or in-session comprehension to capability usage at three and six weeks. This is the outcome onboarding exists to produce, and it is the only measure that will distinguish a well-designed massed onboarding from a distributed one.
Ebbinghaus’s central discovery was that forgetting is not random. It follows a curve, and the curve responds predictably to when reinforcement occurs. This makes memory an engineerable property rather than an accident of user attention.
Most products do not engineer it. They deliver information once, comprehensively, at the moment of least context — before the user has done anything, before they have a problem the information solves, before any of it is connected to a real task. Then they observe that users did not retain it, and conclude that the explanation was insufficiently clear.
The explanation was fine. The schedule was wrong.
There is no amount of clarity that overcomes a single massed exposure. There is no visual design that defeats the forgetting curve. The only intervention that reliably produces retention is distributing the encounters across time — which is less tidy, harder to instrument, and worse for onboarding completion metrics.
It is also the only thing that works.
Teach it once and they will forget it. Teach it four times across a month and they will have it.
There is a sequence that most product organizations believe in and almost none of them examine. First you build a great product. Then you achieve product-market fit. Then, with the product working, you test acquisition channels until you find the ones that work.
Brian Balfour, formerly VP of Growth at HubSpot and founder of Reforge, argued that this sequence is backwards in a way that has quietly destroyed a large number of otherwise viable companies. His formulation is blunt: products are built to fit with channels. Channels do not mold to products.
If that is true — and the evidence he assembled is substantial — then treating channel strategy as a phase that begins after product development is not merely inefficient. It is a category error that produces products which cannot be distributed, discovered too late to fix.
A B2B startup builds a sophisticated analytics product. It is genuinely good: deep functionality, thoughtful design, strong early customer feedback. Average contract value lands around eight thousand dollars annually. The team has been focused on product quality and has deliberately deferred growth work.
With the product working, they turn to acquisition. They try content marketing, which produces traffic but low-intent leads. They try paid acquisition, where the customer acquisition cost lands around fourteen thousand dollars — profitable only if customers stay more than two years, which they cannot yet demonstrate. They try inside sales, which works, but the sales cycle is long enough that each rep only closes a handful of deals per quarter, and the unit economics are marginal.
Every channel is either too expensive for the contract value or too slow for the burn rate. The team concludes they have a growth problem.
They have a product problem. The product was designed without reference to any channel, and it landed in a position — mid-market price point, moderate complexity, no viral mechanism, no organic content surface — where no channel works well. The fix is not a better growth strategy. It is a different product.
Product-channel fit is the framework, developed by Brian Balfour as part of his Four Fits model, holding that acquisition channels have fixed characteristics which the product must be designed around — and that the causality runs from channel to product rather than product to channel.
Balfour’s Four Fits describes four relationships that must all hold for a company to reach significant scale: market-product fit, product-channel fit, channel-model fit, and model-market fit. The four operate as a system. Changing one requires revisiting the others.
The core claim in product-channel fit is that channels are not neutral pipes through which any product can flow. Each channel has structural properties — cost per acquisition, intent level, content requirements, viral mechanics, sales cycle tolerance — and only products with matching properties can move through it economically.
Balfour supports this with an observation about distribution concentration: companies that achieve product-channel fit typically derive the large majority of their growth from a single channel. TripAdvisor, Yelp, Glassdoor, Pinterest, and Houzz all built primarily on user-generated content SEO. WhatsApp, Evernote, Dropbox, and Slack all built primarily on some form of virality. Supercell, Squarespace, and Blue Apron all built primarily on paid marketing.
The concentration is not laziness or lack of experimentation. It is the consequence of a product having properties that fit one channel’s requirements and not others’.
The asymmetry at the heart of the framework is that channel characteristics are largely immutable while product characteristics are not.
Paid acquisition has a cost floor set by auction dynamics and competition. Viral channels require the product to create a genuine reason for users to involve others in their normal usage. SEO requires an indexable content surface with search demand behind it. Inside sales requires contract values that can support the cost of a human sales motion. Enterprise sales requires organizational complexity that justifies a long cycle.
None of these constraints can be argued with. A team cannot decide that paid acquisition will be cheaper for them, or that SEO will work for a product with no content surface. The channel sets terms.
The product, by contrast, is malleable. Pricing can change. Collaboration mechanics can be added. Content surfaces can be created. The fit is achievable — but only by moving the thing that can move.
The most common failure the framework describes is temporal. Teams treat channel selection as a phase that follows product development, which means product decisions are made without reference to channel requirements for the entire period when those decisions are cheapest to change.
By the time channel testing begins, the product’s price point, complexity, and mechanics are established. Discovering at that point that no channel fits means either accepting poor unit economics or undertaking a product change that is now expensive and disruptive.
The alternative is not to build for channels before understanding the market. It is to treat channel hypotheses as a product design input from early on — to ask, while the product is still malleable, which channel this product would need to work through, and whether the product as designed can move through it.
The clearest instance of channel constraint operating on product design is the relationship between price point and viable acquisition motion.
At very low contract values, only channels with near-zero marginal cost work: virality, SEO, organic content. Any human touch in the sales process makes the economics impossible. At very high contract values, sales-led motions are viable and often necessary, since complex products require explanation. The middle is where products get stranded — expensive enough that low-cost channels struggle to convert, cheap enough that sales motions cannot be supported.
This means pricing is not solely a monetization decision. It is a channel decision, because it determines which acquisition motions are economically available. Teams that set price based on value delivered or competitive positioning without checking channel implications are making a distribution decision without knowing it.
Balfour’s framework explains a specific and common failure: a company observes a competitor’s successful growth motion and attempts to replicate it, without replicating the product properties that made the motion possible.
A team sees a competitor growing through virality and adds referral mechanics. But the competitor’s virality came from a product where collaboration was the core workflow — inviting others was how the product was used, not an added feature. Bolting a referral program onto a single-player product produces a referral program nobody uses.
The growth tactic was downstream of a product decision. Copying the tactic without the decision produces the appearance of the strategy without the mechanism.
Figma’s product architecture and its growth channel are the same decision. The product was built so that collaboration is the primary workflow rather than a feature — files are shared by default, multiple people work in the same document simultaneously, and the natural act of doing design work involves bringing others in. This produces virality not as a growth mechanic layered on top but as a direct consequence of how the product works. Figma did not achieve product-channel fit by finding the right channel for their product. The product was built such that a specific channel would work.
Squarespace built for paid acquisition and the product reflects it throughout. The value proposition is immediately comprehensible in a fifteen-second video ad, the product demonstrates visually in a way that converts on impression, the price point supports paid customer acquisition costs, and the onboarding is designed to convert self-serve traffic without human intervention. Each of these is a product property selected for compatibility with a specific channel. A product with the same functionality but a more complex value proposition would not have been able to use the channel that Squarespace built its growth on.
Glassdoor’s core product mechanic is its channel. The requirement that users contribute a review to access reviews simultaneously generates the user-generated content that powers organic search and creates the search-indexable content surface that makes the channel work. The give-to-get mechanic is often discussed as a growth tactic; it is more accurately a product design decision that made a specific channel economically viable. Without it, the same product would have had no content surface and no organic acquisition motion.
Product-channel fit matters because it relocates a category of failure from growth to product — and therefore relocates the fix to a much earlier and cheaper point in the company’s life.
Teams that discover distribution problems after building typically respond with growth experimentation: more channels, better targeting, improved conversion. This work has real value at the margin, but it cannot solve a structural mismatch. A product whose price point and mechanics fit no channel will not be rescued by better execution within channels.
The framework also explains why growth advice transfers so poorly between companies. Tactics that worked for one company were downstream of that company’s product properties. Applying them to a product with different properties produces different results, which is frequently interpreted as an execution failure rather than a fit failure.
There is a broader strategic implication. If channels shape products, then significant changes in the channel landscape create pressure on product design. Balfour has noted this explicitly in recent work: as AI changes which channels are viable — with some traditional channels declining and new ones emerging — products built for the old channel structure face a product problem, not just a marketing one. Channel shifts propagate backward into product architecture.
Treat channel hypotheses as a product design input from the beginning. Before the product’s price point, complexity, and core mechanics are settled, articulate which channel the product will need to grow through and what properties that channel requires. This is not a growth exercise conducted after the fact — it is a constraint on product design applied while design decisions are still cheap.
Check the price-channel relationship explicitly. For any pricing decision, calculate which acquisition channels remain economically viable at that price. If the answer is none, the price is wrong regardless of what the value analysis says. Pricing that strands a product between viable channels is a distribution decision made accidentally.
Audit whether the product has the mechanic its intended channel requires. If the channel hypothesis is virality, is inviting others a natural part of how the product is used, or an added feature? If SEO, does the product generate indexable content as a byproduct of normal use? If paid, can the value proposition be communicated in the format the channel supports? A channel hypothesis without a matching product mechanic is not a plan.
Before copying a growth tactic, identify the product decision beneath it. When a competitor’s growth motion looks attractive, work backward to the product property that makes it possible. Then ask whether your product has that property. If it does not, copying the tactic will produce the surface without the mechanism.
The instinct to build the product first and figure out distribution later is not irrational. Product quality matters enormously, and building something people want is genuinely prior to everything else.
But the sequence conceals an assumption: that a good product can be distributed through some channel, and finding which one is a search problem. Balfour’s framework denies this. There are products — perfectly good products, solving real problems for real users — that cannot be distributed economically through any available channel, because their properties fit none of them.
The teams that avoid this outcome do so not by being better at growth but by treating distribution as a design constraint rather than a downstream problem. They ask, early, what the channel would require, and they build a product that can move through it.
Channels do not adapt. Products do.
Design accordingly, and design early — because the properties that determine distribution are the ones that become most expensive to change.
Every networked product faces the same opening problem. The value comes from other users, and at launch there are none. The first person to arrive finds a ghost town, receives nothing, and leaves. The second person arrives to find the same thing. The network cannot start because it has not started.
Andrew Chen, who spent years at Uber before joining Andreessen Horowitz, wrote a book about this problem and the strategies that solve it. Among them is one that has produced a disproportionate share of the last decade’s most valuable software companies, and that most teams building networked products still fail to design for.
The strategy is to build a product that works for one person. Then let the network form on top of it.
Two teams launch collaboration tools in the same year. Both believe their product’s value comes from teams working together.
The first team builds for the collaborative case from day one. The onboarding asks the new user to invite colleagues before they can do anything meaningful. The core workflows assume multiple participants. The empty state says: invite your team to get started.
The second team builds a tool that a single person can use productively on their first day, alone, with no invitations. Collaboration exists and is good, but it is not required. A solo user gets real value immediately.
The first product’s activation funnel dies at the invite step. The overwhelming majority of new users will not invite colleagues before they have personally evaluated whether the product is worth their colleagues’ attention — and they cannot evaluate it, because it does not work until they invite.
The second product acquires solo users at ordinary conversion rates, and some fraction of them eventually bring their teams in. The network forms from the accumulated bottom of a funnel that was never blocked.
Single-player mode is a product design strategy in which a networked product delivers standalone value to an individual user before any network exists, allowing adoption to proceed without solving the chicken-and-egg problem first.
The concept is closely connected to what Chris Dixon named “come for the tool, stay for the network” — the strategy of attracting users with a standalone utility and converting them into network participants over time. Andrew Chen treats it as one of several approaches to the cold start problem in his book of that name, alongside the atomic network strategy of building small, complete, self-sustaining networks before scaling.
The mechanism is a decoupling. In a pure network product, individual value and network value are the same thing — you get value only when others are present. In a single-player-mode product, they are separate: there is a floor of individual value that exists regardless of network size, and network value accumulates on top of it.
This decoupling changes the acquisition math fundamentally. A pure network product must acquire users in coordinated groups or must convince individuals to act on faith. A single-player-mode product acquires individuals on ordinary terms, and network formation becomes a conversion problem among users who are already retained rather than a precondition of acquiring them at all.
The useful frame is that single-player mode establishes a value floor while the network sets the ceiling.
The floor must be high enough to justify adoption on its own. This is the demanding part: single-player mode is not a stripped-down demonstration of what the product will do once the network arrives. It must be genuinely worth using alone. A user who tries the product solo and finds it thin will not stay long enough to reach the network.
The ceiling is what makes the product defensible. Once the network forms, the value exceeds what any single-player alternative can offer, and switching costs accumulate through the network rather than through the tool.
Products that get the floor wrong — building something that only makes sense once others are present — cannot acquire. Products that get the ceiling wrong — building a standalone tool with no genuine network dimension — acquire fine and never become defensible.
Chen identifies a specific difficulty with this strategy that receives less attention than the strategy itself: converting single-player users into network participants requires them to switch mental models about what the product is for, and that switch is not automatic.
A user who adopted the product as a personal tool has formed an understanding of it as a personal tool. Some will find the network dimension irrelevant. Some will actively prefer the private, non-social version of the product they already have. The team may find itself effectively maintaining two products with different value propositions and different user populations.
This is a real cost, and it means single-player mode is not free. The strategy trades a hard acquisition problem for a moderate conversion problem — which is usually a good trade, but it is a trade rather than a solution.
The products that navigate the transition well share a structural property: network participation happens as a byproduct of doing the work rather than as a separate action.
There is a meaningful difference between a product where sharing is a menu item and a product where the natural motion of working produces sharing. In the first, network formation requires a deliberate additional act. In the second, it happens because the user was doing what they came to do.
This distinction is what separates products where single-player mode successfully seeds a network from products where it produces a large population of permanently solo users. The seed only germinates if the ordinary use of the tool creates occasions for others to be involved.
A variation Chen identifies is products whose single-player value includes publishing into a network that already exists elsewhere. Instagram’s early value proposition was photo filters plus sharing to Facebook — useful even if no other Instagram users existed, because the network being published into was Facebook’s.
This is a particularly efficient version of the strategy because it borrows an existing network’s density during the period when the product’s own network is too thin to provide value. The product builds its own network in parallel, and eventually the borrowed one becomes unnecessary.
Figma is the clearest modern demonstration. A designer can open Figma alone and do complete, professional design work with no collaborators present — the single-player floor is a fully capable design tool. The network dimension, multiplayer editing and commenting, sits on top of that floor rather than replacing it. Critically, the transition mechanism is embedded in the workflow: sharing a design for feedback is what designers do as part of their work, not an additional action. The file link is the natural artifact of the process, and receiving one is often a new user’s first exposure. The network forms because working generates sharing.
Dropbox built on the same structure. Personal file syncing across a user’s own devices was fully valuable to a single user with no sharing at all, and this was the product’s initial mass-market proposition. Sharing folders — the network dimension — came into play afterward, and the shared folder became both the collaboration mechanism and the acquisition mechanism. A user who shared a folder with a colleague was simultaneously collaborating and recruiting. The single-player floor made the product adoptable; the sharing motion made it spread.
Slack’s approach illustrates the atomic network variant operating alongside single-player considerations. Chen notes that Slack found its stable network unit was approximately three users — below that, the product did not sustain. This is a low threshold but not a single-player one, which meant Slack’s early strategy focused on team-by-team adoption within organizations rather than individual acquisition. The comparison is instructive: not every networked product can construct a genuine single-player floor, and when it cannot, the atomic network strategy of seeding small complete units is the alternative rather than a weaker version of the same thing.
Single-player mode matters because the cold start problem kills a large number of networked products, and most of those deaths are structurally avoidable through a design decision made early.
The teams that fail here are usually not naive about network effects. They understand that value comes from the network, and they design the product around that understanding — which is precisely the mistake. Designing around the end-state network produces a product that cannot reach the end state, because it does not work during the period when the network is being built.
There is also an acquisition economics argument. A product requiring coordinated group adoption has a much higher effective acquisition cost than one that accepts individuals, because every acquisition requires convincing multiple people simultaneously. Single-player mode converts a group acquisition problem into an individual acquisition problem plus an internal conversion problem, and the second is almost always cheaper.
The strategic caution is that single-player mode is a bridge rather than a destination. A product that establishes a strong individual value floor and never develops the network dimension has built a tool, which is a legitimate business but not a defensible one. The tool is copyable. The network is not. Companies that succeed with this strategy use the tool to acquire and the network to retain — and the second half is the one that determines whether the business is durable.
Define the single-player value proposition explicitly and test it alone. Articulate what one user, with no colleagues on the platform, receives on their first day. Then validate it with users who have no network — not with users who have been given a pre-populated demo environment. If the honest answer is that the product is thin without others, the floor is not built yet.
Design network formation into the workflow rather than beside it. Audit whether the ordinary act of using the product creates natural occasions for others to be involved. Sharing that requires a deliberate detour will not seed a network at scale. Sharing that is how the work gets done will.
Measure the conversion from solo to networked usage as a primary metric. This is the mechanism that makes the strategy work, and it is frequently unmeasured. Track what proportion of single-player users bring at least one other person in, how long that takes, and what precedes it. This conversion rate is the leading indicator of whether the network will ever form.
Consider whether an existing network can be borrowed. If the product can publish into, integrate with, or draw on a network that already exists, the cold start period becomes substantially easier. This is a temporary borrowing rather than a permanent dependency, but it can carry the product through the phase where its own network is too sparse to matter.
Be honest about whether single-player mode is possible. Some products genuinely have no meaningful solo use case — a marketplace, a communication network, a two-sided platform. For these, the atomic network strategy of building small complete networks is the right approach, and attempting to force a single-player floor produces a weak version of both.
The cold start problem is often framed as a growth challenge — how do we get the first users? Single-player mode reframes it as a product design question: what does this product do for someone who arrives before anyone else?
Products that have a good answer to that question can grow through ordinary means, because they are not asking users to take anything on faith. Products that do not have a good answer are asking every early user to act against their immediate interest for the benefit of a network that does not yet exist, and that request rarely succeeds at scale.
The strategy is not a trick for bootstrapping. It is a discipline that forces a networked product to be genuinely good at something before it becomes valuable through others — which turns out to be the condition under which the network is most likely to form.
Build something worth using alone. The network will come to a place worth being.
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 ancient Babylon, builders who constructed houses were held to a precise standard: if a house collapsed and killed its owner, the builder was put to death. If it killed the owner’s son, the builder’s son was put to death. The principle was brutal, but the logic was impeccable — the person who makes the decision should bear the consequences of that decision. The house would not collapse, because the builder’s life depended on it not collapsing.
Nassim Taleb spent a book — Skin in the Game, published in 2018 — arguing that this principle, stripped of its brutality, remains one of the most important and most violated ideas in modern organizational life. His central claim: when decision-makers are insulated from the consequences of their decisions, systems become fragile, incentives become distorted, and the quality of decisions deteriorates in ways that are invisible until something breaks. He called the alternative “phantom accountability” — the appearance of responsibility without genuine personal exposure to the outcome.
The application to product work is immediate and uncomfortable. Consider who typically influences a roadmap decision: a PM, a VP of Product, an engineering lead, a head of sales, a representative from customer success, maybe someone from finance. Each of them votes, advises, or pressures. But only some of them will actually experience the consequences if the decision turns out to be wrong. The PM whose roadmap fails to move the needle faces a difficult performance review. The VP whose strategic bet didn’t land may see their team restructured. But the head of sales who pushed for a feature to close a deal is already onto the next quarter. The finance stakeholder who killed a research budget to hit a cost target is measured on a different set of numbers entirely.
<cite index=”11-1”>The further removed decision-makers are from the consequences of their decisions, both geographically and organizationally, the less their skin in the game matters.</cite> This creates a specific kind of organizational fragility: decisions made with confidence by people who won’t feel the downside, executed by people who will. The asymmetry doesn’t make people malicious. It makes them systematically overconfident — because the cost of being wrong falls elsewhere.
Naming that asymmetry is the first step toward correcting for it.
Step 1: Choose one upcoming or recent roadmap decision of real consequence
This works best with something that has genuine stakes — a priority call that will commit engineering time for a quarter, a bet on a new segment, a decision to kill or significantly change an existing feature, a resource allocation choice that leaves something else underfunded. The more consequential the decision, the more important the asymmetry question becomes.
Step 2: List everyone who has — or will have — meaningful input on this decision
Not just the formal decision-maker. Everyone who shaped the direction: the PM, the engineering lead, the designer, the VP who set the strategic context, the sales leader who escalated a customer request, the data analyst whose numbers anchored the conversation, the customer success rep who flagged user sentiment. Write them down.
Step 3: For each person, ask two questions
Question one — Upside: If this decision works out well, what does this person gain? Recognition, quota attainment, a stronger roadmap story, a promotion case, a satisfied customer, a positive performance review?
Question two — Downside: If this decision turns out to be wrong — if the feature flops, the bet misses, the segment doesn’t convert — what does this person actually experience? Will they know? Will it affect their next review, their next quarter, their next project?
Write the answers next to each name. You’re looking for asymmetry: people whose upside is real and whose downside is abstract, insulated, or attributable to someone else.
Step 4: Map the asymmetries
Most roadmap conversations will surface at least one clear pattern:
The advocate without exposure. Someone pushed strongly for this direction — a sales leader wanting a feature to close a deal, a VP who wants a bet on a new market — but will not be the one who executes it or measured on whether it delivers. Their conviction is real, but it isn’t tempered by personal downside. Their input deserves weight, but perhaps not equal weight to someone who will live with the outcome.
The executor with exposure. The people who will actually build this — the engineering team, the PM, the designer — carry most of the execution risk. If the decision was poorly framed, they absorb the rework. If the direction changes, they absorb the disruption. Their caution, if it exists, is worth taking seriously.
The absent consequencer. The person most affected by the decision outcome — often the user, sometimes the customer success team, sometimes downstream teams — who had little or no voice in making it. Their absence from the decision room doesn’t reduce their exposure to the outcome.
Step 5: Ask one question in the next decision meeting — and notice the reaction
You don’t need to reframe the entire decision process. Ask one question, framed neutrally: “For the people in this room advocating for this direction — what changes for you personally if it doesn’t work out?”
This question is not an accusation. It’s a diagnostic. The answers — including the discomfort the question produces — tell you a lot about how much the group’s conviction is grounded in genuine accountability versus insulated enthusiasm.
Step 6: Write one sentence adjusting how you’ll weight the input
After the analysis, write one sentence that reflects what you now know: “In this decision, [person or group] had strong conviction but limited personal exposure to the downside, so I’m weighting their input as a signal of opportunity rather than a validation of risk.” Or: “The people most exposed to getting this wrong were most cautious — that caution deserves more weight than it got in the discussion.”
This isn’t about discounting anyone’s perspective. It’s about calibrating your own judgment with full awareness of who bears what.
For you: The habit of mapping decision accountability changes how you process input in real time. When someone argues passionately for a direction, you can now ask: does the strength of their conviction reflect genuine insight, or does it reflect the fact that they’re not the one who’ll absorb the cost if it’s wrong? That distinction doesn’t make you cynical — it makes you more accurate. PMs who develop this lens make better calls about whose caution to trust, whose enthusiasm to temper, and whose concerns to take seriously even when they’re expressed quietly.
For your team: <cite index=”14-1”>When a company systematically shields its leaders from the consequences of their decisions, it becomes fragile.</cite> The inverse is also true: teams where accountability is more symmetrically distributed — where the people making calls also experience their outcomes — tend to make better decisions over time, because the feedback loop is intact. Surfacing asymmetry in one decision doesn’t restructure accountability overnight. But it creates a conversation that, repeated, shifts how the team thinks about who should have voice at what stage of a decision.
For your organization: Most organizations don’t design accountability asymmetry on purpose. It emerges naturally from functional specialization, quarterly measurement cycles, and the distance between decision rooms and production environments. <cite index=”9-1”>When people have their own reputation or well-being on the line, they are more likely to make responsible decisions.</cite> Making asymmetry visible — even informally, even in a single meeting — is the first step toward correcting for it. Organizations that develop this awareness tend to involve the right people in decisions at the right time, weight input more accurately relative to exposure, and build a culture where advocacy comes with accountability rather than without it.
Pick the decision. Map the asymmetries. Ask the question in the next meeting.
One analysis, one question, this week.
Doing this challenge? Share what you found on LinkedIn or X and tag it #MLAChallenge. The asymmetry you found — who advocated loudest with the least to lose — is usually the most worth naming out loud.
0:00
-25:58
How many things in your product work the way they do because someone once assumed they had to, and nobody ever checked? How many design reviews have you sat through where not a single comment came up? And how many times have you heard something one on one that the same person never repeated in front of everyone? For years I took that for agreement. Until I checked.
For two, maybe three months I argued that the solution I had inherited made no sense. The conversations happened the way most product conversations happen now, in small rooms. A meeting with two people, then with two others, then notes floating somewhere in between. Every time I heard the same thing, that the approach was well thought through, that this was how it had to be, that it had full backing. Until I finally got everyone into one room, showed them my own findings from digging into the problem and a working solution from another product, and asked each person in turn to react to it. A few minutes later it turned out they agreed with me. All of them. The same people who had spent the previous weeks declaring full backing for something else. It wasn’t that they were lying. It was that none of them had ever heard what the others thought.
The work was a feature I had been handed to rebuild from scratch after the previous crew, a product manager and a product designer who were no longer at the company. What they left behind were their materials, which I had to go through end to end, and a team used to their way of working and to their reasoning about why things had to work this way. Before I challenged anything, I did my own, very thorough dig into the problem, so my objection would stand on something. There were six, maybe eight people in that room, which is exactly enough for everyone to know each other by name and for each of them to spend months convinced they were the only one with doubts. I braced for a wall and found people waiting for someone to say it out loud.
The assumption I disagreed with was technical, but it dragged scope along with it, so once we finally overturned it, we had to walk through scope again from the start. And the same thing happened there. Again, in separate conversations, I heard that scope was settled. Again, that agreement fell apart the moment we sat down together. So the false consensus didn’t turn out to be a one-off you break through once and it’s gone. It rebuilt itself around the next assumption as soon as the conversation went back into small rooms. The approach really did change and that’s how we built it in the end, but I had to do the same thing twice.
Jerry Harvey described the mechanism in 1974 and called it the Abilene paradox, after a story about a family that drove eighty five kilometres each way in forty degree heat, without air conditioning, for a bad meal nobody at the table wanted. Everyone agreed because they assumed the others wanted to go. His diagnosis was simple and inconvenient for the management fashion of the time. Organisations don’t have a problem with conflict, they have a problem with agreement. They can’t tell real agreement from the appearance of it, so they read silence as acceptance and drive on.
Organisations don’t have a problem with conflict, they have a problem with agreement. They can’t tell real agreement from the appearance of it, so they read silence as acceptance and drive on.
I came across the name late, long after both of the stories I’m telling here, so the experience came first and the label much later. Which is why I’ll say something upfront that none of the industry pieces on Abilene I read while writing this article will tell you. This is not a theory backed by research. It’s an essay published in a practitioner journal, built on a parable and a handful of described cases, with no sample, no measurement, nothing that would let you falsify it. That doesn’t invalidate the concept, it just puts it where it belongs, among sharp observations rather than verified laws.
The mechanism underneath does have solid backing, only under a different name. It’s called pluralistic ignorance, and it means we systematically misjudge what other people think, usually assuming we’re in the minority. Deborah Prentice and Dale Miller showed this in 1993 at Princeton, across four studies of how students related to the drinking culture on campus. Students consistently believed they were less at ease with it than the average peer, and the same held for their estimates about their own friends, which rules out the explanation that they simply didn’t know those people well. The norm held without real support, because everyone kept up something they didn’t believe in, so as not to fall out of the group.
The most interesting part is the study that tracked attitudes across a semester, though it’s only fair to add that it covered fifty people. Men gradually shifted their private attitudes toward the imagined norm, meaning they began to actually think what they had previously only performed. Women didn’t shift that way. A separate, fourth study showed something else: simply feeling out of step with the norm was linked to alienation on campus, even though being out of step was an illusion. So a false consensus either becomes real inside people’s heads or leaves them feeling they don’t belong, and from the outside both look like agreement. In our work that means one thing: a team that spends a year performing enthusiasm for a strategy will, after a year, start believing in it.
The popular explanation is that people are afraid to speak. That’s convenient, because it moves the problem inside the person, where nobody has to fix it. I’d put it differently: this isn’t about character, it’s about the channel. It’s easier to tell someone what you actually think over coffee or one on one than in a meeting with fifteen people. That’s not a flaw in people. It’s an ordinary property of the situation.
And here’s where it gets uncomfortable, because a large part of product conversation happens in channels where nobody sees the whole picture. One on one conversations with each person separately. Slack, where you mostly talk one to one, and if in a group, a small one. Figma comments pinned to a specific frame. Alignment built through a series of short conversations, so nobody has to call everyone in at once. This doesn’t mean nobody runs joint sessions, because workshops do happen. It means the way they’re run often changes nothing, because they’re missing the things that actually let you see where people stand, like having the person with the most power speak last. Each of those channels separately confirms the same fiction, and nobody ever sees the whole. We collect the team’s position through a keyhole, one room at a time.
Each of those channels separately confirms the same fiction, and nobody ever sees the whole. We collect the team’s position through a keyhole, one room at a time.
The heart of it isn’t in the tools anyway, it’s in what we don’t do. When we skip the methods that surface where people actually stand, the decision lands wherever the conversation happens to be, which means in a very narrow group. And a narrow group is the best incubator for false agreement there is, because the fewer people in the room, the easier it is to believe that what you’re hearing is what everyone thinks. Spreading a conversation across a few pairs is the most effective way of preserving that kind of agreement I know of, and that one we invented ourselves.
Remote work didn’t break this, because Harvey described the phenomenon when everyone still sat in one office. But it amplifies it several ways at once. Silence in an online meeting is even more ambiguous than silence at a table, because you don’t know whether the person agrees, has their camera off and is reading something else, or is simply waiting for someone ahead of them to speak. There’s no exchange of glances that sometimes shows you half the room has doubts. There’s no hallway and no lunch, the places where false consensus traditionally cracked. Remote work does give us things the office never had, like written positions collected before a meeting, which let someone quiet get heard at all. So the problem isn’t remote work. It’s that we carried the office ritual into it, the one where you ask “does everyone agree?” and read the silence as yes.
Then there’s something our industry has elevated to the status of a value. Alignment. A word that was supposed to mean everyone understands where we’re going, and in practice came to mean nobody is objecting any more. Dissent reads as blocking and as a failure to focus on delivery. The meeting has to fit into thirty minutes, so agreement is the default exit and a doubt costs everyone time. In those conditions you don’t need fear to go quiet. Politeness is enough, plus the assumption that if nobody else has concerns, I must be the one missing something.
I have to draw a line here, because without it the whole concept turns into a skeleton key. The Abilene paradox requires that people stay silent because of an imagined scenario. If someone on the team remembers a colleague saying what she thought, nobody backing her, and the conversation moving on as if nothing had been said, then silence stops being a cognitive error and becomes a rational conclusion drawn from evidence. It looks identical. It’s something entirely different.
That difference has practical consequences. Revealing preferences works on Abilene, because all you need is to show people they’re not in the minority. No round of “tell me honestly what you think” will work on fear of consequences, because everyone knows how that went last time, and at best they’ll walk away more certain that whoever asked doesn’t understand where they work. It’s also worth remembering that the evidence doesn’t have to be recent or verified. One meeting is enough, where someone took a stand and was left alone with it while everyone else stared at their screens. Nobody ever named it or talked about it. It works like a fact.
I also have my own example of agreement being revealed and it still not being enough. I came into an American company as a consultant, not as a member of staff. My job was to say what to fix in the product and what to change to get it back on track, because until then it had been in trouble. Over four months of that engagement I argued that it starts with a design system. Publicly, the team’s position was unambiguous, that it was unnecessary. In individual conversations, those same people told me that yes, it needed to be introduced. I got five people from the Polish side into a room, and there the agreement surfaced without resistance, including the argument that it would simply speed the work up. Then came the joint meeting, fifteen people, with the team from the States. They listened, there was a discussion, and then they decided my way of thinking was wrong and they didn’t want to work that way.
I don’t know what happened next, because I ended the engagement. I’m not someone who folds at the first pushback, but the conversation stopped being about the design system. My competence started getting questioned, insults were thrown, along with suggestions that with an approach like mine I wouldn’t find work. At that point there’s nothing left to defend, only the decision to walk. The false consensus broke, and still nothing came of it, because what stood on the other side was a real conflict of interest, not a misunderstanding.
Set that against the story at the start of this piece, because it was a completely different company and a completely different ending. There too I got people into one room, there too it turned out they agreed with me, and there it ended in real change. Same move, two different outcomes. The difference wasn’t in how I asked the question, it was in who sat on the other side of the table, because in the first case nobody had a stake in keeping the old assumption alive, and in the second someone did. You can ask directly at any company. Whether the answer changes anything depends on who’s sitting across the table and how much they have to lose.
You can ask directly at any company. Whether the answer changes anything depends on who’s sitting across the table and how much they have to lose.
It’s worth saying what that fight was really about, because from the outside it looked like an argument over a tool. It wasn’t about the design system. It was about discovery. Screens there were produced to order, with no phase for understanding the problem, so the company had a completely warped sense of how long anything should take. I made screens based on discovery and that made me look slower. The design system was meant to be a way of buying back the time discovery took. For a designer it was a question of consistency and quality. For the business side, a question of pace. We were talking about two different things using the same word, and that’s a separate problem, one that has nothing to do with Abilene.
There’s one more thread, and it’s probably the most important, though I have no hard data behind it, only thirteen years of watching this industry up close. When tech was a gold rush, dissent cost you socially but not existentially. You could come across as difficult, as a blocker, as the one who always has objections. It couldn’t cost you your job, because a new one took a month to find. That is the perfect environment for the Abilene paradox. People stayed quiet out of politeness and out of a belief that if things are going this well for everyone, they must be the only one with doubts. False consensus is cheap during a boom, so nobody tested it.
Today it’s different, and that’s the shift I don’t see in any piece written about this paradox. With layoffs, frozen hiring and teams that plenty of companies cut every quarter, dissent stopped being a question of image. People saw who went and in what order. So silence stopped being a misreading of the group and became a calculation based on observation. In other words, the downturn didn’t deepen the Abilene paradox. It’s pushing it out and replacing it with something far harder to do anything about. That distinction matters in practice. If your team is quiet because it’s misreading its own preferences, a well framed question is enough. If it’s quiet because it did the maths on the risk, no question will help until you change what happens to the people who do speak.
Both of the stories I’ve told here share an uncomfortable part. In the first one I walked into the middle of someone else’s story. I was handed a feature to fix, and with it a full account of what had happened before: that there was a blow up, that a manager was let go, that a designer left because he couldn’t get through to anyone, that customers ultimately didn’t want to use it. Nothing but consequences and a list of the guilty. Nobody could tell me who had actually wanted it built. In the second one I’m the one who left before the end and doesn’t know what happened after, so whoever came in after me got exactly what I got walking into that first company: a story without a cause.
Harvey described why this happens, and it’s the part of his essay that industry summaries skip most often. What follows a bad decision isn’t reflection, it’s frustration and mutual blame, usually aimed at the leader or at the neighbouring subgroup. Nobody says “I misread what everyone else thought”, because that would mean admitting to their own silence, and silence is embarrassing exactly when it turns out everyone was thinking the same thing. So the cause disappears and what’s left is a story about a weak leader and bad data. And that’s why the same thing happens again, only with a better deck.
Which brings me to what bothers me most about this concept. When a failure gets explained by nobody having spoken up, the whole weight of it lands on the team that stayed quiet. Not on the people who set the meetings up so there was never a moment to speak, and not on the people who left behind a memory of what happens to those who do. That’s a very convenient diagnosis for whoever created those conditions.
I don’t have a twenty step procedure here, I have one thing that worked for me and a few small ones around it. If you’re hearing full backing only in one on one conversations or in pairs, get those same people into one room. Not to catch them out. So that they hear each other for the first time. Put something concrete on the table, your own findings or a solution that already works somewhere, instead of throwing out a general question, because a general question gets one person talking and everyone else tuning to them. Then call on each person in turn. Silence after “does everyone agree?” isn’t an answer, it’s the absence of one, and we treat it as agreement because that’s faster.
You do have to be careful not to overdo this. If there are forty people from different departments in the meeting, going round one by one won’t surface where people stand, it will produce forty different expectations, each of which sounds sensible on its own. What comes out of that isn’t a solution to a problem, it’s a creature stitched together from other people’s wishes. Call on the people the decision actually affects, and inform the rest instead of asking them.
First aid courses teach you not to shout into a crowd but to point at one person and tell them to call an ambulance. A call to everyone reaches nobody. The mechanism there is different from ours, because it’s about diffused responsibility rather than misreading what other people prefer, but the counter is identical. You address a specific person, by name, and you ask them what they think.
A few small things sit around this, and they cost five minutes. The person with the most power in the room speaks last, because their view sets everyone else’s and after it no round has any value left. Collect positions on the specific question in writing before the discussion, one sentence from each person, before anyone has heard what the boss thinks. For high stakes decisions an anonymous vote works, just remember it shows you the spread of opinion, not the reasons behind it, so it’s a good opening for a conversation, not a replacement for one. And if there’s real fear of consequences in the team, anonymity won’t fix anything, it will only show you the size of the problem. These are methods I use in product workshops, and every one of them can be introduced on your own, without anyone’s help. If you’d rather someone from the outside ran it, because from the outside it’s easier to ask the uncomfortable question, get in touch, I run those workshops and mentoring.
If you’re a designer, take a look at your critique. A session where nobody has comments isn’t proof the work is good, it’s an absence of information. Silence in a critique doesn’t tell you the design is right, only that nobody wants to go first. Ask for specifics rather than opinions, and ask each person separately instead of throwing “what do you think?” at a screen with fifteen frames on it. Pay attention as well to the patterns in your design system that nobody likes but everyone uses, because they assume somebody once designed them deliberately. Sometimes nobody designed them. They just went in and stayed.
A session where nobody has comments isn’t proof the work is good, it’s an absence of information. Silence in a critique doesn’t tell you the design is right, only that nobody wants to go first.
If you’re a product manager, look at how you build alignment. If you build it through a series of two person conversations and only then announce the outcome, you’re producing exactly the configuration in which a false consensus survives for months. Announce the outcome after the joint conversation, not before it. And ask yourself the question we usually don’t: when did someone on this team last say something genuinely uncomfortable, and what happened to them afterwards. If people answer with something specific, you don’t have a communication problem. You have a power problem, and that’s an entirely different conversation.
Because the worst product decisions don’t get made in an argument. They get made in a silence everyone agreed to call agreement. And it’s always easier to count the people who stayed quiet than the people that silence suited.
A Scrum Master’s Perspective for Product Managers
Michał was returning to the office Friday after lunch when he saw Rafał sitting at his table with an open laptop. Rafał, a PM with four years of experience, whom Michał had earlier supported in Shape Up experiments, was staring at a draft email to the CEO. Three weeks earlier, sales had closed a contract with an enterprise client on one condition — a product modification the CEO had personally promised at a meeting Rafał hadn’t attended. The feature was supposed to be ready by the end of Q2. Rafał, after a week of analysis, knew this was impossible. It would take six months, maybe eight if done properly. It probably required an architectural change no one had yet discussed. The client had received a promise the product couldn’t deliver.
Michał sat down next to him. He saw three deleted email versions. The first began with “I’d like to discuss with you certain challenges related to feature X.” The second — “I’ve noticed a few things worth thinking through.” The third was blank. Rafał had been staring at the screen for forty minutes. It needed to be ready for the board meeting on Monday. He had no message ready.
Michał asked what was going on. Rafał told him. Michał had seen this hundreds of times — in Rafał, in other PMs, in colleagues, in himself. A PM who knows
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.