💜 You Build on Quick Fixes. Someone Else Pays (by Jakub Sirocki)
💜 The Shower Doesn’t Answer (by Alex Dziewulska)
💪 Interesting opportunities to work in product management
🍪 Product Bites - small portions of product knowledge
🔥 MLA week#57
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 🍵☕.
The burnout advice for product managers in 2026 goes like this: block focus time. Cut meetings. Use AI for repetitive tasks. Protect your calendar.
Calendar hygiene. For an identity wound.
It’s like handing someone a spreadsheet template while their house is on fire. Technically useful. Wildly beside the point. And the reason the advice misses is that it’s built on a model of burnout that stopped describing reality somewhere around February 2025 — the month a single tweet renamed how software gets built and quietly renamed what gets expected of you.
Let me take this apart properly. Because there’s a new burnout mechanism running in product organizations right now, it has almost nothing to do with workload, and nobody prescribing meeting-free Wednesdays has noticed.
Classic burnout theory is a supply-and-demand story. Demands exceed resources, sustained over time, and the human starts to fail in a predictable three-part sequence that Christina Maslach mapped decades ago: exhaustion first, then cynicism — that creeping detachment where you stop caring as self-defense — then the third one, the quiet one, the sense that nothing you do amounts to anything. Inefficacy. Professional accomplishment draining out of work that used to feel like accomplishment.
The whole model assumes one thing so basic nobody thought to state it: the job is stable. The demands might be brutal, the resources might be laughable, but the job itself — what it is, what counts as doing it well, whether it exists next year — that part holds still. You burn out from doing the job.
That assumption is dead. Product people in 2026 are burning out from something the classic model doesn’t have a slot for. Two somethings, actually, running in parallel. One reprices your output — silently, by default, unless somebody stops it. The other puts your identity under permanent review.
I wrote a while back about the three buckets — minimum, optimum, premium. The 80% you deliver sick and exhausted. The 100% of a normal day. The 300% when everything clicks: rare, unsustainable, never the expectation. The system works because the buckets are honest about human variability.
AI builders didn’t break the bucket system. They did something sneakier. They put a question on every organization’s table that most organizations never noticed was a question: when the tools collapse the cost of producing, where do the gains go?
Because they have to go somewhere. There are exactly two ledgers. The gains come back to the human as slack — recovered time, recovered rest, recovered capacity to think. Or they get absorbed into expectations — the bar quietly relocates to wherever the tools just put your ceiling. Someone always decides which ledger. The trap is that in most organizations, nobody decides out loud — and silence routes everything to the expectations ledger by default. What used to be your premium bucket — working prototype over a weekend, full research synthesis solo, the deck produced overnight — slides down the shelf. Premium becomes optimum. In some organizations, premium becomes minimum. “You have AI now” does the same job “you have a laptop” did for weekend emails twenty-five years ago: converting a capability into an obligation without anyone signing anything.
The productivity gains are real — I use these tools twelve hours a day, I’m not going to stand here pretending the acceleration is fake. The gains aren’t the problem. The routing is.
Full disclosure before I go further: I didn’t let this happen to my buckets. The hours AI gives back, I keep. I use them to serve my clients better, sure — but also to go on a walk with my dogs, to read, to be idle, because my brain needs to be idle to be great. I’m telling you this as evidence, not a flex: the gains can come back as slack. The repricing isn’t physics. It’s a decision — and if nobody in your organization remembers making it, that’s worse, not better.
The psychology of why the expectations ledger burns is older than the tools. Effort-reward imbalance — Johannes Siegrist built a whole occupational health model on it — says burnout tracks the gap between what you put in and what comes back, and “what comes back” was never just salary. It’s recognition. Acknowledgment. The felt sense that the output registered. When premium output becomes the expectation, the reward for premium output drops to zero by definition. You can’t be recognized for clearing a bar that moved to wherever you already are. The organization hedonically adapts to your ceiling the way you adapt to a pay raise: instantly, completely, and with no memory of before.
Which lands you directly in Maslach’s third dimension, the quiet one. Inefficacy. Producing more than at any point in your career and feeling less accomplished — because accomplishment is measured against the bar, and the bar is on a treadmill powered by your own output. In that regime, every time you’re impressive, you raise the price of impressive. The better you are, the faster the machine eats it — until someone names the machine.
That’s the first mechanism. It’s nasty, but it’s at least a recognizable cousin of classic burnout — effort in, insufficient reward out, deficit accumulates.
The second mechanism is the new one. And it’s worse.
Here is the ambient condition of working in product in 2026. An industry report predicts product managers will disappear by 2030 — an actual date, like a prophecy business filed its forecast. The same report celebrates a 10x increase in “Product Builders” in a single year. The trend pieces tell you your learning speed is your moat. The tooling reshuffles monthly. And the takes cycle annually — same argument, fresh dates — because the discourse was never an inquiry that could conclude. It’s an anxiety ritual with a publishing schedule.
So the job now includes a second, invisible shift: metabolizing a rolling forecast of your own obsolescence while sprinting to outrun it. Extinction on the left. Moat-building course on the right. Buy now.
Occupational psychology has studied what this does to a human, and the findings should be printed on the discourse like a surgeon general’s warning.
The research field is called job insecurity, and its central finding is one of the most counterintuitive results in occupational health: anticipating the loss of your job damages you on the same scale as actually losing it. Sometimes more. De Witte found in the late nineties that workers who felt insecure scored the same on mental health measures as people who were actually short-term unemployed. The anticipation matched the event. A later meta-analysis across twenty cohort studies made it sharper: the odds ratio for developing depressive symptoms was 1.19 for unemployment — and 1.29 for perceived job insecurity.
Read that again. The people still employed but waiting for the axe were at higher risk than the people the axe had already hit.
The mechanism is two-headed: unpredictability and uncontrollability. Not knowing what’s coming, and having no lever to affect it. Actual job loss, brutal as it is, resolves both — you know, and you can act. Grieve, retrain, move. Anticipated loss resolves neither. The threat just sits there, undated and unanswerable, and your nervous system does the only thing nervous systems know how to do with an unresolved threat: it monitors. Continuously. It runs the audit.
Now look at what the AI-PM discourse is, structurally. It is a machine for maximizing exactly those two variables. Unpredictability: nobody can tell you which capability release moves the bar next, which is why the takes never conclude, only recycle. Uncontrollability: the forecast is about the role, not about you — no amount of individual excellence lets you veto an industry-level prophecy. The discourse doesn’t merely describe insecurity. It manufactures the precise psychological conditions under which insecurity does maximum damage, and it delivers a fresh dose every time you open a feed.
This is identity-threat burnout. It doesn’t run on hours. You can have a light sprint, a clean calendar, a protected Wednesday, and still be cooking — because the threat assessment doesn’t bill by the hour. It runs in the background, always, the way any vigilance system runs: every tool launch a threat scan, every “the role is dead” post a court date, every impressive stranger on the feed a data point in the case against your future. Conservation of resources theory says the threat of losing something you value drains you the way actual loss does — and what’s under threat here isn’t a task list. It’s the answer to “what are you?” at a dinner party.
That’s why the exhaustion feels so disproportionate to the work. It isn’t disproportionate. You’re just counting the wrong shift.
Now the standard advice makes sense as a category error. Focus blocks, meeting audits, AI-for-repetitive-tasks — every item on the list treats burnout as a capacity problem. Demands here, resources there, rebalance. Fine for the old machine.
But identity-threat burnout isn’t a capacity problem. It’s a threat problem. You cannot calendar-block an extinction forecast. You cannot delegate your relevance audit to an agent. The advice bounces off because it’s aimed at the visible shift and the damage is being done on the invisible one.
Worse: some of the advice actively feeds the machine. “Keep up or fall behind” — the learning-speed-as-moat framing — takes an unresolvable industry-level threat and privatizes it into a personal to-do. Now the prophecy isn’t just ambient. It’s your fault if it comes true. That’s not advice. That’s the audit with a productivity skin.
And here’s the part I want product leaders to sit with: watch what the cynicism stage looks like in this new machine. Maslach’s second dimension — detachment — was always the psyche’s circuit breaker, distance deployed as anesthesia. The PMs on your team who’ve gone quiet, who’ve stopped fighting for their point of view, who ship and shrug — read them again. That’s not laziness and it’s not lost talent. That’s a nervous system conserving resources under a threat it can’t resolve, exactly as the theory predicts. They’re not checked out. They’re bracing.
I don’t do listicles, but I’ll tell you where the levers actually are, because they’re not where the advice points.
Renegotiate the contract. Out loud. If the repricing got you, it got you silently — that’s the only way it works. So reverse it the only way silent renegotiations reverse: make the routing question explicit. Where do the gains go? Redefine the buckets with the tools in the room — what does minimum, optimum, premium look like now, including the parts the throughput metrics don’t see: the review time, the judgment calls, the being-wrong-faster. And name what share of the recovered hours stays yours. Write it down. Take it to your manager. Not because managers are villains — most absorbed the repricing as unconsciously as their teams did — but because the silent version of this negotiation only ever moves in one direction.
Bound the audit. You cannot resolve the threat, but you can stop volunteering for extra doses. The discourse is a business, not a forecast — fear converts, prophecy sells courses, and the takes recycle annually because anxiety doesn’t conclude, it subscribes. You’re allowed to log out of a prophecy business. This isn’t head-in-the-sand; it’s dosage control. Follow the tools, skip the obituaries. The information content of the discourse rounds to zero anyway — same argument since early 2024, fresh dates on it.
If you lead: the routing is yours. The gains landed on one of two ledgers, and if you never made that decision consciously, silence made it for you — and silence always picks the expectations ledger. If throughput went up 10x and your bar followed it without a single explicit conversation, you didn’t witness a productivity miracle. You built a burnout machine and put a dashboard on it. The bar’s position is architecture, and architecture has an author. Be one, or be the reason your best people are bracing.
The tools got faster. The nervous systems didn’t. One of those was supposed to be 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 - Stellantis
Senior Product Manager - Zendesk
Senior Product Manager - Finom
Product Manager - Asana
Lead Product Manager - Pencil
In 1948, a psychologist named Bertram Forer gave a personality test to thirty-nine of his students. A week later, he returned to each of them a personalized profile based on their individual results, and asked them to rate its accuracy on a scale from zero to five.
The average rating was 4.26. Students described the profiles as remarkably accurate — as capturing something specific and true about who they were.
Every student had received exactly the same profile. Forer had assembled it from statements pulled out of a newsstand astrology book. The text included lines like: you have a great need for other people to like and admire you; you have a tendency to be critical of yourself; you have a great deal of unused capacity which you have not turned to your advantage.
The profiles were not personalized at all. They were general enough to describe nearly anyone, positive enough to be welcome, and framed as individually derived. That combination produced a subjective experience of precise personal recognition. Forer called it the fallacy of personal validation. It is now more commonly known as the Barnum effect — and it is running, largely undiagnosed, through a substantial portion of what modern products call personalization.
A product team ships a personalized weekly summary email. It opens with a line generated from user data: “You’ve been most active on Tuesday mornings this month — that’s when you get your best work done.”
Engagement metrics are strong. Open rates climb. Users reply to the email with genuine enthusiasm; several tweet screenshots. In user interviews, people describe the product as “knowing them” and “actually paying attention.”
Six months later, an engineer reviewing the code discovers a bug: the day-of-week calculation has been broken since launch. Every user has been receiving Tuesday. No one noticed. Users with peak activity on Thursday, Sunday, and Monday read “Tuesday morning” and experienced a moment of recognition.
The engagement was real. The insight was not. The product had accidentally run a Forer experiment on its entire user base, and passed.
The Barnum effect is the tendency to accept vague, general descriptions as uniquely and specifically applicable to oneself, particularly when those descriptions are framed as individually derived and are broadly favorable.
Forer identified it in 1949 under the name “the fallacy of personal validation.” The name Barnum came later, from psychologist Paul Meehl in the 1950s, in reference to P.T. Barnum’s showmanship and his purported observation that a good show has “a little something for everybody.”
Subsequent research has identified the specific conditions that amplify the effect. Statements rated as most accurate tend to share several properties: they are vague enough to admit multiple interpretations; they use hedging qualifiers like “at times” or “sometimes”; they are socially desirable, describing traits people want to have; and they are delivered by a source with perceived authority or access to privileged information about the recipient. The last condition matters more than most people assume — the same statement rated as generic in one framing is rated as highly accurate when presented as the output of an assessment.
For product teams, this is a direct description of the mechanism by which a substantial amount of personalization functionality actually works. Not through accuracy, but through a combination of sufficient generality, positive framing, and the strong contextual signal that says: this was computed for you.
The most consequential finding for product design is that the perceived source of a statement changes how accurate it is judged to be, independent of the statement’s content. A description labeled as the output of an algorithm, an assessment, or a data analysis is rated more accurate than an identical description labeled as generic.
This means the interface framing around a personalized feature is doing measurable work. “Based on your activity” is not neutral packaging around a computed insight — it is an active input to how accurate the insight will feel. Products that wrap generic outputs in strong personalization framing generate genuine subjective experiences of being known.
The uncomfortable implication is that this framing works whether or not the underlying computation is any good. A poorly-tuned recommendation engine presented with confident personalization framing may produce higher user satisfaction than a well-tuned engine presented neutrally. The framing is not compensating for the quality — it is substituting for the signal that would allow users to evaluate quality at all.
The Barnum effect implies a specific epistemic problem: users are poorly positioned to assess whether personalization is actually working. Their evaluation mechanism is the feeling of recognition — does this describe me? — and that mechanism is reliably triggered by sufficiently general statements.
This means user satisfaction is an unreliable proxy for personalization accuracy. Survey responses, qualitative feedback, and even engagement metrics can all be strong for personalization that is barely functioning, because users are measuring resonance rather than precision, and resonance is achievable without precision.
Teams that validate their personalization systems primarily through user satisfaction are, in effect, measuring how well their outputs conform to Barnum conditions rather than how well their models predict individual behavior.
Not all personalization sits at the same point on the generality spectrum, and the position determines whether the Barnum effect is doing the work. A statement like “you tend to be most productive in focused blocks rather than fragmented sessions” applies to nearly everyone who works in knowledge domains. A statement like “your average session length dropped 40% after you switched to the mobile app in March” applies to a specific person and could be wrong.
The first type is safe, well-received, and informationally empty. The second type carries real information and real risk. Products drift toward the first type over time, because it never generates complaints, never requires accurate models, and reliably produces positive user response.
This drift is rarely a deliberate decision. It is the accumulated result of many small choices to soften a claim, hedge a statement, or generalize an insight that occasionally landed wrong.
There is a meaningful line between using Barnum-adjacent framing to make genuine insights land, and using it to manufacture the appearance of insight that does not exist. The first is presentation. The second is a form of deception that users are structurally unable to detect.
The distinguishing test is straightforward: would this output be different for a different user? If the answer is no, and the product presents it as individually derived, the product is running Forer’s experiment rather than delivering personalization.
Spotify Wrapped is a widely-studied case of personalization that sits deliberately on the accurate side of the line while borrowing heavily from Barnum-adjacent presentation. The underlying data is genuinely individual — actual listening history, actual top artists, actual minutes played. But the framing layer, including personality-style labels and characterizations of listening behavior, uses categories broad enough that many users land in flattering, resonant descriptions. The product’s enormous social sharing performance depends on both elements: the data must be genuinely personal for users to feel it is about them, and the framing must be positive and archetypal enough for them to want to share it. Wrapped works because it combines real personalization with Barnum-effective presentation, rather than substituting the second for the first.
Personality assessment products used in enterprise settings — Myers-Briggs being the most widely deployed — have been extensively critiqued in psychological literature for Barnum dynamics. Research on MBTI’s validity has consistently found that its type descriptions are broad enough that individuals frequently rate multiple type profiles as accurate descriptions of themselves, and that test-retest reliability produces different types for a substantial proportion of people on repeat administration. The commercial success of these instruments does not depend on their predictive validity. It depends on the recognition experience the descriptions produce, which is a Barnum outcome. Product teams building assessment or profiling features should treat this as a cautionary case rather than a model.
Netflix’s approach to recommendation presentation illustrates a design choice that reduces Barnum dependence. Rather than characterizing the user — telling them what kind of viewer they are — Netflix presents recommendations with explicit provenance: “Because you watched X.” The framing points at a specific, verifiable prior action rather than at an inferred trait. This makes the recommendation falsifiable in a way that trait-based personalization is not. If the connection is bad, the user can see that it is bad. The design choice sacrifices some of the warmth that Barnum framing produces in exchange for a signal users can actually evaluate.
The Barnum effect matters for product teams because it creates a systematic gap between the perceived and actual quality of personalization systems — and the gap runs in the direction that makes it hard to detect.
Personalization is expensive. Building the data infrastructure, the models, and the pipelines to produce genuinely individual insight requires substantial investment. The Barnum effect means that a much cheaper approach — general statements with confident personalization framing — produces a comparable and sometimes better subjective user experience. Organizations that measure personalization success through user response will find that the cheap approach performs well, which creates pressure to under-invest in the expensive one.
Over time, this produces products that feel personalized and are not. This is a fragile position. It works until something breaks the illusion: a user comparing notes with a colleague, a screenshot shared publicly, a bug that reveals the same output going to everyone. When the illusion breaks, the trust cost is disproportionate to the underlying deception, because users experience it as having been fooled about something they had felt was intimate.
There is a growing relevance in AI-driven features specifically. Large language models are exceptionally good at producing text that feels individually addressed while containing little individual specificity. The Barnum effect describes precisely the failure mode that AI personalization features are most prone to — fluent, warm, plausible, and generic.
Run the substitution test on every personalized output. Take a personalized insight, statement, or recommendation and ask: if this were sent to a randomly selected different user, would they notice? If the answer is no, the output is not personalization regardless of what the pipeline does. This test can be automated across a sample of users and run as a routine quality check.
Measure personalization on falsifiability, not satisfaction. Since users cannot reliably evaluate personalization accuracy, user satisfaction is the wrong primary metric. Better measures include predictive accuracy against held-out behavior, the rate at which users act on personalized recommendations relative to non-personalized baselines, and explicit accuracy feedback on specific, falsifiable claims.
Prefer provenance framing to trait framing. “Because you did X” is verifiable by the user and creates accountability for the system. “You’re the kind of person who Y” is not verifiable and invites Barnum dynamics. Provenance framing is less warm and more honest, and it produces a feedback loop that improves the underlying system rather than obscuring it.
Watch for generality drift in copy review. Personalization copy tends to soften over time as teams hedge statements that occasionally landed wrong. Periodically audit personalization language for hedging qualifiers, universal-experience framing, and statements that could not be false. These are the signatures of a system that has drifted from personalization to Barnum.
Forer’s students were not gullible. They were doing what everyone does when handed a description framed as being about them: reading for resonance, finding it, and taking the resonance as evidence of accuracy. The mechanism is not a defect. It is how recognition works.
What Forer demonstrated is that this mechanism can be triggered without any actual knowledge of the person. And what the last decade of product development has demonstrated is that this is a commercially viable thing to do — that a product can generate genuine feelings of being understood without understanding anyone.
The choice available to product teams is whether to treat that as an opportunity or as a warning. The opportunity is real: Barnum-effective framing is cheap and it works. The warning is that it works by exploiting the gap between the feeling of being known and the fact of it, and that gap is not stable. Products built on it are borrowing trust they have not earned.
The test is one question, asked honestly: would this be different for someone else?
If not, it is not personalization. It is a horoscope with better typography.
There are two ways to protect a user from a mistake. The first is to stop them before they make it: a dialog appears, asks whether they are sure, and requires a second deliberate action. The second is to let the action happen and give them a way back: the thing occurs, and a small offer to reverse it appears alongside.
These look like variations on the same safety mechanism. They are not. They produce different user behavior, different emotional states, different levels of protection, and — critically — different degrees of willingness to use the product at all. One of them makes users more careful. The other makes them more capable.
Most products default to the first and should default to the second.
A design tool ships a feature that lets users apply a style change across an entire document. The team is aware this is a significant action, so they add a confirmation dialog: “This will change 47 elements. Are you sure you want to continue?”
Usage of the feature is low. In research sessions, the team observes why. Users hover over the button, read the dialog, and cancel. Not because they do not want the change — because the dialog has asked them to predict, in advance, whether they will like a result they cannot yet see. They cannot answer that question, so they decline.
The team removes the dialog and adds an undo affordance instead: the change applies immediately, and a small toast appears offering to revert. Usage of the feature increases substantially. The revert rate is around eight percent — meaning ninety-two percent of the time, the confirmation dialog had been asking users to pre-approve something they were going to be happy with.
The dialog was not protecting users. It was preventing them from finding out.
The undo principle holds that for reversible actions, allowing the action to occur with a clear path to reversal produces better outcomes than requiring confirmation before the action occurs.
The principle sits within a broader tradition in human-computer interaction. Jakob Nielsen’s usability heuristics include “user control and freedom” — the requirement that users have a clearly marked emergency exit from unwanted states, with support for undo and redo — as one of ten foundational principles. Reversible actions have been identified in the HCI literature as enabling exploratory learning, reducing serious errors, and lowering the cognitive cost of using unfamiliar systems.
The mechanism is a difference in what each pattern asks of the user. A confirmation dialog asks the user to evaluate an outcome they have not yet seen, using only their mental model of what the action will do. That mental model is frequently incomplete — which is precisely why the action feels risky. Undo asks the user to evaluate an outcome they can see. The evaluation is dramatically easier and dramatically more accurate.
Gmail’s Undo Send, introduced in 2009, remains the canonical consumer example. Its predecessor pattern would have been a confirmation dialog on every send, which no one wanted and which would have made email unusable. Instead, the action completes and a brief window opens in which it can be recalled. The feature became a standard expectation across email clients because it addressed the actual problem — regret discovered after the fact — rather than the theoretical problem of insufficient deliberation before it.
The most well-documented failure of confirmation dialogs is habituation. A dialog that appears frequently is dismissed automatically, without being read, within a small number of exposures. This is not user carelessness. It is a rational adaptation: if ninety-nine out of a hundred dialogs are unnecessary interruptions, the efficient strategy is to dismiss them all quickly.
The consequence is that the one dialog that genuinely mattered gets clicked through on autopilot. Confirmation dialogs applied broadly do not protect users from serious errors — they actively degrade the protection available for serious errors by training the dismissal reflex that will eventually be applied to the one that counted.
Undo does not suffer from this dynamic. An undo affordance that is not needed is simply ignored and disappears. It costs nothing when unnecessary, so it does not train anything.
The two patterns produce different emotional states. A confirmation dialog focuses attention on risk. It says: this could go wrong, and you are responsible for whether it does. Users leave the interaction with elevated caution.
An undo affordance says: this is fine, and if it is not, here is the way back. Users leave the interaction with a sense of safety net.
The behavioral consequence is that products with strong undo support see more exploration. Users try things. They apply the bulk operation, use the unfamiliar feature, test the setting they were unsure about. Products with heavy confirmation get less of this — users avoid the paths that generate friction, which means they avoid the features behind them.
For products where capability discovery is a driver of retention and expansion, this difference is strategically significant. The features users never try cannot create value.
The principle is not that confirmation should never be used. It is that the friction should be proportional to the actual irreversibility and blast radius of the action.
There is a useful ladder here. No confirmation, for actions that are trivially reversible and low-impact. Undo toast, for actions that are reversible but not obviously so, or where the user might not notice the change immediately. Soft delete, for removals that should feel final but be recoverable — trash rather than deletion. Simple confirmation, for actions that are genuinely hard to reverse. Explicit-consequence confirmation, for actions where the user needs to understand what specifically will be lost. Type-to-confirm, for the small set of actions that are truly irreversible and catastrophic.
The failure mode most products exhibit is compression: applying the same middle-of-the-ladder confirmation to everything from deleting a draft to deleting a workspace. When all destructive actions carry identical friction, users cannot distinguish the recoverable from the catastrophic, and they calibrate to the average — which means under-worrying about the fatal ones.
Undo is frequently harder to build than confirmation. A dialog requires no state management; undo requires the system to retain enough information to reverse the operation, sometimes across sessions, sometimes across collaborative edits by multiple users.
This asymmetry means the choice between the patterns is often made by engineering cost rather than by user outcome. The dialog ships because it is a day of work and undo is a week. This is a legitimate constraint, but it should be recognized as a trade-off with user consequences rather than treated as a neutral implementation detail. Reversibility is a product property, and deciding not to build it is a product decision.
Figma’s approach to reversibility is architecturally deep rather than surface-level. Version history, branching, and multi-user undo are built into the core data model rather than added as features on top of it. This is what allows Figma to have almost no confirmation dialogs in ordinary editing flows — users can move, delete, restructure, and experiment freely because the system can always return them to a prior state. The design consequence is a tool in which exploration is the default posture. Designers try things in Figma that they would have hesitated over in tools where the cost of a bad experiment was higher. The reversibility architecture is not a safety feature; it is the enabling condition for the product’s core creative behavior.
Google’s product suite applies the undo pattern with unusual consistency across Gmail, Drive, and Photos. Deletion moves items to a recoverable state and surfaces an immediate undo toast; permanent removal requires a separate, deliberate action from a different context. The pattern is applied uniformly enough that users develop an accurate mental model: in Google products, deletion is recoverable. That model reduces hesitation across the entire suite, including in products the user has not used before, because the expectation transfers.
Notion’s handling of block deletion and page removal illustrates the soft-delete rung of the ladder. Deleted pages move to trash rather than disappearing, remain recoverable for a defined period, and require an explicit permanent-delete action to remove entirely. This preserves the psychological finality that users want from deletion — the page is gone from their workspace — while retaining the underlying reversibility. The design separates the perceptual outcome from the technical one, which is frequently the right resolution when users want something to feel permanent without actually being irreversible.
The undo principle matters because the default instinct in product teams runs the other way. When a feature carries risk, the natural response is to add a gate. The gate is cheap, it visibly demonstrates that the team took the risk seriously, and it transfers responsibility to the user, who confirmed.
That last property is why confirmation dialogs proliferate in mature products: they are as much an organizational artifact as a design one. The dialog is documentation that the user was warned. It protects the team more reliably than it protects the user.
The cost is paid in capability. Every gate is a place where some users stop. The features behind heavy confirmation get used less, discovered less, and generate less value than their quality would predict. In products where breadth of feature adoption drives retention and expansion revenue, this is a measurable commercial cost that does not appear in any dashboard, because the users who did not try the feature generate no signal.
There is also a compounding trust effect. Products that consistently make actions reversible teach users that the product is safe to explore. That lesson generalizes across the whole product and persists across sessions. Products that gate heavily teach the opposite lesson, and it generalizes just as thoroughly.
Audit every confirmation dialog against actual reversibility. For each confirmation in the product, determine whether the underlying action is genuinely irreversible. Most are not. Dialogs guarding reversible actions should be replaced with undo affordances, which will increase feature usage and reduce dismissal habituation simultaneously.
Match friction to blast radius using an explicit ladder. Define, at a product level, which rung each destructive action sits on: no confirmation, undo, soft delete, simple confirmation, explicit-consequence confirmation, type-to-confirm. Document the criteria. This prevents the compression problem where everything gets the same middle-tier dialog regardless of consequence.
Measure the revert rate on undo affordances. When an action moves from confirmation to undo, the revert rate reveals how much the confirmation was actually protecting. A revert rate near zero means the dialog was almost entirely friction. A high revert rate means the action genuinely surprises users and may deserve a clearer preview or a stronger gate.
Treat reversibility as an architecture question, not a feature request. Retrofitting undo onto a system that was not designed for it is expensive and frequently incomplete. Systems where reversibility is a property of the data model — event sourcing, versioned state, soft deletes as the default — can offer undo broadly and cheaply. This is a decision that is much cheaper to make early than to correct later.
The deepest argument for the undo principle is not about error prevention. It is about what kind of relationship the product has with its users.
A product built on confirmation treats the user as a source of risk to be managed. Every dialog is a small assertion that the user might not know what they are doing and should be slowed down. A product built on reversibility treats the user as someone who will figure it out if given room to try — and takes on the engineering burden of making that room safe.
The second posture produces users who explore, discover, and use more of what has been built. It also produces a product that is more expensive to build and more honest about where its real dangers are, because when a confirmation dialog does appear, it means something.
Let the action happen. Keep the way back open. Reserve the gate for the doors that genuinely do not reopen.
In his 2015 letter to Amazon shareholders, Jeff Bezos described a distinction that has since become one of the most widely cited decision frameworks in technology — and one whose second half is almost universally ignored.
“Some decisions are consequential and irreversible or nearly irreversible — one-way doors — and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don’t like what you see on the other side, you can’t get back to where you were before. We can call these Type 1 decisions. But most decisions aren’t like that — they are changeable, reversible — they’re two-way doors.”
The part organizations remember is that important decisions deserve care. The part they forget is the sentence that follows: most decisions aren’t like that. Bezos’s actual argument was not that some decisions need more rigor. It was that organizations systematically apply heavyweight process to lightweight decisions, and that this misapplication is one of the primary sources of organizational slowness.
A product team wants to change the default sort order on a list view from newest-first to most-relevant-first. They believe it will improve task completion. They cannot be certain.
The change requires a design review, because it affects a shared component. It requires a product review, because it changes default behavior. It requires sign-off from the customer success lead, because some enterprise customers may notice. It goes on the agenda for the next cross-functional sync, which is in nine days. At that meeting, someone asks whether there is data supporting the change. There is not, because the change has not shipped. A decision is made to run an experiment. The experiment requires its own scoping.
Eleven weeks later, the sort order changes.
The change could have been reverted in four minutes by a single engineer at any point in those eleven weeks. It was a two-way door treated as a one-way door — and the eleven weeks were spent purchasing certainty that the reversibility had already made unnecessary.
The two-way door framework classifies decisions by reversibility rather than by importance, and prescribes fundamentally different decision processes for each class.
One-way doors are consequential and effectively irreversible. Walking through changes the available options permanently. Bezos’s prescription for these is deliberation, consultation, and methodical care — the heavyweight process that most organizations apply by default.
Two-way doors are changeable. If the outcome is unsatisfactory, the decision can be reopened and reversed at manageable cost. Bezos’s prescription is the opposite: these “can and should be made quickly by high judgment individuals or small groups.”
The critical claim in the framework is empirical rather than procedural: most decisions are two-way doors. The framework is not primarily a tool for identifying which decisions deserve extra care. It is a tool for identifying the large majority that deserve substantially less.
Bezos connected this to a companion principle in the same body of writing: that most decisions should be made with around seventy percent of the information one wishes one had. Waiting for ninety percent means being slow, and the ability to recognize and correct bad decisions quickly makes being wrong less costly than being slow. For reversible decisions, this arithmetic is straightforward — the cost of a wrong two-way door decision is bounded by the cost of walking back through.
The most common error in applying the framework is conflating reversibility with stakes. A decision can be highly consequential and fully reversible — a pricing experiment, a major UI change, a shift in positioning, a new onboarding flow. The consequences are significant. The reversibility is also real.
Conversely, some low-stakes decisions are genuinely irreversible: choosing a name that will appear in URLs, selecting a data format that customers will build integrations against, publishing an API contract. The immediate stakes look small. The doors are one-way.
Sorting decisions by importance produces the wrong process assignment. Sorting by reversibility produces the right one. Organizations that ask “how big is this?” instead of “can we undo this?” will over-process significant reversible decisions and under-process minor irreversible ones — which is exactly the pattern most product organizations exhibit.
Bezos identified a specific organizational pathology: as organizations grow, they tend to apply the heavyweight Type 1 process to most decisions, including the many that are Type 2. He named the consequences directly — slowness, unthoughtful risk aversion, failure to experiment, and diminished invention.
The mechanism is structural rather than cultural. Heavyweight process gets added in response to specific failures. A bad decision is made; a review step is added to prevent recurrence. The review step is not scoped to the class of decision that failed — it is applied to the category. Over time, the accumulated review layers apply uniformly to a decision space in which the original failure was a rare case.
Nobody designs this. It accretes. And because each individual review step was added for a defensible reason, dismantling it requires an argument that the original concern no longer applies, which is harder to make than the original addition was.
The purpose of heavyweight process is to increase confidence before committing. For one-way doors, this is the right trade — the cost of additional certainty is time, and the cost of being wrong is permanent.
For two-way doors, the trade inverts. Additional certainty still costs time, but the cost of being wrong is bounded and small. Spending eleven weeks to increase confidence from sixty percent to eighty percent on a decision that could be reverted in four minutes is not prudence. It is a category error about which currency is being spent.
The framework’s practical value is that it makes this arithmetic visible. Once a decision is named as a two-way door, the question “how much more certainty do we need?” has an obvious answer: enough to be worth trying, no more.
Amazon’s “disagree and commit” principle is directly downstream of the two-way door framework. The phrase permits a team member to state disagreement clearly and then support the decision fully, without requiring the disagreement to be resolved first.
This works specifically because most decisions are reversible. If the decision is a two-way door, unresolved disagreement is not dangerous — the disagreeing party’s concerns will be tested by reality faster than they could have been tested by argument. Consensus is expensive, and for reversible decisions, reality is a cheaper and better arbiter.
For one-way doors, disagree and commit is inappropriate. Those decisions genuinely warrant the resolution of substantive disagreement before committing, because reality will not offer a second opportunity.
Amazon’s own application of the framework is visible in the structural separation between decisions that require the six-page narrative memo process and decisions delegated to single-threaded owners. Major new business lines, significant capital commitments, and architectural decisions with long-lived consequences receive the heavyweight treatment. Feature-level product decisions, experiments, and operational changes are pushed to individuals or small teams with the explicit expectation of speed. The framework is not aspirational at Amazon — it is embedded in who has authority over which class of decision.
Netflix’s culture of “highly aligned, loosely coupled” operationalizes a similar distinction without using the same vocabulary. The company invests substantially in alignment on strategy and context — the equivalent of getting one-way doors right — and then delegates execution decisions broadly, with an explicit norm against requiring approval for reversible choices. Reed Hastings has described the approach as trading the cost of occasional bad reversible decisions for the speed of not requiring approval on the vast majority that turn out fine. The trade is only rational if most decisions are genuinely reversible, which is the framework’s empirical claim.
Basecamp’s Shape Up methodology encodes the distinction at the level of the work cycle. Decisions about what to build in a cycle are treated as significant and deliberate — closer to one-way doors, because a six-week commitment cannot be easily reversed mid-cycle. Decisions within the cycle about how to build it are delegated entirely to the team with no approval requirement, on the explicit reasoning that these choices are reversible within the cycle. The methodology’s speed comes substantially from refusing to apply commitment-level process to implementation-level decisions.
The two-way door framework matters because organizational slowness is rarely caused by decisions that were genuinely hard. It is caused by the accumulated overhead applied to decisions that were not.
The compounding effect is significant. A team that requires two weeks of process for every meaningful product change makes roughly twenty-six such changes per year. A team that reserves that process for genuinely irreversible decisions and moves quickly on the rest makes several times as many. Over a year, the second team has run more experiments, learned more, and corrected more errors — including errors the first team is still deliberating about.
There is also a quality argument that runs counter to intuition. Heavyweight process on reversible decisions does not reliably produce better decisions, because the additional confidence is purchased through argument and analysis rather than through evidence. For most product questions, the cheapest way to find out whether something works is to try it. Process that delays trying substitutes weaker evidence for stronger evidence and calls the substitution rigor.
The failure mode this framework guards against is not recklessness. It is the slow, defensible, thoroughly-reviewed accumulation of not shipping.
Classify the decision explicitly before choosing a process. Before scheduling any review, meeting, or approval cycle, ask a single question: if this turns out to be wrong, what does it cost to reverse? The answer determines the process. This takes thirty seconds and reliably prevents weeks of misapplied deliberation.
Audit existing approval requirements against reversibility. Most product organizations have accumulated approval gates that apply uniformly to a decision space in which the majority of decisions are reversible. Reviewing these gates and scoping them to genuinely irreversible decisions is one of the highest-leverage process interventions available, and it is almost always available.
Set an explicit confidence threshold for two-way doors. Bezos’s seventy percent figure is a useful default. For a reversible decision, once the team believes the change is more likely to help than hurt, further analysis is purchasing certainty that reversibility has already made cheap. Naming the threshold in advance prevents the drift toward more information.
Identify the genuine one-way doors and treat them accordingly. The framework cuts both ways. Decisions that are truly irreversible — data model choices, public API contracts, naming, pricing architecture, key hires — deserve more scrutiny than most organizations give them, precisely because they look ordinary at the moment they are made. A short list of decision types that are genuinely one-way, reviewed with the team, prevents the more dangerous half of the misclassification.
The framework’s power comes from a simple observation: organizations do not have a single decision-making problem, they have two, and the two require opposite solutions.
The visible problem is bad important decisions — the strategic error, the architectural choice that constrains everything after, the hire that damages a team. These are real, and they warrant care.
The invisible problem is the enormous volume of ordinary decisions processed at a speed calibrated to the visible problem. This one does not generate post-mortems, because nothing goes wrong. It generates a company that ships less than it could have, learns slower than it could have, and cannot explain why competitors seem to move faster.
Bezos’s insight was that these two problems are connected: the process that addresses the first, applied indiscriminately, causes the second.
Most doors open both ways. Walk through, look around, and come back if you need to. Save the deliberation for the ones that lock behind you.
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 1929, G.K. Chesterton described a thought experiment about a fence built across a road. A certain kind of reformer, he wrote, looks at the fence and says: “I don’t see the use of this — let us clear it away.” Chesterton’s response was sharp: if you don’t see the use of it, you’re not yet qualified to remove it. First understand why it was built. Then decide.
The principle sounds obvious. In product work, it’s violated constantly.
New PMs join a team and find a feature that seems redundant and propose cutting it. Engineers inherit a codebase with a mysterious function that appears to do nothing and delete it. A team redesigns an onboarding flow because the old one “feels dated” without asking why it was structured the way it was. In each case, the change feels like progress. Sometimes it is. And sometimes, weeks or months later, something breaks in a way nobody anticipated — because the fence was protecting something nobody remembered was there.
The cost of removing something you don’t understand is almost always higher than the cost of taking time to understand it. This isn’t an argument against change. It’s an argument against uninformed change — the kind that celebrates disruption as a virtue while treating existing decisions as obstacles rather than as encoded knowledge. Every feature that survived long enough to annoy you was built by someone who had a reason. That reason might be outdated. It might have been wrong from the start. But it exists, and ignoring it means making decisions based on ignorance rather than insight.
The principle scales with stakes. A low-risk, easily reversible change — removing a minor UI element, adjusting a default setting — deserves a quick check. A high-stakes, hard-to-reverse change — removing a core workflow, deprecating an integration, killing a feature that a specific segment depends on — deserves genuine investigation. The question is proportional: how much research does this fence require before you touch it?
For most product decisions, the answer is a single clarifying question. What was this originally intended to solve? That question, asked before the change rather than after, is what separates informed reform from expensive regret.
Step 1: Choose one thing you’re currently considering changing, removing, or replacing
It could be a product feature, a process your team follows, a metric you track, a workflow in the codebase, a policy in how you run sprint ceremonies, or a design pattern that keeps appearing in the product. What matters is that your first instinct is “this should go” or “this needs to change” — and that you haven’t yet asked why it’s there.
Step 2: Write down your current reasoning in one sentence
Before you do any research: why do you want to change this? What’s the problem it’s causing? Be specific. “It feels outdated” isn’t a reason — it’s an aesthetic reaction. “Users drop off at this step at a rate of 34%” is a reason. “The team spends 2 hours per sprint working around this” is a reason. Getting the real reason on paper is the first step, because it’s what you’ll compare against what you find.
Step 3: Ask the Chesterton question — and find the actual answer
The question is: “What problem was this originally built to solve?”
Not a hypothetical answer. The real one. This means:
Checking the git history, the Jira ticket, the Confluence doc, the Notion page — wherever decisions used to get recorded
Asking the person who built it, if they’re still around
Asking the person who’s been on the team longest what they remember about why it exists
Looking at what customer complaints or edge cases existed at the time it was introduced
You’re not looking for permission to keep it. You’re looking for the original problem — because that problem might still exist, might have evolved, or might have disappeared entirely. Each outcome leads to a different decision.
Step 4: Categorize what you found into one of three buckets
The problem no longer exists. The fence was built to solve something that’s no longer relevant — a competitor who pivoted, a technical constraint that’s been resolved, a user segment the product no longer serves. In this case, the fence can come down, and you can do so with confidence rather than assumption.
The problem still exists but the fence isn’t the best solution. The original reason was valid, but the approach has become outdated or there’s a better way to address the same need. This is a redesign, not a removal — and knowing the original problem tells you exactly what the redesign needs to preserve.
The problem still exists and the fence is still solving it. The thing you wanted to change is doing exactly what it was built to do. Your frustration with it is real, but removing it would reintroduce the problem it was solving. The work now is either to address the root cause differently, or to find a way to live with the fence while reducing the friction it creates.
Step 5: Make the decision — with the context you now have
Write one sentence: “Now that I understand why this fence exists, my decision is [keep / modify / remove] because [reason grounded in what you found].”
This sentence is qualitatively different from the one you would have written before doing the research. It might reach the same conclusion — remove it — but it does so from understanding rather than assumption. That difference matters for the decision itself, and it matters for how you communicate the decision to the people who will have to live with it.
Step 6: Document the context before you make the change
This is the step most teams skip — and it’s the one that creates the next generation of mystery fences. If you’re removing or changing something, write one sentence in the commit message, the ticket, or the product changelog that explains why the old version existed and why you’re changing it now. Future teammates will thank you. More importantly, you’ll never be the person who removed a fence without explanation — creating the exact problem Chesterton was describing for the next person who has to figure out what it was protecting.
For you: The habit of asking “why does this exist?” before “should this exist?” sounds small but changes the texture of how you approach inherited systems, legacy decisions, and existing product patterns. PMs who develop this reflex make fewer expensive reversals, communicate change decisions more credibly (because they can explain what they’re replacing and why), and build a reputation for thoughtfulness that compounds over time. It’s also a form of intellectual humility that stakeholders notice — you’re not the person who tears things down because they’re inconvenient; you’re the person who understands before they act.
For your team: When a team develops a shared Chesterton habit — when “do we know why this is here?” becomes a standard question before any significant change — the quality of change decisions improves substantially. Fewer features get removed and then quietly re-added six months later. Fewer refactors introduce regressions that could have been anticipated. Fewer process changes create the exact dysfunction they were designed to eliminate. The question doesn’t slow teams down in practice — it filters out the changes that would have created rework, which is far more expensive than the investigation.
For your organization: Every organization accumulates legacy: features nobody understands, processes that seem arbitrary, decisions that were made for reasons nobody can remember. Most of the time, these accumulate silently until a new leader arrives and begins dismantling them — quickly, confidently, and sometimes catastrophically. The antidote isn’t to preserve everything. It’s to build a culture where decisions get documented well enough that the next person can understand them. Chesterton’s Fence, practiced consistently, produces that culture as a side effect: when teams get in the habit of investigating before changing, they also get in the habit of recording why they changed — so the next fence has a label.
Find the fence. Ask why it’s there. Then decide.
One change, one investigation, this week. Write the reason down before you make the move.
Doing this challenge? Share what you found on LinkedIn or X and tag it #MLAChallenge. The reason a fence existed that you didn’t know about is almost always the most worth naming out loud.
The first step is all that counts for you, so you take the shortcut. And whatever you build the quick way stays for good. The shortcut that was meant to be temporary soaks into the product for years, and at some point it bites you in the ass so hard you cannot even trace where it came from. You take it because you think someone will clean it up later, except later nobody does, and some of those decisions can never be undone. They are easier to make, because you only look at what sits right in front of you and you do not have to guess what next year brings. But the less you look ahead, the better the odds that the thing you preferred not to see catches up with you in a form you can no longer reverse.
Thinking long term guarantees nothing, but it does one thing: it lowers the odds that the product falls over. And we still pick the easier path, because what we do now gets paid today, and what comes later gets paid by nobody. You can see it in what the industry publishes about itself. More and more posts, reports, talks and conference decks brag about the fast shot, about what someone shipped in a week, and fewer and fewer mention that something was anticipated, and that a decision made for the long haul actually paid off. I have no insight into how every team works, and that is not the point. I write about what shows on the surface, and about what I saw from the inside, because when those two pictures line up, it gets hard to call it an exception. And on the surface, short term thinking looks like the default setting today, and strategic thinking like a departure from the norm.
I want to show how this actually works, and I am not going to pretend I write about it with detachment. I have had enough of the narrative where shipping one thing after another gets called product development, even though nobody along the way planned anything, laid a foundation or asked a hard question, they just moved elements from one place to another. That is not product development, that is an imitation of it, and the data I cite further on shows what that imitation really costs. I do it not because I have a cure, but because I saw the same mechanism from the inside in so many different companies and teams that it stopped looking like coincidence. It always looks the same: someone makes a fast decision under pressure, the decision stays for years, and the cost is paid by someone else, much later, often without ever knowing where it came from. We talk about it too little, because talking about it is uncomfortable for everyone who makes those fast decisions, which is to say for almost all of us.
It is not that I have no idea what to do about it, it is that this is a different subject. Because the remedy exists, it has a name and it has an author. Teresa Torres described an approach in Continuous Discovery Habits that she calls continuous discovery and the product trio, where the team talks to users every week and learns as it goes, instead of guessing once a quarter what to build. That skill, continuous learning instead of shipping blind, is what separates the people who build a product from the ones who merely operate it, and it will decide more and more who stays in this line of work. But that is a subject for a separate piece, maybe a whole series, because you cannot handle it with a list bolted onto the end. I also have my own nine month project where all of this shows up in practice, and that is probably where I will start. Here I am staying with the problem itself, because naming it is where everything begins.
Let us start where it shows fastest, with the roadmap. In public we say we plan, that we are data driven, that every idea goes through discovery before we start building it. In private it often goes differently, because I have watched a roadmap get made two weeks before planning, with no data and no conversation with anyone who actually uses the product, based on what struck someone as a good idea, or on the so called hallway test, meaning asking three people from the team next door. And this is not a shameful secret people whisper about. At an industry conference I heard someone on stage present exactly that hallway test as their way of making product decisions, asking people inside their own company instead of the ones who actually use the thing. From the stage it sounds like a method. In the product it usually ends differently, because if that is how direction gets set, sooner or later you can see it in how the product behaves.
I know nobody plans a year ahead anymore, and that planning a few months out is often sensible, but there is a difference between deliberately shortening your plans and making strategic decisions two weeks before a sprint without a single number. The first is managing uncertainty, the second is guessing with a nice name on it. There is one more trap in this. Sometimes people ask us to decide, because we are the experts and we know best, and sometimes we genuinely do. But sometimes we do not, and then it is far smarter to find out from users what should be built and how, than to fake a confidence we do not have. That does not mean asking them about everything, because some things we really do know better, it means being able to tell which situation you are in.
The roadmap is only one symptom, though. I know this mechanism from my own experience, because I had to be part of that kind of planning more than once, and I saw that the same short term thinking that wrecks a roadmap also sits in the design system, in the architecture and in every decision made on the fly. It is not about one place, it is a pattern you can see everywhere at once, and it even has a name. John Cutler christened it the feature factory, where success gets measured by the count of things shipped, not by whether any of them changed anything. What interests me is not the factory itself but its source, meaning why short term thinking becomes the road we take so easily, even when we know better. And the roadmap is only the first of those places. The same thing shows up at the level of craft, in the design system, and there it leaves a trace you can count by the hour.
In the roadmap you see how short term thinking ruins decisions. In the design system you see how it ruins craft. But let us be clear: there is no such thing as a design system built short term, because a design system either exists or it does not. All its value sits in the connections between elements, so a pile of separate pieces is not a system in draft form, it is not a system at all, the way half a bridge is not a bridge you can partly walk across. What gets made under two weeks of pressure only looks like a design system, and is not one. Because a team thinking short term does not build a system, it ships one view after another, each on its own, as long as it works and lands on time, and nobody assembles them into a coherent, connected whole underneath, because that costs time nobody has. At the start you cannot see it, because the views are there, the deadline is met, nobody raises a problem. The problem arrives later, at the tenth view, at the twentieth, when it turns out nothing fits together, that the same thing was built five different ways, that changing one element means fixing forty places by hand. That is debt, taken on in the first week and repaid across a year, except the person repaying it is usually not the one who took it on, exactly the same pattern as with the roadmap, only moved down to the level of craft. Fast now, expensive later.
I know how this looks, because I walked into it myself. When the AI revolution was starting, I joined a startup to help develop the product, and I was assured the design system was ready and set up so changes could be made quickly. It was not. It was a pile of atoms, the smallest blocks in atomic design logic, but with no molecules or organisms built from them, meaning no larger, finished components, so nothing could be changed systemically and every small fix meant manual work in many places at once. That missing layer of molecules and organisms meant there was no way to show sprawling edge cases quickly, so instead of designing, I spent hours explaining to developers how something was supposed to work and look. Nothing was logically connected, so you could not even understand why one thing behaved one way and another differently. I came in from outside to help the product grow, and instead I first put out fires, and then explained why I was putting them out, because most people around me never asked why something should be built one way and not another, they just ticked off the task they were given. And that is why the foundation kept rotting, because nobody except me had any interest in touching it, given that ticking things off gets paid and fixing the foundation does not.
The most important part of this story is something else, though, because the cost did not end with my time. The real problem was not that we could not add new features, it was that the makeshift foundation made it impossible to check the one thing that mattered, whether the product we were building was needed by anyone at all. And that answer could have been had earlier and cheaper, in at least two ways, and we missed both. The first was before the first line of code, because proper discovery at the start could have triggered a pivot on its own, before anything existed, when there is nothing yet to tear down. The second was already underway, because a well built design system is itself a validation tool, on a solid foundation you assemble variants fast, show them and check whether the concept holds, with a handful of features instead of a full basic version. A bad foundation took even that away from us, because every variant cost so much that checking anything stopped being worth it, so we stopped.
Instead of catching the signal at either of those two moments, we built the full basic version, slowly, and only then started learning what we could have known much earlier. A pivot is the consequence of that kind of checking, and we could not do it in time, so it came far too late, and a late pivot is exactly the moment a product really dies. Building that product was not the mistake, because it was only on it that we understood what users actually wanted, the mistake was that the foundation slowed our learning down so much that we paid for the lesson in months. And this is not just my story. CB Insights analysed hundreds of failed startups, and the most common cause turned out to be no market need, meaning building something the market did not want, around 42% of cases. What matters most is that the information needed to avoid it almost always existed before anything got built, only nobody looked further than the next sprint. So short term thinking is not merely inconvenient later, it genuinely raises the odds that the whole thing falls over.
We have now seen where it surfaces, both in decisions and in craft. So it is worth asking directly where it comes from, and why the fast shot is the thing people brag about most. This is not just an impression from the internet, because McKinsey, on a sample of 615 companies between 2001 and 2014, calculated that long term oriented firms had on average 47% higher revenue growth and 36% higher earnings growth than the rest, though that is data on whole companies, not on digital products alone. And yet knowing something pays off is not enough to make people do it. Product people surveyed by the Pragmatic Institute admitted that strategic thinking takes up only 27% of their time, with the remaining 73% going to day to day churn, meaning daily shipping, small tasks and firefighting, even though they themselves believe those proportions should be roughly equal.
So the answer is not that people are stupid or lazy, it is that they respond rationally to how the rewards are set. Short term shipping gets rewarded, thinking ahead does not, so on top of nobody paying for it, the praise and the feeling of having delivered are right here and now. Meanwhile the effect of a long term decision will be seen by someone you may no longer be around for, and not just on that project but often at that company at all. And it is not that anyone passively waits for a reward that never comes for the long haul. People actively chase the short one, because it is within reach, and the system rewards what shows up immediately.
There is something more primal in this too. A closed ticket, a shipped feature, a completed sprint give you fast, tangible satisfaction right away, that small hit people casually blame on dopamine. Building something solidly gives you no such reward, because the effect arrives years later, so it is easy to slip into a mode where you are chasing not the result but the feeling of having delivered. It is the same loop as with rewards, only seen from the inside.
On top of that comes pressure, which in startups is constant background, not an exceptional situation. You have to show progress to the investor, you have to ship ahead of the competition, you have to close the quarter, and in that mode any conversation about what happens a year from now sounds like a luxury there is no time for. Ordinary FOMO shows up as well, because if everyone around is shipping fast, stopping to do something properly looks like a loss. And finally there is the simplest mechanism of all, which is that a fast decision is just easier, because asking a user, gathering data and thinking a system through takes effort, while “let us do it this way for now” takes five minutes. The sum of these mechanisms means short term thinking is rarely anyone’s conscious decision, it simply wins by default, because every one of them pushes in the same direction.
If short term thinking wins by default, then someone has to clean up after it. Tanya Reilly named that work most precisely when she wrote about glue work. It is the work that holds a team together but does not count at promotion time, and since short term decisions leave debt behind, this is the work that repays it. It is the fixing, the cleaning up after decisions made under pressure, the unifying of what got built in five variants, the documenting of what nobody documented. Reilly called it the difference between work that is valuable and work that is valued, and it is exactly the same reward paradox, only seen from the career side.
This work does not make it into case studies and it does not get reach, and that is no accident. Nobody hires for “tidies up how the team works”, so putting it front and centre always comes out one of two ways, and both are bad. Either you look like someone bragging about cleaning up after others, meaning ego, or like someone dragging into the open that the company is a mess, meaning a threat. So this work stays invisible not only because it is dull, but because showing it gets punished.
It is worth pausing on one thing here. The fast decision you make today almost never comes without a victim. Either it hits someone else, who picks up that piece after you and has to live with it, because that someone always shows up, or worse, it hits you, when six months later you come back to your own shortcut and wrestle with it, no longer remembering you left it there yourself. And the person who says something needs fixing is almost always the awkward one on the team, because they point at work nobody wanted to see, and they cut into the shipping rhythm with a message nobody wants to hear, namely let us stop, this is broken. Mid sprint, when everyone is watching the deadline, that voice sounds like an obstacle rather than help, and without it the debt never gets named, so it never gets repaid. Which is why whether a team has someone with the nerve to be awkward is a real product variable, not a matter of personality.
There is a rule everyone knows from life rather than from work: if something is meant to be temporary, it usually stays for good. The internet cable run across the whole hallway and taped to the floor, because one day it will be done properly. The cabinet assembled in a hurry, where you skipped two screws because it holds anyway, until a year later it buckles under everything you put on it. The door you have propped with a chair for a year because the lock gave out. The hole in the wall covered by a picture nobody wanted there. We all know this from home and we all laugh about it, and then we go to work and do exactly the same thing to a product.
History is full of it, just on a larger scale. The Eiffel Tower went up in 1889 as a temporary ornament for the world’s fair, with a permit for twenty years and a plan to dismantle it, and it stayed for good and became the symbol of Paris. Except that is the exception proving the rule, because its survival was not decided by its creator but by the lucky accident that it worked as a radio antenna. I bring it up deliberately as a positive example, so it is clear what is at stake, because if everything once put up for a moment stayed forever, Paris today would be a jumble of random sheds from that fair rather than a city, and nobody would want to wrestle with that.
Far more often, though, the other version happens. The QWERTY key layout you are most likely typing on right now was arranged in the nineteenth century so the arms of the typewriters of the day would not collide and jam, meaning it was designed around a hardware fault that has not existed for a very long time. The machines are gone, and all of us still tap away on a layout designed around their limitation, because it caught on once and the cost of switching to anything better became impossible to bear. And that is the default fate of a quick fix: not the Eiffel Tower, but yesterday’s solution you wrestle with daily, often without knowing it could have been otherwise.
If someone decides something will be connected temporarily, that we will do it the quick way now and fix it later, it will most likely stay that way forever, because there is never a good moment to go back, there is always something more urgent and always another deadline. And that is the heart of the whole problem, because short term thinking is dangerous not because you make one fast decision, but because that decision outlives you, works its way into the foundation of the product and sits there as something nobody questions anymore, because it was always like that. After a few years nobody even remembers it was supposed to be temporary, and that is exactly the moment the quick fix becomes the foundation everything else stands on.
Because this is not a scratch on a wall you paint over, it is a crack in the foundation you cannot paint over at all. A house built on badly poured foundations can stand, but it will lean and generate costs for generations, and nobody will take it down to nothing just to fix the foundation itself. In a product it works the same way, because the early, boring, invisible decisions about how things are connected and arranged determine everything you can later build on top, and because foundations are invisible, they are so easy to lay the quick way and so expensive to live with afterwards.
There is one more thing that amplifies all of it, and this one is often invisible from below and only shows from above: scale. As long as the organisation and the product are small, a badly poured foundation can be masked, worked around, propped up by someone’s heroic effort, and for a long time nobody sees a problem. The bigger the company, the harder it gets, because the same crack that one person handled manually in a team of five grows into something unmanageable in a team of a hundred. And the worst part is that organisations rarely see that moment as it happens, because from the level of daily work you cannot tell you have just crossed the threshold beyond which certain things can no longer be undone, and only later, usually too late, does it become clear how much it grew and how deep that quick fix sank into everything.
The best lessons about building digital products often do not come from our industry at all. I will take two from entirely different fields, from running a country and from architecture centuries old, because an example coming from outside product does not weaken the conclusion, it strengthens it. History is one of the best teachers, because it shows the effects of decisions at full scale, after decades or centuries, not after a single quarter.
The first is Singapore, a country that in a single generation covered ground most nations do not cover in a hundred years. In 1965, when it gained independence, its GDP per capita was around 500 dollars, roughly the same as Mexico, and today it is over 90 thousand dollars, more than in the United States (World Bank data for 2024). People usually point to one man and one way of thinking. Lee Kuan Yew, long serving prime minister rather than president, since that office is largely ceremonial, planned in generations rather than terms. Water, education, housing, economic standing, all of these were decisions whose effects were meant to show up thirty years out, not before the next election.
Take housing alone. When the national housing agency was set up in 1960, barely 9 percent of people lived in public units and most were crowded into slums and shacks, while today around 80 percent of Singaporeans live in such housing, and home ownership, close to 90 percent, is among the highest in the world (data from Singapore’s Housing and Development Board). You cannot ship a change like that in one quarter, it is the sum of generations of the same decision. The point is not to compare building a country to building an app, that would be a stretch, the point is a mechanism that works identically at both scales. A long term decision costs now and pays later, so to make it, someone has to consciously give up the reward they would get for a fast result.
The second lesson has been standing on water for centuries. Venice is built on millions of wooden piles driven into the mud of the lagoon, and those piles do not rot, because underwater, cut off from oxygen, wood does not decay, it hardens over time almost into stone. You see it best at the Santa Maria della Salute basilica, raised in gratitude after the plague of 1630, set on more than a million piles, consecrated in 1687, and still standing today, close to four centuries later. That gratitude was real, and that is exactly why someone made a decision so costly and so slow, even though they would not see the full effect in their lifetime. And that is the quiet answer to the question hanging over this whole piece: only someone with a reason bigger than the reward of the moment can afford a distance that long.
Singapore and Venice are two entirely different scales, a country and a city, politics and architecture, and the conclusion is the same. What lasts for decades gets built by someone who accepts they will not see the result of their work, or at least has a reason why that does not bother them. In a product exactly the same principle applies, only across a shorter distance, because we are not separated from the effect by centuries, at most by years or months. And that is precisely why it is so rare, because it turns out we do not even want to wait that long. We plan in weeks, and then we act surprised that the product looks the way it looks.
To be clear, I am not claiming short term thinking is always wrong. There are situations where the future of the company depends on shipping something right now, where you have to deploy fast, where you have to compromise, because the alternative is no company in six months, and then it is the right, mature decision. The difference is that it has to be a conscious, named departure from the norm. We are doing this the quick way, we know it is debt, we write it down and we plan the return, and then the shortcut is a tool you reach for in a specific situation rather than a mode you live in permanently.
It is worth defusing the counterargument that is about to come up, because it is a fair one. Someone will say fast iteration lowers risk, because the quicker you learn the smaller the chance you are building something nobody wants, and that is true, the “move fast” people have a point. Except here is the paradox that turns the whole intuition on its head: fast iteration is not something a shortcut gives you, a solid foundation gives it to you. A shortcut gives you speed only today and takes it away later, because on a quick fix every subsequent change costs many times more than it should, and after six months you are stuck. With a solidly built system it works the other way round, you pay in time now and get it back later, because when everything is tied into a system, you change any given thing cheaply and immediately. A shortcut buys speed for now and takes it away later, a foundation costs it now and returns it later with interest. Which is why the enemy is not pace, it is the foundation that either enables that pace or kills it.
And this is not abstract, because an unsettled shortcut like that can present its bill in a quarter of an hour. In 2012 Knight Capital, one of the largest market makers in the United States, was deploying new code to its servers by hand and missed one of them, and on that one server sat a dead fragment of code from 2003 they should have got rid of long before, but nobody ever removed it. The new deployment woke it up by accident, and in under 45 minutes that zombie bought and sold blindly, accumulating around 7 billion dollars in unwanted positions and sinking the firm by some 440 million dollars, more than it was worth. Seventeen years of building ended before lunch, because of a shortcut somebody failed to clean up years earlier. The problem starts when the exception becomes the rule, when every decision gets made as if the company were folding tomorrow, and “there is no time” is the answer to everything. Then firefighting stops being exceptional and works its way into the DNA of the job, and once it is there, strategic thinking has no room to happen. And the data says that for many of us this is already daily life, because if half your time goes on putting out fires, that is not an exception, that is the standard mode. Nuance matters more than a strong thesis here, because the problem is not that someone took a shortcut once, it is that the shortcut became the only road anyone knows.
I am not writing all this from the position of someone who thinks there is no way out. There is a way out, and there are people who have named it, and companies that have gone through it. In October 2017 Uber stopped work on new features and announced Fix-It Week, a week where engineers, data scientists and developers worked exclusively on repairing what was broken, sloppy or poorly documented. It also happens that entire teams pause their projects for months to repay accumulated debt.
There is something about this that struck me while I was looking for such examples. Descriptions of the effect are plentiful, how much was saved, how much faster things went afterwards. But there are almost no descriptions of who had to fight for it, how many times they heard there was no time, and what it cost them. The effect makes it into the case study, the fight for it does not, because that is exactly the work whose visibility gets punished. And that is why we need to talk about it more often, and why it takes nerve to say it out loud while everyone around is watching the deadline. Because without someone who says it, no Fix-It Week ever happens.
And before anyone says it out loud, each role has its own version of the same question. The product manager asks whether that shortcut is written down anywhere and whether anyone is accountable for returning to it, because debt nobody comes back to ends the same way as debt nobody recorded. The designer asks whether they are building this systemically or merely delivering a view, because a view made the quick way looks identical to a considered one, right up until you have to put twenty more next to it. The founder asks what their people actually get recognised for, because a team will build what gets rewarded, not what is written on the wall. I am deliberately not laying out the techniques here, that was covered at the start, but if you feel this problem where you work and you want me to go into concrete ways of working for those three roles in a separate piece, let me know, in a comment or in any other form, as long as it is a signal that this is worth digging into properly.
Let us go back to that easy decision from the beginning, the one you make while looking only at what sits right in front of you. It stays with you not because someone was at fault, but because nobody ever planned the moment you come back to it. Strategic thinking is in large part planning that return before you even take the shortcut. I know the reward for it does not arrive right away, and it is easy to think it does not pay off. But it does pay back, just in a different currency. When the fire comes, you are ready for it, because you know what you are dealing with. Trust remains, because solid work stays in people’s memory longer than one delivered sprint, and it is you they will come back to next time. The next job goes easier, and work you understand, rather than merely firefight, gives you more satisfaction. On top of that the market is slowly catching up, because in leadership research it is strategic thinking that most strongly separates the people who get promoted from the ones who stay put. And that is exactly why it is valuable, because as strategy researcher Rich Horwath estimates, only around three managers in ten think that way. Not every benefit arrives as an invoice someone has to pay. Some of it arrives as the fact that one day, sooner or later, you are the one who has it easier.
Tomek is a senior PM at a Series B company. He isn’t real, which is the only reason it’s safe to write about him, and about a third of the product people reading this are currently living inside his week.
He’s good. Ships. Runs discovery properly, which already puts him ahead of most. And about eighteen months ago he got very good at using AI, the way people who are good at their jobs tend to get good at new tools.
His work improved. That’s not the setup for a reversal — it’s just true. Better PRDs,
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.