💜 Three Tools from Shape Up Worth Taking to Your Product, Even If You’re Not Abandoning Scrum (by Łukasz Domagała)
💜 Dear UX Designer, When to Quit (And When to Stay) (guest article by Michał Kosecki)
💪 Interesting opportunities to work in product management
🍪 Product Bites - small portions of product knowledge
🔥 MLA week#56
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 🍵☕.
Three circles. Business, technology, user. Overlap in the middle, and that’s your product.
It’s on conference tote bags. It opens every discovery course on the market. And it isn’t wrong — the trio is real, the tension between those three is where product decisions actually get made, and a team that can’t hold all three builds beautiful things nobody wants or wanted things nobody can build.
But look at the diagram. Three circles floating in white space.
Nobody draws the white space.
I teach the fourth layer. I’ve taught it for years, I say it in every training, and I watch it evaporate somewhere between the room and Monday. People take the three circles and leave the container behind, because the circles are a framework you can apply and the container is a political problem you’d have to survive.
The white space is the organization. Its maturity. Its structure. Its history. Its politics. The fact that the CTO and the CFO haven’t agreed on anything since 2019 and everyone routes around it. The fact that the last reorg took eleven months and the person who championed it left. The fact that three of your product managers report to delivery and two report to marketing and nobody will say out loud that this is why the roadmap contradicts itself.
The trio doesn’t float. It sits inside a body. And the body has opinions.
So a company decides to adopt a product operating model. There’s a kickoff. There’s a deck. There’s a slide with the three circles and a slide with the new team topology and a slide that says empowered teams with a photograph of people pointing at sticky notes.
And then nothing happens. Or worse — something happens for four months and then quietly stops happening, and nobody announces it, and eighteen months later a consultant gets hired to find out why product transformation didn’t stick.
The standard explanation is that people resisted. I’ve written about why that framing is lazy — resistance is rational, and it’s usually a correct read of an unanswered question about what happens to me now. But individual resistance isn’t the whole story, and blaming it lets the actual mechanism off the hook.
The actual mechanism is rejection. Not refusal — rejection, in the surgical sense.
You can transplant an organ into a body that is not prepared to accept it. The surgery goes fine. The organ is healthy. The recipient is grateful. And then the immune system, which is doing exactly the job it was designed to do, identifies the new tissue as foreign and begins to dismantle it. Nobody made a decision. Nobody resisted. The system simply ran its normal function on new material, and its normal function was destruction.
Organizations have an immune system. It’s called performance management.
Here is the part that most product leaders would rather not sit with.
You can declare any operating model you want. You can rename the roles, redraw the org chart, hire a Chief Product Officer, buy the training, run the workshops, put outcomes over output on the wall in a font that costs money.
None of that is the operating model.
The operating model is what gets someone promoted.
Everything else is commentary. If your deck says empowered teams and your promotion criteria says delivered the committed roadmap on time, you do not have empowered teams. You have a compliance exercise with a nice vocabulary, and everyone in the building has already decoded it, because people are extremely good at working out what actually pays.
They’re not cynical. They’re reading the system correctly. That’s a competence, not a character flaw.
So the diagnostic is simple, and it takes about twenty minutes. Don’t read the values page. Look at the last five promotions. Who got them, and for what. Then look at the last two people who left and were not replaced. Then look at what happened to the person who killed a feature after discovery said it wouldn’t work — did that show up in their review as judgment, or as failed to deliver?
That’s your operating model. Written in the only language that doesn’t lie.
Which means the change you actually need is not a product change.
It’s hiring. What you screen for, who screens, and what a good answer sounds like to the person doing the screening. It’s onboarding and training — what a new PM learns in week one about how decisions really get made here, which is transmitted by watching, not by reading the handbook. It’s the competency framework, which in most companies is a document in the HR system that was last edited by someone who is no longer at the company and still describes the job as gathering requirements. It’s the promotion criteria. It’s the performance review template. It’s the comp bands, and what the bonus is tied to, and whether anyone has looked at that since the model changed.
It’s which behaviors get celebrated in the all-hands and which ones get a private conversation.
That is the systemic change. Not a methodology install. A rewiring of every mechanism by which the organization tells people who to become.
And here’s the trap in it: almost none of those levers belong to product.
The competency framework lives in HR. The promotion decision happens in a calibration meeting. The comp structure belongs to finance. The job description was copied off a competitor’s careers page by a recruiter under pressure to fill the role in three weeks. The person who decides what gets celebrated is usually the CEO, and their instincts were formed at a company with a completely different operating model, which is why they keep asking when the thing will ship.
Product transformation is, structurally, a people-systems programme wearing a product name badge. And it is routinely handed to a product leader who has authority over none of the systems that would make it work, and who is then evaluated on whether it worked.
I don’t think most CPOs have ever sat in the calibration meeting where the actual operating model gets written. I don’t think most of them know who owns the competency framework in the HRIS. I’ve asked. The answer is usually a pause.
Somebody will now say: fine, but we hire A players. Strong people find a way.
I built a competency map for product roles. Nine categories, sixteen roles, dispositions and skills and practices. I run masterminds. I run end-to-end recruitment. I know precisely what a strong product person looks like, because I assess them for a living.
Which is how I know the map has a ceiling, and the ceiling isn’t in the map.
A competency map tells you what a person is capable of. It cannot tell you what the organization will permit them to do. Those are different questions, and only one of them is answered by hiring better.
Deming spent a career saying some version of the same sentence, and the reason it never stops being relevant is that it never stops being unwelcome: the system produces the results. Not the people standing inside it. You can swap out every person on a team and the output distribution will barely move, because the output was never a property of the people — it was a property of the structure they were operating in, the information they were allowed to see, the decisions they were permitted to make, and the consequences attached to making them.
Put your best product manager into an organization where the promotion goes to whoever shipped the most, and watch what happens. She will do discovery for a quarter. She will find that two of the four things on the roadmap shouldn’t be built. She will say so, carefully, with evidence, in the right forum. And she will be told that’s very interesting and the dates haven’t moved.
She will do this two or three more times. Then one of two things happens. She adapts — starts running discovery that produces the conclusion the roadmap already assumed, because that version doesn’t cost her anything and still looks like the job. Or she leaves, and you conclude the hire didn’t work out, and you go back to the market for a stronger one.
Neither outcome contains a single incompetent person. Every individual behaved rationally. The system did exactly what it was built to do.
This is why “we just need better PMs” is such a durable idea, by the way. It’s the only diagnosis that doesn’t require anyone senior to change anything.
None of this is hypothetical. We already ran the experiment.
Agile was a company-level change. Decision rights moving closer to the work. Funding models that don’t require a twelve-month commitment to a guess. Managers whose job stops being allocation and starts being removal of obstacles. Read the manifesto — almost none of it is about a team. Nearly all of it is about who is allowed to decide what, and how fast the organization can change its mind.
And it was handed to teams.
So teams did what teams could do with the authority they had, which was the ceremonies. Standups. Retros. Story points. A board with columns. All of it real, all of it sincere, all of it operating inside a company that still funded annually, still promoted for delivery, still expected a date in November for something that would be discovered in March.
Look at what survived. The standup survived, stripped down into a status report to a manager who doesn’t attend. The retro survived, and everybody knows the action items die, because the things that actually need fixing sit three levels above anyone in the room. The certification industry survived magnificently. What didn’t survive was the only part that mattered — the transfer of authority.
That’s not a failure of Agile. That’s an organ transplanted into a body that kept its immune system running at full strength, and the immune system did what it was designed to do. The tissue that looked harmless was allowed to stay. The tissue that threatened the existing distribution of power was dismantled, quietly, over about eighteen months, by nobody in particular.
Now watch what’s happening to the product operating model.
The certifications are already here. The maturity assessments are already here. There is already a scaled framework with a logo, and there will be more. Empowered teams is becoming a ceremony — you can be an empowered team in a company where the roadmap arrives fully formed from the CEO, because empowered has been quietly redefined to mean allowed to choose the implementation.
Your product operating model is company-level change, not product-department change. If you’re blind to that, it will fail, and we will have another Agile on our hands. Same arc, new vocabulary, and a generation of product people who learn the word outcomes the way the last generation learned velocity — as something you say in a meeting that changes nothing.
--- If organizational readiness is a precondition, does anything ever move? Is this just an elaborate permission slip — we can’t do product properly, the org isn’t ready — handed to every stalled team in the industry?
It would be, if readiness were a single gate you either pass or don’t. It isn’t. There is no maturity score you hit before you’re allowed to start.
But there is a sequence, and most transformations get it backwards. They start with the visible layer — new titles, new rituals, new team shapes — because that’s the layer you can change in a quarter and show a board. The invisible layer, the one that decides whether any of it survives, gets scheduled for later. Later never comes, because by then the visible layer has already failed and the conclusion is that product didn’t work here.
Start with one lever instead. Not all of them. One, and preferably one that touches promotion, because promotion is where the organization’s real beliefs are stored.
Rewrite what a senior product manager is evaluated on, and make one of the criteria something that can only be satisfied by evidence — a decision changed by what they learned, a thing killed for a reason they can articulate. Then defend it in calibration. Not send it to calibration. Go, sit in the room, and defend it, which will require getting invited to a meeting you were probably never invited to, which is itself the transformation, because the moment product has a voice in who gets promoted, product has an operating model.
One promotion that visibly rewards judgment over delivery teaches the organization more than any amount of training. People will study that promotion the way they study nothing else, because it’s the only signal they trust.
That’s where agency lives. Not in readiness. In the boring, unglamorous, deeply political work of getting your hands on one mechanism that shapes who people become here.
So the diagram needs a fourth thing, and it isn’t a circle.
It’s the container. And unlike the three circles, you don’t get to balance it against the others — you don’t trade off a bit of business viability for a bit of organizational maturity. The container isn’t a competing consideration. It’s the condition under which the other three mean anything at all.
You can hire the best product people in the market. You can teach them discovery until they can run it in their sleep. You can give them the frameworks, the map, the language, the community — every input I know how to build, delivered properly.
And then you can put them inside a system that promotes for delivery, evaluates for compliance, hires for pliability, and rewards whoever looks busiest in front of the CEO — and you will get exactly what that system was built to produce, at a higher salary.
We’ve done this before. We called it Agile, we kept the standups, and we threw away the point.
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 :)
HOT OFFER
Product Manager / Project Manager — Affiliate Experience Required
We’re hiring for a client — an established ad tech company (performance marketing space, product with global user base).
The role
Own product/project delivery for an affiliate-focused platform
Work with engineering, support, and commercial teams — you’re the connector who ships
Translate advertiser and affiliate problems into a roadmap that moves metrics
Hard requirements
Hands-on affiliate marketing experience — you’ve run campaigns, worked at a network, or built for affiliates. You know CPA, tracking, attribution, and traffic sources from the inside, not from a Wikipedia read
3+ years in a PM or project management role in tech
Data fluency — you pull your own numbers
Fluent English
Nice to have
Ad tech / martech product background
Polish
Remote-friendly, Poland-based company. Details, brand, and comp disclosed at first conversation.
DM us or send your CV + two sentences: the best call you made in affiliate and how you knew it was right.
Product Manager - Santander Consumer Bank S.A.
Product Manager - Get Response
Product Manager - Allegro
Senior Product Manager - ERGO
Senior Product Manager - Ten Square Games
Ask someone if they understand how a zipper works. Almost everyone says yes. It is a familiar object, encountered daily, mechanically simple in appearance. The confidence is immediate and unqualified.
Now ask them to explain it. Not to demonstrate it — to explain, in step-by-step mechanical detail, how the interlocking teeth engage, what the slider actually does to them, why the mechanism holds under tension and releases in one direction only.
Almost nobody can. And in the moment of trying, something happens that is more interesting than the failure itself: their confidence collapses. They revise their self-assessment downward, immediately and substantially. They knew less than they thought — and they did not know that they knew less until the attempt to explain revealed it.
Leonid Rozenblit and Frank Keil at Yale documented this in a 2002 paper in Cognitive Science. They called it the illusion of explanatory depth. For product teams, it is one of the most consequential and least examined biases operating in user research, stakeholder alignment, and internal decision-making.
A PM runs a discovery session with five power users of an internal analytics tool. Each user is asked to describe their current workflow: how they generate reports, which data sources they combine, what they do when numbers don’t reconcile. All five give confident, coherent accounts. The PM synthesizes them into a workflow map and designs a new feature to streamline the process described.
The feature ships. Adoption is near zero.
In follow-up research, the PM sits with two of the original users and observes them working. The actual workflows bear little resemblance to what was described. There are undocumented workarounds, a spreadsheet nobody mentioned, a Slack message to a colleague at a critical step, and a manual reconciliation process that one user described as “automatic” because she had done it so many times she had stopped noticing it.
The users were not lying. They believed their accounts. They had an illusion of explanatory depth about their own work — and the PM built a product for the workflow they described rather than the one they performed.
The illusion of explanatory depth is the systematic tendency to overestimate how well we understand complex causal systems — to believe our mental models are more detailed, more coherent, and more mechanistically complete than they actually are.
Rozenblit and Keil demonstrated the effect across twelve studies. Their method was consistent: ask participants to rate their understanding of how something works (a bicycle, a flush toilet, a sewing machine, a cylinder lock) on a seven-point scale. Then ask them to write a complete mechanistic explanation. Then ask them to re-rate their understanding.
The re-ratings dropped, substantially and reliably. Independent judges scoring the written explanations found that the post-explanation self-ratings were far more accurate than the pre-explanation ones. The act of attempting explanation did not reduce anyone’s knowledge — it revealed how little knowledge had been there all along.
Crucially, the researchers found the illusion is specific to explanatory knowledge — knowledge of causal mechanisms, of how things work. It does not appear, or appears much more weakly, for facts, procedures, or narratives. People are reasonably well calibrated about whether they know the capital of Burkina Faso. They are dramatically miscalibrated about whether they understand how a refrigerator produces cold.
The mechanism Rozenblit and Keil identified is that our understanding is propped up by environmental support. When the object is present and its mechanism is partially visible, we can reconstruct enough in real time to feel we understand it. We mistake the ability to recognize and describe what a system does for the ability to explain how it does it. Familiarity masquerades as mastery.
The most immediate product implication is that user self-report about process is systematically unreliable. When we ask a user “walk me through how you currently do this,” we are asking for explanatory knowledge about a causal system — their own workflow — and receiving an account that has been smoothed, simplified, and filled in by the same reconstructive mechanism that makes people confident about zippers.
This is not a failure of honesty or memory. It is the illusion operating exactly as documented. Users describe the workflow they believe they follow. The workflow they actually perform contains steps they have automated below conscious awareness, workarounds they no longer register as workarounds, and decision points they resolve by heuristics they cannot articulate.
The gap between described workflow and observed workflow is not noise. It is the specific territory where product opportunities live — the friction that has been normalized so thoroughly that users have stopped experiencing it as friction.
The illusion operates with equal force inside the organization. Executives who direct product strategy have mental models of how the product works, how users behave, and how the market operates. These models feel detailed and coherent. Asked to explain the mechanism — why does this feature drive retention, what specific user behavior produces this metric, how does this architectural constraint limit that capability — the models frequently collapse in exactly the way Rozenblit and Keil observed.
This matters because strategic directives are frequently issued on the basis of explanatory models that would not survive an explanation request. “Users want more integrations” is a conclusion that feels grounded in an understanding of user behavior. Asked to explain which users, in which contexts, solving which problem, through which mechanism, the explanatory depth may be much shallower than the confidence of the directive suggested.
Perhaps the most uncomfortable application: product teams overestimate their understanding of their own products. We know what our features do. We are far less certain about how they work in the specific sense of what causal chain connects a user action to a business outcome.
Ask a PM to explain why a particular onboarding step improves activation. The answer usually arrives quickly and confidently. Ask them to specify the mechanism — which cognitive or behavioral change the step produces, why that change increases the probability of the next action, what would have to be true for the mechanism to fail — and the confident answer often becomes a much more tentative one.
The most useful property of the illusion, from a practical standpoint, is that it collapses under a specific and cheap intervention: the request for explanation. Rozenblit and Keil’s participants recalibrated immediately and accurately once they attempted to explain. The illusion is not stubborn. It is simply invisible until tested.
Fernbach and colleagues extended this in 2013, showing that asking people to explain the mechanism behind a policy position — rather than simply justify it — reduced the extremity of their position and increased their acknowledged uncertainty. The explanation request is a general-purpose calibration tool.
Intercom’s approach to user research reflects an organizational awareness of the self-report problem. The company has publicly described its preference for observational research and behavioral data over interview-based process description, particularly for workflow questions. Their research practice emphasizes watching users work in their actual environment rather than asking them to describe their work in a session — a methodological choice that directly addresses the gap between described and performed workflow. Intercom’s product decisions around inbox management and conversation routing emerged substantially from observed behavior that users had not reported when asked directly.
Amazon’s six-page narrative memo requirement functions as an institutionalized explanation request. The format demands that the author explain — in full prose, without bullet points that permit elision — the mechanism by which a proposed initiative produces the claimed outcome. Bullet points allow explanatory gaps to pass unnoticed; prose exposes them. Jeff Bezos has described the writing requirement in terms consistent with the illusion of explanatory depth: the process of writing forces the author to discover what they do not actually understand, before the organization commits resources on the basis of an incomplete model.
Stripe’s approach to internal documentation requires that engineers and PMs writing technical design documents explain not only what a system does but the causal chain by which it produces the intended behavior, including failure modes. The requirement operates as a systematic explanation request applied to the team’s understanding of its own systems. The documentation’s primary value is frequently not the artifact but the calibration that producing it forces — the discovery, during writing, of the mechanisms the team believed it understood and did not.
The illusion of explanatory depth matters because it corrupts the inputs to product decisions at every level simultaneously. User research produces descriptions of workflows that do not match behavior. Stakeholder directives rest on causal models that would not survive examination. Team confidence about why the product works reflects familiarity rather than mechanistic understanding.
The compounding effect is a product organization that is making decisions with high confidence and low calibration — precisely the combination most likely to produce expensive errors that nobody sees coming. The confidence is not a warning sign, because the illusion produces exactly the same subjective feeling as genuine understanding.
There is also an implication for how teams handle disagreement. When two people hold different explanatory models and neither has tested theirs against an explanation request, the disagreement is between two illusions of varying depth. The resolution mechanism most organizations use — argument, authority, or compromise — does not test either model. Requiring both parties to explain their mechanism frequently resolves the disagreement by revealing that one or both models does not hold together.
Replace “describe your process” with “show me.” In user research, any question that asks a user to explain a causal system — their workflow, their decision process, why they chose one option over another — is subject to the illusion. Observational research, session recordings, and contextual inquiry produce data about what users do. Interviews produce data about what users believe they do. Both are useful. Only the first is reliable for workflow questions.
Ask for the mechanism, not the conclusion. When a stakeholder, a team member, or a user asserts a causal claim — this feature will improve retention, users want this capability, this constraint prevents that outcome — ask them to explain the mechanism. Not to justify the conclusion, which invokes a different and less diagnostic cognitive process, but to explain how the causal chain actually works. The request is not adversarial. It is calibrating.
Write the explanation before committing the resources. The Amazon narrative memo, the technical design document, and the product brief all serve the same function when they require prose rather than bullets: they force the discovery of explanatory gaps before the organization builds on an incomplete model. Any significant initiative should require a written mechanistic explanation as a precondition of resourcing.
Test your own understanding on the product’s core loops. Pick the three most important causal chains in the product — the mechanisms by which the product creates value, retains users, and generates revenue — and write a complete explanation of each. The exercise takes an hour. It reliably reveals gaps in what the team believed it understood well.
Rozenblit and Keil’s finding was, at its core, a finding about the difference between recognition and understanding. We recognize what systems do. We are far less capable than we believe of explaining how they do it. And because recognition feels like understanding from the inside, we do not detect the gap without a deliberate test.
For product teams, this means that a great deal of what passes for insight — about users, about markets, about our own products — is actually familiarity. The workflow the user described feels like knowledge. The strategic model the executive articulated feels like understanding. The reason we believe this feature works feels like explanation.
The test is cheap. Ask for the mechanism. Write it in prose. Watch instead of asking.
The illusion collapses immediately under examination. That is the good news. The bad news is that it never collapses on its own.
Peter Thiel opened his 2014 book with a distinction that has become one of the most quoted frameworks in technology strategy — and one of the most consistently misapplied.
“Horizontal or extensive progress means copying things that work — going from 1 to n. Horizontal progress is easy to imagine because we already know what it looks like. Vertical or intensive progress means doing new things — going from 0 to 1. Vertical progress is harder to imagine because it requires doing something nobody else has ever done. If you take one typewriter and build 100, you have made horizontal progress. If you have a typewriter and build a word processor, you have made vertical progress.”
The framework is usually invoked as a value judgment: 0 to 1 is the noble path, 1 to n is the derivative one. That reading is both what Thiel intended and, for most product teams, the least useful part of the idea. The more valuable insight is operational rather than aspirational. These are not two levels of ambition. They are two fundamentally different kinds of work — requiring different teams, different metrics, different tolerance for failure, and different definitions of what progress even looks like. Most product organizations attempt both simultaneously without recognizing that they have set two different games in motion under one set of rules.
A company has a successful core product serving 40,000 customers. Growth is steady. The team knows what works: reduce onboarding friction, expand integrations, improve the reporting layer, close the feature gaps that lose deals to competitors. Each quarter, the roadmap advances the product incrementally and the numbers move accordingly.
Leadership decides the company needs a bet on the future. A new team is formed to build something genuinely new — a capability that does not exist in the market and that could define the company’s next decade.
The new team is given the same quarterly OKR cycle as the core product team. The same sprint cadence. The same expectation of measurable progress every two weeks. The same requirement to justify roadmap items against projected revenue impact. The same definition of a successful quarter.
Eighteen months later, the new initiative is quietly folded back into the core product as a feature. It did not fail because the idea was bad or the team was weak. It failed because the organization applied 1 to n operating logic to 0 to 1 work — and 0 to 1 work does not survive contact with metrics designed for scaling something that already works.
Zero to one describes the creation of something that did not previously exist: a new capability, a new category, a new mechanism for solving a problem. The defining property is that the outcome is not knowable in advance. Nobody can tell you the conversion rate of a product that has never existed, because there is no prior instance to measure.
One to n describes the extension, replication, and scaling of something that already works: adding markets, adding users, adding capacity, adding features to a validated core. The defining property is that the outcome is knowable within bounds. We can estimate the conversion rate of a new onboarding flow because we have a baseline, comparable variants, and prior instances to reason from.
Thiel’s argument was that vertical progress creates disproportionate value and that most organizations, most economies, and most careers systematically underinvest in it because horizontal progress is easier to imagine, easier to plan, and easier to justify. That argument is contestable — one-to-n execution has built enormous durable businesses, and many organizations would be better served by executing well on what they have than by chasing novelty.
But the operational distinction survives regardless of where one lands on the value question. Zero-to-one work and one-to-n work are structurally different activities, and treating them identically is a reliable way to fail at the first.
One-to-n work operates under bounded uncertainty. We do not know exactly how a new feature will perform, but we know the range. We have baselines, comparable cases, and a model of the system that can be updated incrementally. The appropriate posture is optimization: run the experiment, measure the result, iterate toward the better outcome.
Zero-to-one work operates under unbounded uncertainty. There is no baseline because there is no prior instance. The relevant question is not “how much better is this than the alternative” but “does this work at all.” The appropriate posture is not optimization but discovery — and discovery has a fundamentally different failure profile. Most attempts fail. The successful ones frequently succeed in ways nobody predicted at the outset.
This difference in uncertainty structure means that the same measurement approach cannot serve both. A quarterly OKR that requires demonstrable progress toward a numeric target is well-suited to one-to-n work and actively destructive to zero-to-one work, where the honest answer at the end of most quarters is “we learned that this approach does not work, and we now have a better hypothesis.”
In one-to-n work, progress is measured in output: features shipped, users acquired, conversion improved, markets entered. The relationship between activity and progress is relatively direct.
In zero-to-one work, progress is measured in reduced uncertainty. A team that spends six weeks and conclusively demonstrates that a promising approach does not work has made significant progress — it has eliminated a branch of the possibility space and can now allocate the next six weeks more intelligently. Under one-to-n measurement, that same six weeks reads as a total loss.
Organizations that do not distinguish these definitions systematically penalize the most valuable zero-to-one activity. Teams learn to avoid conclusive negative results and to produce partial positive signals instead. The initiative continues on a hypothesis that has not been genuinely tested, because testing it conclusively would look like failure.
The skills that make someone excellent at one-to-n work — systematic optimization, rigorous measurement, incremental improvement, operational excellence — are not the same skills that make someone excellent at zero-to-one work: comfort with ambiguity, willingness to discard sunk effort, ability to generate and discriminate between hypotheses without data, tolerance for extended periods without external validation.
These are different cognitive profiles, and while some individuals are strong at both, most are not. Staffing a zero-to-one initiative with the organization’s best one-to-n operators is one of the most common and least examined staffing errors in product organizations. The people are excellent. The match is wrong.
The two modes are not alternatives — they are sequential. Every successful one-to-n business began as a zero-to-one creation. Every successful zero-to-one creation eventually requires one-to-n execution to reach scale. The strategic question is not which mode to be in but where the organization currently is, and whether its operating system matches.
The most dangerous moment is the transition: the point at which a zero-to-one creation has been validated and must shift to one-to-n execution. Teams that carry zero-to-one operating logic into the scaling phase under-invest in the systematic optimization that scale requires. Teams that impose one-to-n logic too early kill the thing before it has found its form.
Amazon’s organizational separation of these modes is among the most deliberate in technology. AWS began as a zero-to-one initiative — a bet on a capability that did not exist as a market — and was deliberately insulated from the metrics and operating cadence that governed the retail business. Jeff Bezos has described the internal logic explicitly: businesses in the invention phase cannot be evaluated on the same terms as businesses in the scaling phase, because the invention phase produces no measurable output for extended periods. Amazon’s willingness to run AWS at a loss for years, without quarterly justification against retail-comparable metrics, was a structural precondition of its eventual success. The same company applies rigorous one-to-n discipline to its retail and logistics operations, where the work genuinely is optimization of known mechanisms.
Google’s evolution from a single zero-to-one creation into a portfolio structure illustrates the transition problem at organizational scale. The search product went from zero-to-one to one-to-n and eventually required an operating system built for optimization at enormous scale. The creation of Alphabet in 2015 was substantially a structural response to this: separating the mature one-to-n businesses from the zero-to-one bets, so that the latter could operate under different metrics, different time horizons, and different expectations of failure rates. The reorganization was an admission that a single operating system cannot govern both modes.
Stripe’s expansion sequence demonstrates disciplined one-to-n execution built on a zero-to-one foundation. The original insight — that payment integration could be made dramatically simpler for developers — was genuine vertical progress. Almost everything Stripe has built since has been rigorous horizontal execution: expanding to more countries, more payment methods, more adjacent financial products, more enterprise capabilities. This is not a criticism. It is a description of a company that identified its zero-to-one moment, validated it, and then executed one-to-n with exceptional discipline for a decade. The strategic clarity about which mode the company is in has been a substantial source of its operational coherence.
The distinction matters for product teams because most organizations attempt both modes simultaneously while operating a single system designed for one of them — almost always the one-to-n system, because it is the one that produces legible quarterly progress and because it is the mode that mature organizations are structurally optimized for.
The result is a predictable failure pattern. Innovation initiatives are launched with genuine intent and adequate resources, and then killed by an operating system that requires them to demonstrate progress in a form that zero-to-one work cannot produce. The initiative is not defunded because leadership stopped believing in it. It is defunded because it kept failing to meet metrics that were never appropriate to the work.
There is a converse failure that receives less attention. Teams that have found a working zero-to-one creation sometimes never transition to one-to-n discipline — continuing to explore, iterate, and pivot long after the right move was to execute systematically on what had already been validated. The exploration posture that produced the creation becomes the obstacle to scaling it.
Name the mode explicitly for every significant initiative. Before resourcing any initiative, state whether it is zero-to-one or one-to-n work. This is not a rhetorical exercise — it determines what metrics apply, what cadence is appropriate, what failure rate is expected, and what “a good quarter” means. Initiatives where the team cannot agree on the answer are usually one-to-n work being described in zero-to-one language for internal political reasons.
Give zero-to-one work different metrics. Zero-to-one initiatives should be measured on uncertainty reduction, not output. What did we believe at the start of the period? What do we believe now? Which hypotheses have been eliminated? What would have to be true for this to work, and how much closer are we to knowing? These are answerable questions that produce genuine accountability without requiring output that the work cannot yet produce.
Staff for the mode, not for seniority. The best operator on the core product team is frequently the wrong lead for a zero-to-one initiative, and the reverse is equally true. Match the cognitive profile to the mode. Comfort with ambiguity and willingness to discard work are zero-to-one requirements. Systematic rigor and optimization discipline are one-to-n requirements.
Manage the transition deliberately. When a zero-to-one initiative has been validated, the shift to one-to-n execution is a specific organizational event that should be named and planned. It typically requires different people, different metrics, and a different relationship to iteration. Teams that drift across this boundary without acknowledging it tend to under-execute on both sides.
Thiel’s framing was a provocation aimed at an industry he believed had become too comfortable with incremental improvement. Whether or not one accepts that critique, the operational insight beneath it is robust and independent of the value judgment.
Creating something that does not exist and scaling something that does are different activities. They have different uncertainty structures, different definitions of progress, different appropriate failure rates, and different requirements for the people doing them. An organization that runs one operating system across both will do one of them well and the other badly — and, because one-to-n logic is the default in most mature organizations, the one done badly is almost always the creation of anything new.
The typewriter and the word processor are both products. Building the hundredth typewriter and building the first word processor are not the same job.
Know which one you are doing. Then build the system that job actually needs.
In 1975, a pediatrician named John Gall published a book about why systems fail. He was not a software engineer, a management consultant, or a product strategist. He was a doctor who had spent a career watching institutional systems — hospitals, bureaucracies, public health programs — behave in ways their designers had not intended and could not have predicted.
The book was called Systemantics. Buried in it was an observation that has since become one of the most widely cited principles in software and product development, and one of the most consistently ignored:
“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”
Fifty years later, product teams still routinely attempt what Gall said cannot be done. The attempt is always well-reasoned. It usually has an impressive architecture diagram. And it fails with a regularity that should have made the principle common sense long ago.
A company decides to replace its aging internal tooling with a unified platform. The current situation is genuinely bad: four separate tools, inconsistent data models, manual reconciliation between systems, and a support burden that consumes a full engineer’s time every week. The proposed solution is comprehensive — a single platform that handles everything the four tools handle, correctly, with a coherent data model designed properly from the start.
The architecture is elegant. The specification is thorough. The team is strong. The project is scoped at nine months.
Twenty months later, the platform is not in production. Each of the four legacy tools handled edge cases that nobody documented and nobody remembered until integration testing surfaced them. The unified data model, designed to handle all four domains coherently, turned out to require compromises in each domain that made it worse than any of the specialized models it replaced. The team is now debating whether to ship a partial version or start over.
They did not lack skill, resources, or intelligence. They attempted to design a complex system from scratch. Gall’s Law describes exactly what happened next.
Gall’s Law states that complex systems which work are always found to have evolved from simpler systems that worked, and that complex systems designed from scratch reliably fail and cannot be repaired into working order.
The claim is stronger than the familiar advice to “start small.” Gall is not saying that starting simple is a prudent risk-management strategy. He is making an assertion about the nature of complex systems: that the properties which allow a complex system to function cannot be specified in advance, because they emerge from the accumulated interaction of the system with its actual operating environment.
The mechanism is straightforward once stated. A complex system has an enormous number of interactions between components, and between the system and its environment. The number of possible interaction states grows combinatorially with the number of components. No design process can enumerate them all, which means that any complex system designed from scratch contains a large number of unexamined interaction assumptions — each of which is a potential failure point that will only be discovered in operation.
A system that grows from a working simple core has a fundamentally different property: at each stage of growth, the system has been tested against its actual environment. The interactions that would have been unexamined assumptions in a from-scratch design have been validated incrementally. The complexity is real, but it has been earned rather than assumed.
Gall’s Law is closely related to Fred Brooks’s second-system effect and to Joel Spolsky’s argument against rewrites, but it makes a more general claim: this is not a warning about a specific psychological failure mode. It is an assertion about what complexity is and how it can be produced.
The central insight is that the working complexity of a mature system is not primarily the product of good design. It is the accumulated record of encounters with reality. Every conditional branch that seems arbitrary, every edge case handler that looks like cruft, every apparently redundant validation is typically the fossilized record of something that actually happened — a user behavior, an integration failure, a data state that the original design did not anticipate.
A from-scratch redesign discards this record. The new system is designed against the problem as currently understood, which is the problem as it appeared to the designers — not the problem as it has actually manifested across years of operation. The rebuild then rediscovers the same edge cases, in production, at much higher cost.
This is why teams rebuilding a mature system consistently find that the new version has mysteriously fewer capabilities than the old one, despite being architecturally superior. The old system’s messy complexity was doing work that the clean new system does not yet know how to do.
Gall’s argument rests on the claim that complex systems succeed or fail based on their fit with an environment that cannot be fully modeled in advance. Requirements documents, user research, and architectural planning all produce a model of the environment. The model is always incomplete, and the ways in which it is incomplete are not knowable from inside the model.
A simple system deployed into the real environment discovers the gaps immediately and cheaply. A complex system deployed into the real environment discovers the same gaps expensively and often catastrophically, because the failures are entangled with each other in ways that make diagnosis difficult.
The precise phrasing of Gall’s Law matters: a complex system that works evolved from a simple system that worked. Not from a simple system that existed, or from a prototype, or from a specification. From a simple system that actually worked, in production, with real users.
This constrains the growth path. Each stage of evolution must itself be a working system. The temptation to build a partial version of the eventual complex system — one that does not work yet but will once the remaining components are added — is a from-scratch design in disguise. The intermediate states are not being tested against reality. The complexity is still being assumed rather than earned.
Gall’s Law is not a prohibition on planning or a mandate for permanent minimalism. Systems with well-understood domains and rigid external specifications — a compiler for a defined language, a system implementing a published protocol, a component whose interface is fully determined by an external standard — can be designed from scratch with reasonable success, because the environment genuinely is specified in advance.
The law applies with maximum force where it is most commonly ignored: systems whose environment includes human users, organizational processes, and integration with other evolving systems. That describes essentially every product.
Amazon’s evolution from a single-database bookstore into the most complex distributed commerce system in existence is the canonical demonstration. The original architecture was a monolith that would be considered laughably inadequate for Amazon’s current requirements. It also worked, at the scale it was built for, with real customers. Each subsequent stage — the service-oriented architecture transition, the extraction of AWS from internal infrastructure, the decomposition into thousands of services — grew from a system that was functioning in production. Amazon did not design its current architecture. It arrived at it through two decades of incremental evolution from a system that worked.
Facebook’s growth path illustrates the same principle at product rather than infrastructure level. The original product was a single-university directory with profiles and connections — a system simple enough that a small team could build it and that worked completely within its narrow scope. The News Feed, the graph API, the advertising platform, and the messaging infrastructure were each added to a system that was already functioning. A team attempting in 2004 to design the 2024 Facebook from scratch would have failed, not because of insufficient talent but because the interaction complexity of the mature system was not specifiable in advance.
The UK Government Digital Service’s approach to public sector digital transformation was built explicitly around Gall’s Law logic, in a domain notorious for the opposite pattern. Large government IT projects had a documented history of comprehensive from-scratch design followed by expensive failure. GDS’s alternative was to build small working services, deploy them, learn from operation, and expand — an approach codified in the UK’s Digital Service Standard requirement to start with a minimum viable service and iterate based on real user data. The methodological shift produced a markedly different success rate than the preceding era of large specified programs.
Gall’s Law matters for product teams because the from-scratch impulse is persistently attractive and structurally reinforced. The existing system is genuinely messy. The proposed redesign is genuinely more coherent. The engineers who would build it are genuinely capable. Every input to the decision points toward the rebuild, and the principle that says it will fail is counterintuitive precisely because the reasoning that leads to it is sound at every individual step.
The organizational cost is substantial and recurring. Large rebuild projects consume disproportionate resources, run over their timelines with high reliability, and frequently ship with reduced capability relative to what they replaced. The pattern repeats across companies and decades because each team believes their situation is the exception — that their design is sufficiently thorough, their domain sufficiently understood.
There is also a strategic cost. The period during which a team is building a from-scratch replacement is a period during which the existing product is in maintenance mode. Competitors continue shipping. Users continue experiencing the current system’s problems. The rebuild’s timeline overrun is not just an internal cost — it is a competitive gap.
Find the working simple core before adding complexity. For any new system, identify the smallest version that would genuinely work for real users solving a real problem — not a prototype, not a demo, but a working system. Ship that. Everything after is growth from a validated base rather than assumption stacked on assumption.
Treat legacy complexity as documentation, not debt. Before replacing or removing an apparently unnecessary piece of an existing system, determine what it was responding to. The conditional that looks arbitrary is usually the record of a real situation. Systems that appear over-complicated are frequently correctly complicated for an environment the current team has not fully mapped.
Prefer strangler-fig migration to rewrites. When a system genuinely must be replaced, replace it incrementally — building the new system alongside the old, migrating functionality piece by piece, with both operational throughout. Each migrated component is validated against reality before the next begins. The old system continues working during the transition, eliminating the competitive gap that big-bang rebuilds create.
Be suspicious of intermediate states that do not work. If a plan’s early milestones produce components rather than working systems, the plan is a from-scratch design regardless of how incrementally it is scheduled. The test is whether each stage is deployable and useful on its own.
John Gall was a pediatrician writing about bureaucracies, and his observation applies to biological systems as readily as to software. No functioning organism was designed from scratch. Every complex living system is the accumulated result of simpler systems that worked, modified incrementally under continuous testing against an environment that could not be predicted in advance.
The reason this feels counterintuitive in product development is that we are accustomed to thinking of design as the source of order and evolution as the source of mess. Gall’s Law inverts this. In sufficiently complex domains, evolution is the only reliable source of working order, and comprehensive design is the source of systems that are beautiful on paper and non-functional in production.
This is not an argument against thinking carefully or planning ahead. It is an argument about where complexity comes from: not from specification, but from surviving contact with reality, repeatedly, at increasing scale.
Start with something that works. Let it grow. The complexity you end up with will be the complexity you actually needed — which is never the complexity you would have designed.
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
Most product teams are reasonably good at articulating what they’re building and why. Vision statements, OKRs, roadmap priorities — these are the artifacts of a team that knows what it’s going for. What they rarely articulate with equal precision is what they’re deliberately not going for. And that absence creates a specific, predictable kind of organizational friction.
Without an explicit anti-goal, every request is theoretically in scope. A feature that serves a completely different segment than the one you’re optimizing for? Hard to decline without a clear articulation of who you’re not building for. A partnership opportunity that pulls engineering in a direction that contradicts your strategic bets? Difficult to pass on when no one has written down what those bets exclude. A roadmap addition that would make the product better for power users at the expense of the experience you’re building for beginners? The debate takes longer than it should because nobody established that tradeoff in advance.
<cite index=”13-1”>Steve Jobs put it plainly: “People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done.”</cite> The insight is that what you exclude is as strategic as what you include — and that the exclusions, if they’re not written down, don’t actually exist as shared decisions. They exist as individual intuitions that diverge the moment there’s pressure to make an exception.
The research on this is pointed. <cite index=”16-1”>Companies without documented product strategies launched 41% more features but saw 23% less impact on key metrics compared to strategically-aligned counterparts.</cite> Some of that gap is strategy debt — the accumulation of tactical decisions made without strategic context. But some of it is simpler: teams that haven’t defined what they’re not building end up building more of the wrong things, because “no” requires justification and the justification requires a prior commitment that was never made explicit.
An anti-goal statement is that commitment. Written down. Shared. Stress-tested against what your team actually believes.
Step 1: Write what your product is NOT — solo, before any discussion
Block fifteen minutes and write freely. Three prompts to work through:
Who is not your user? Not “anyone who doesn’t fit our ICP” — get specific. A project management tool might be deliberately not for solo freelancers, even though solo freelancers could technically use it. A B2B analytics platform might be deliberately not for companies below a certain operational maturity, even though smaller companies might ask for it. Name the segments your product is not optimizing for, and why.
What problem are you deliberately not solving? Most products are adjacent to problems they could plausibly address but shouldn’t. A customer success platform that could expand into CRM territory but chooses not to. A developer tool that could serve non-technical users but would lose its edge in doing so. Where is your product’s boundary — and what sits just outside it?
What kind of company are you deliberately not becoming? This is the hardest one. It’s about the tradeoffs baked into your strategy. A product optimized for depth of functionality for experts is implicitly not trying to become the easiest thing to onboard. A product optimized for breadth of integrations is implicitly not trying to become the most opinionated workflow. Name the tradeoffs your current strategy commits you to.
Step 2: Write three anti-goal statements — one sentence each
Each statement follows this structure: “[Product name] is not for [specific segment / use case / direction] — [one sentence explaining the strategic reason].”
Examples of what a well-formed anti-goal looks like:
“This product is not for teams of fewer than ten people — the value we create compounds with scale and the onboarding investment doesn’t pay off below that threshold.”
“We are not building reporting features that duplicate what BI tools already do well — our edge is in workflow, not in visualization.”
“This product is not trying to serve users who need it to work without internet — our core value proposition requires real-time data that makes offline use a fundamental architectural contradiction.”
Notice what these have in common: they’re specific, they explain the reasoning, and they close a door that might otherwise be knocked on repeatedly.
Step 3: Ask three people to write their version independently
Choose a designer, an engineer, and someone from sales or customer success — people who interact with your product from different angles. Give them the same prompt: “In one or two sentences, describe who this product is NOT for and what we’re deliberately not trying to do.”
Ask them to write independently before comparing. The comparison is the exercise.
Step 4: Look for the gaps
Three patterns to look for when you put the versions side by side:
Contradiction: Someone believes the product is not for segment A. Someone else believes segment A is actually a target. This isn’t a communication failure — it’s a strategy gap that’s been producing silent misalignment in decisions neither person knew they were making differently.
Omission: Something appears in your version that nobody else mentioned. Either you’re holding a strategic commitment that hasn’t been shared, or you’re operating on an assumption that the rest of the team doesn’t hold.
Agreement: Where everyone’s versions converge without having coordinated, you have genuine strategic alignment. Those are your strongest anti-goals — the ones that can be written down and used as actual decision filters.
Step 5: Draft one canonical anti-goal statement for your product
Not three. One. The most important exclusion — the one that, if violated, would most fundamentally compromise your product’s focus or integrity.
Write it in a sentence that a new team member could read on their first week and understand immediately — both the what and the why.
Step 6: Put it somewhere your team will actually see it
The top of the product brief. The first slide of the next roadmap presentation. A pinned message in the product channel. One sentence in the team wiki that someone reads before proposing a new initiative.
An anti-goal that lives only in a document nobody opens isn’t a strategic commitment — it’s a thought you had once. Its value is proportional to how often it’s encountered when decisions are being made.
For you: Writing an anti-goal statement forces a kind of strategic clarity that goal statements alone don’t produce. Goals describe where you’re going. Anti-goals describe the terrain you’re not crossing — and knowing that terrain precisely makes every path-finding decision faster. PMs who can articulate anti-goals clearly say no more credibly, prioritize more decisively, and spend less time relitigating decisions that should have been closed by a prior commitment.
For your team: When an anti-goal is shared and understood, it changes the nature of inbound requests. Instead of every new idea requiring a fresh prioritization debate, the anti-goal functions as a first filter: does this request require us to cross a boundary we’ve already committed to not crossing? If yes, the conversation is different — and shorter. Teams with well-understood anti-goals report fewer “how did this get on the roadmap?” moments and fewer features shipped to segments they were never actually optimizing for.
For your organization: The compounding cost of not having explicit anti-goals is a roadmap that gradually expands toward everything and excels at nothing. <cite index=”12-1”>A complete and utter absence of product strategy — not bad strategy, literally no strategy — leads to many features built but little in the way of results or innovation, and eventual decline.</cite> Anti-goals are one of the cheapest forms of strategic protection available: they cost nothing to write and potentially save months of misallocated development effort. Organizations that make their exclusions as explicit as their ambitions tend to ship less and matter more.
Write the three anti-goal statements today — solo, before asking anyone else. Then compare with two or three teammates.
The gap between your version and theirs is the most useful thing this exercise produces.
Doing this challenge? Share what you found on LinkedIn or X and tag it #MLAChallenge. The thing your team disagreed on — who you’re not for, what you’re not building — is usually exactly the conversation worth having in public.
You’ve been reading the layoff headlines for two years now, and at some point they stopped meaning anything: a company, a number, a line about “efficiency.” You’ve gotten good at scrolling past them, and that’s exactly the problem. The headline that matters never gets written: the slow, unglamorous story of what’s happening at your company, on your team, to your work.
In “You’re Not Unemployed Because of AI,” we established that the market is sorting, not collapsing, and the aggregate demand for design has never really gone away. That’s the market. NN/g’s State of UX 2026 adds the piece that matters here: senior and generalist roles are recovering faster than entry-level ones. This letter is about something smaller and harder to see: your desk. Whether the place you work is investing in you or managing you out, one deprioritized project at a time. And whether you should stay and fight for it, or leave.
Reading your own company
I’ve sat in enough of these companies to recognize the pattern before the slide deck gets to the AI slide. Outward-facing, the company talks about innovation, chasing whatever technology is trending, looking high-tech to whoever is listening, investors especially. Inside, a much smaller number of people are holding legacy systems together with string, patching one collapsing piece after another, on unpaid overtime, because telling the truth (”we drifted technologically for years and now we need to fix it”) would cost someone their stock price or their seat at the table. AI just gave an old pattern a better cover story.
Every company in 2026 has learned to talk about AI. Some of them are telling the truth when they say AI changed their headcount needs. Most of them are using AI as a story that’s easier to tell than the real one, which is that the money ran out, the strategy didn’t work, or someone above you made a bet that failed and needs a headline that isn’t “we misjudged the market.”
Challenger, Gray & Christmas, the outplacement firm that tracks announced job cuts, counted AI as the top cited reason for the second month running in April 2026 - 21,490 cuts, over a quarter of that month’s total. Andy Challenger, who has watched company layoff announcements for a living, put it plainly: whether or not your actual job is being replaced by AI, he said, “the money for those roles is.” It means the AI story and the budget story are often the same thing, wearing different clothes.
Gartner analyst Kathy Ross has gone further, predicting that half the companies now blaming AI for headcount cuts will be quietly rehiring for the same work under new job titles by 2027. Orgvue, a workforce-planning software firm, found something similar already happening: nearly a third of companies that cut staff to chase AI savings have had to hire the work back. Three-quarters of the reasons behind these cuts, when you look past the press release, are economic conditions and restructuring. Not automation. (Not that this should comfort you. A company doesn’t need to be right about AI to be wrong for you.)
So don’t read the AI announcement. Read the desk. The signals that tell you something about your specific situation look like this:
• Your projects have shifted from long-horizon work to two-week tactical asks, with nobody able to tell you what comes after.
• You’ve been moved off the roadmap conversations you used to be in, and nobody explained why.
• Work that used to be yours is now split between a PM, an AI tool, and whoever’s left on the team, with no one owning the outcome.
• Design’s reporting line has moved further from the business decisions that shape what gets built.
• Your manager has stopped fighting for headcount, or budget, or your next project, and started talking mostly about “efficiency.”
I’ve watched people get written out of the planning meetings they used to run, without a word, and I’ve watched their work get split three ways before they noticed it had happened. Neither one comes with an announcement. That’s the whole design of it.
One of these, on its own, might be a bad quarter. Nielsen Norman Group’s read on 2026 is that many organizations are compressing responsibilities that used to be spread across several specialists, which is a polite way of saying: you’re being asked to do more, with less clarity about why. If that’s happening to your whole team, it might be strategy. If it’s happening only to you, that’s a different conversation, and probably one you should be having with your manager directly, not with this letter.
The math on staying and leaving
2026 is different from 2021 in one specific way. Back then, leaving was the smart financial move almost by default. You jumped, got a 20 percent raise, and barely had to negotiate. ADP’s data on the wage premium for switching jobs - what you earn by leaving versus staying put - has fallen to 1.9 percentage points, the lowest since they started tracking it in 2020. People are quitting at a rate down by about a third from the 2022 peak. Nela Richardson, ADP’s chief economist, said it best: “No one ever promised a 50-year cycle for white-collar work.” The market that made leaving easy isn’t the market you’re in now.
This doesn’t mean stay no matter what. It means the arithmetic changed, and you have to do it honestly instead of running on 2022 muscle memory. Start with the unglamorous version: what do you give up by leaving. Unvested equity, a manager who’d fight for you elsewhere, a severance package that companies are now offering less generously than they were three years ago (industry estimates put the shrinkage at 15 to 20 percent, alongside shorter health coverage bridges). None of that is a reason to stay in a company that’s managing you out, but know the number before you decide, instead of discovering it the week after you resign.
Then do the other half of the arithmetic, the part people skip because it’s less comfortable: what does staying cost you if you’re right about the decline. Every month inside a shrinking role costs you three things: skills that stop compounding, a resume that gets harder to explain, and one more month spent telling yourself the next reorg will be the one that fixes it. Stanford’s Nick Bloom has one piece of advice for this exact moment, and it isn’t complicated: line up the next thing before you leave the current one. In a low-hire, low-fire market, quitting on faith that something better will show up is a bet, not optimism, and a worse bet than it used to be.
This is why the diagnosis matters more than the instinct. A company managing its people through disinvestment doesn’t announce it. It just slowly stops asking you the questions that used to define your job (will this be good for the user, will this work) and starts asking you a smaller, safer one (does this support the roadmap we already committed to). You’ll feel it before you can prove it. The job is to prove it anyway, because “I have a bad feeling” isn’t a plan, and neither is “the market is scary, so I’ll wait it out.”
Voice before exit
There’s an old idea, older than any of this year’s data, that applies here better than most current thinking does. In 1970, the economist Albert Hirschman wrote about what happens when something you belong to starts to decline - a company, a party, a country. You have three moves: leave (exit), speak up (voice), or stay quiet and hope it fixes itself (loyalty, in its more passive form). Hirschman noticed something uncomfortable about the mechanics of it. The people most capable of noticing decline early, and most equipped to leave because they have options, tend to be the first ones out the door. That sounds like good instincts, until you realize what it does to the organization they left behind. Every time your most talented colleague quits without a word, the room gets a little worse at hearing anyone else. The people best positioned to fix things are the ones with the least incentive to stay and try.
So before you leave, use your voice. Not as a formality you perform on the way out, and not as naive faith that speaking up always works. As a real test, with a real answer, that you’re willing to believe even when it’s not the answer you wanted. Ask for the four things that matter, ideally in one direct conversation rather than scattered across six passive-aggressive Slack messages: the shape of the work (what you’ll be doing, not what the job title implies you’re doing), whether there’s a real path to grow new skills here, whether the people around you are the ones you’d choose to keep working with, and yes, the money, said out loud, not implied. If your manager can move on even one of these in a dated, concrete way, you have a data point worth weighing. If every answer gets deflected into “let’s revisit this next quarter” - the same quarter that was also going to fix things last quarter - you have a different data point, and it’s the more honest one.
I’ve had that conversation more times than I can count, on the asking end of it. I’ve asked directly for clarity on where things were heading, what the plan was, whether the roadmap I was building against still existed anywhere outside a slide. More than once, the answer was a verdict on me, not a plan: too conflictual, too many questions, not adapting well enough to the environment the company was giving me. We don’t have time for that kind of analysis, someone would say. We don’t have all the tools yet, just work with what we have. The answers dodged my question and confirmed a different one: whether asking it at all was welcome.
This is also where you run the test that separates a bad stretch from a managed decline. A bad stretch has a cause you can name: a client left, a reorg is mid-flight, a launch got delayed. It’s contained to one story, and the story has an ending. A managed decline doesn’t have one cause. It has a pattern - the same signal, showing up again in a different form, quarter after quarter, with no single explanation that accounts for all of it. One canceled project is a decision. Three canceled projects, a manager who’s stopped fighting for headcount, and a reporting line that keeps drifting further from the roadmap conversations aren’t three unrelated decisions. That’s a direction.
One designer, Twisha Shah-Brandenburg, wrote about the moment the language in her org started to shift, from asking whether the work would help anyone to asking whether it served the quarter’s targets. She noticed it the way you notice these things, which is to say months after it had already been happening. She stayed anyway, for a while, because leaving wasn’t simple for her either - a mortgage doesn’t care how honest your read on company decline is. Her advice was to “stop waiting for permission to care,” not to quit - to keep pushing the work she believed in, inside the room she was still standing in, instead of performing acceptance of a version of the job she never signed up for.
Another designer, Elizabeth Eagle-Simbeye, took a different lesson from a similar moment: her CEO announced an AI pivot after one too many thought-leadership posts on LinkedIn, and instead of arguing about it in the all-hands, she started keeping a paper trail. Every agreement. Every scoped decision. Every promise made in a meeting that has a habit of getting forgotten by everyone except the person it was made to. Whatever happened next, she wanted a record of what was said, and she wasn’t going to be the only one in the room without one. Her framing is the one worth keeping: “resilience, not resignation.”
Neither of them is wrong, and neither one is the model answer. They were answering different questions, because they were standing in different companies, at different distances from the edge. That’s the real test here, not a scorecard, not a checklist you fill in alone at midnight and mistake for a decision. Talk to your manager. Ask the four questions, plainly, and write down the answers somewhere you’ll reread them. Then watch what happens to those answers over the next month, not the next conversation, because one good meeting proves nothing and one bad one doesn’t either.
This isn’t theoretical for me. Seven people asked me some version of this exact question this year, stay or leave. Five times, I advised them to leave.
And if the pattern keeps repeating - if the work keeps shrinking, if the roadmap conversations keep happening without you, if voice keeps getting the same polite non-answer - then you already know what all of this was for. The data was never going to make the decision for you. It was only ever going to tell you when to stop pretending you hadn’t made it already.
A Scrum Master’s Perspective for Product Managers
Michał had worked as an Agile Coach in a Polish SaaS scale-up for eight years. The company had about a hundred and twenty employees, twelve product teams, an enterprise client whose contract required specific delivery dates, and a structure typical for the Polish market — a Head of Product, two Group PMs, eight PMs, each with one team. Michał knew these PMs. They went to lunch together. He talked to them every day.
That quarter, he watched Rafał, a PM with four years of experience, try for three months to deliver one feature. The rule of events was one Michał would later see many times, with other PMs. Rafał first gathered requirements from the enterprise client. He wrote user stories. He led a refinement with the team. The estimate: three sprints.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.