A Roadmap Without “Why” Is a Backlog. AI Just Gave It the Name “Strategy” | When a Team Starts Doing Scrum Perfectly: On the Signals of the Italian Strike in Product Work
People worry about becoming obsolete. Most of them are right to worry — but for the wrong reason.
It’s not AI. It’s not the market. It’s not some mysterious force reshaping industries overnight.
It’s you. Specifically, it’s the version of you that decided to stop adapting.
I see it across every industry I touch, and the pattern is identical every time.
Doctors who graduated twenty years ago and still practice like medicine stopped evolving the day they got their diplomas. Medical knowledge used to last a career. Now it doubles roughly every few months. The treatment protocols from 2010 aren’t just outdated — some are actively unsafe. Yet the resistance to updating is the same: “This is how I was trained.”
Researchers still deliver 300-slide decks to clients who stopped reading past slide twelve sometime around 2018. Nobody wants your comprehensive report. They want to know what to do Monday morning and why. The craft of research didn’t die — the delivery format did.
Designers obsess over pixel perfection while their product fails to solve a single user problem. Nobody cares that your spacing is mathematically flawless if you can’t build a prototype and hold your own at the product table. The title was upgraded from UI designer to product designer. The competency often didn’t follow.
And product managers — the loudest panic right now. “AI can write a PRD in seconds.” If your entire value is writing documentation, then yes. You should be replaced. Your value is in solving problems, navigating ambiguity, and moving things forward when nobody agrees on the direction. That’s not automatable. That’s barely teachable.
Now — I know how this reads. Like someone who likes change lecturing people who don’t.
Fair. I do like change. My brain is wired for it. But don’t mistake wiring for ease.
When I was a researcher, I was that person. I wanted to show my craft. Show how rigorous my methodology was, how thorough my analysis, how perfect the work underneath. And then I noticed — nobody cared. Not about the craft itself. About the delivery. About the 300-slide monument to my thoroughness that nobody had time to read.
That hit something deep. Because the craft was my identity. The rigor, the methodology, the completeness — that’s what made me a researcher. Letting go of the format felt like letting go of the substance.
But I didn’t let go of the substance. I still do my research the same way — thorough, rigorous, evidence-based. I just deliver it differently. The craft is intact. The packaging changed. And that distinction saved my career.
It’s the same with everything I do now. The shift is real and it touches everything — your values, your identity, the way you’ve built your professional self-worth. I’m not pretending that’s painless. It’s not. Changing how you work when the work is who you are feels like someone rearranging your skeleton.
But the world doesn’t care how hard it is. The world moves forward. It can move with you or without you.
The half-life of professional skills has collapsed from a decade to under five years. In technical fields, closer to two. Flexibility, courage, the willingness to be bad at something new before you’re good at it — that’s the job now. In every role. In every industry.
Product Pro Summit — we’re behind it harder this year. Face-to-face conversations do something Slack channels can’t. Real rooms. Real people. Real exchange.
Now — something you’re hearing first.
We’re joining forces with other product people, soon you will here details. In 2027, there will be Product Jam — an autumn edition. Different formula, same principle: community comes together to exchange knowledge and share concepts that work.
No selling from the stage. Advisory board picks speakers. If you can’t bring value people can use or inspire — you don’t get the mic.
During this year’s Product Pro Summit, we’re doing a soft premiere of two things:
Product Sprint — a methodology from idea to scale. Discovery, shaping, building, scaling — all connected into one product strategy. It asks the right questions so you get the right outputs. Not a template. A thinking system.
Product Competency Map — different from what’s on the market. Everything out there focuses on product managers. Ours focuses on product people. Designer, developer, researcher, agile coach — if you build products, you need product skills. Nine categories. Seven craft domains. Two enabling categories — skills everyone calls “soft” that we know are the hardest. The skills that make you extraordinary.
Both get presented at Product Pro Summit. Mastermind sessions. Workshops. Proper announcement.
Follow the changes. Attend Product Pro Summit. Approach us. Start the conversation.
We’re looking for people who want to build this together.
Community without people is empty.
And if you’re not from Poland — come anyway. Sopot is one of the most beautiful spots on the Baltic coast, the conference community is warm and sharp, and product doesn’t have a language barrier when the problems are universal.
Web Summer Camp is a three-day, hands-on event for Europe’s web professionals — workshops, small group sessions, and real conversations, taking place July 3–5 in Opatija, Croatia. Not the kind of conference where you collect slides and forget about it by Monday. The kind where you actually work through problems with people who build digital products for a living.
This year they added an AI track — not because everyone else is doing it, but because they wanted to do it right. There’s also a dedicated Founders program and tracks for JavaScript, PHP, UX, and product.
Alex will be joining as a speaker. If you’re heading to Opatija this summer — or considering it — this is where to find her in person.
🍪 Anchoring in Pricing: The First Number Always Wins
There is a moment on every pricing page where the user forms their first impression of what the product costs. Everything that follows — every plan, every comparison, every “most popular” badge — is evaluated relative to that first impression. The user does not arrive at a price assessment from scratch. They anchor to the first number they see, and the rest of the page is interpreted through that lens.
This is not a soft preference or a general tendency. It is one of the most robust and well-replicated findings in behavioral economics. And product teams that understand it design pricing architectures deliberately around it. Those that don’t leave conversion, revenue, and positioning to chance.
Opening Hook
A SaaS company has three pricing plans. They display them left to right: Free, Professional at $15 per month, Business at $45 per month. Conversion to paid is flat. They run an experiment: they add an Enterprise plan at $120 per month on the far right, with “Contact Sales” as the CTA. They change nothing else about the page.
Conversion to the Business plan goes up. Revenue per paying user increases.
No one is clicking Enterprise. The Enterprise plan is doing its job by existing. It has shifted what users understand $45 per month to mean. Before, $45 per month was the expensive option. Now, it is the middle option — reasonable, sensible, reassuring. The anchor moved. The conversion followed.
What Is Anchoring?
Anchoring is the cognitive bias first formally identified by psychologists Amos Tversky and Daniel Kahneman in their landmark 1974 paper in Science, “Judgment Under Uncertainty: Heuristics and Biases.” Their research demonstrated that when people are exposed to an initial piece of numerical information, that number disproportionately influences their subsequent estimates and evaluations — even when the number is arbitrary and logically irrelevant to the judgment being made.
In the foundational experiment, participants watched a roulette wheel rigged to land on either 10 or 65, then were asked to estimate the percentage of African nations in the United Nations. Those who saw the wheel land on 65 estimated an average of 45 percent. Those who saw it land on 10 estimated an average of 25 percent. The number on the wheel had no relationship to the question being asked. It influenced the answer by 20 percentage points regardless.
The mechanism is what Kahneman later called anchoring and adjustment: when forming a judgment in an uncertain domain, the mind latches onto an available reference point and adjusts from it. The adjustment is systematically insufficient. The final judgment ends up closer to the anchor than independent reasoning would produce — and crucially, this effect persists even when the anchor is identified as arbitrary, even when participants are warned about it, even when significant incentives for accuracy are offered.
In pricing, no number is arbitrary. The first number a user encounters is a strategically selected reference point. Every price they evaluate after that is adjusted from it.
Breaking Down the Effect
The Three-Tier Architecture
The most widespread application of anchoring in SaaS pricing is the three-tier model. Research consistently shows that in three-option sets, buyers disproportionately choose the middle option. The highest tier anchors the middle tier as reasonable. The lowest tier anchors the middle tier as capable. The middle tier benefits from both anchors simultaneously.
This is not a coincidence of user preference — it is a predictable consequence of how anchoring operates. The highest price in the visible set functions as the reference point that makes the second price feel like a measured, considered choice rather than a compromise. Teams that design three-tier pages with the most expensive option on the left — visible first in reading order — are applying this deliberately. Teams that list plans from cheapest to most expensive are anchoring users to the lowest price, making every subsequent plan feel expensive by comparison.
The Decoy Effect as Anchoring Variant
A related pattern is the decoy effect: introducing a third option that is strictly inferior to one of the other options, designed not to be chosen but to make a target option look comparatively better. The classic illustration is Williams-Sonoma, where the introduction of a $429 bread maker dramatically increased sales of a $275 model that had previously seemed expensive. The $429 unit was rarely purchased. Its function was to reframe the $275 unit as accessible. The numbers on the page had not changed. The anchor had.
In SaaS pricing, decoy tiers are often obvious once identified: the plan that is slightly more expensive than another plan but offers meaningfully less per dollar, positioned to make the target plan look like the clear value choice. The decoy does not need to sell to justify its presence on the page. It needs to anchor.
Anchor Exposure Timing
A less commonly discussed dimension of anchoring in product design is when the anchor is introduced relative to the purchase decision. Users who encounter a high anchor before reaching a pricing page carry that anchor with them. A product that opens its homepage with a headline citing enterprise customer names, a case study with explicit ROI figures, or a “trusted by Fortune 500 companies” signal has implicitly established a quality and price anchor before the pricing page is ever seen. The pricing page encounter is not the first pricing cognition — it is the second.
Teams that control the pre-pricing-page experience can design the anchor environment, not just the pricing page itself.
The “Was/Now” Pattern
One of the most directly transactional applications of anchoring is strikethrough pricing: displaying an original price alongside a discounted current price. The original price anchors the user’s perception of value even when the original price was never a real market price — even when the product was never sold at that price. Research on retailer pricing behavior and consumer responses consistently shows that strikethrough anchors increase willingness to pay and purchase likelihood independent of the absolute price. The anchor does not need to have been real to function as a reference point.
Anchoring in Action
Apple’s pricing architecture across its hardware and services lines provides one of the most studied examples of anchoring at scale. The introduction of the original iPhone at $599 before the carrier-subsidized model dropped to $399 is a canonical case: the $599 anchor made $399 feel dramatically accessible, regardless of its absolute value. Apple has since systematically applied anchoring logic across its product line, with flagship Pro models anchoring the pricing perception for standard models, and annual subscription pricing for services displayed alongside monthly alternatives in ways that make annual pricing feel like captured savings rather than a large upfront cost.
Salesforce’s pricing architecture illustrates how enterprise SaaS applies anchoring across a tiered product lineup. The company’s highest tiers — Unlimited and Einstein editions — function primarily as anchors for the Professional and Enterprise tiers that the majority of customers actually purchase. Salesforce’s pricing pages display the most expensive options most prominently, ensuring that the first number users encounter creates a reference point against which the target conversion tiers are evaluated favorably. The architecture is not accidental. The company has published that pricing page design and tier positioning are subject to continuous experimentation, with anchor placement among the most impactful tested variables.
The Williams-Sonoma bread maker case, first documented by marketing researcher Robert Cialdini and referenced by Dan Ariely in “Predictably Irrational,” remains the cleanest real-world demonstration of anchor deployment in consumer product pricing. Williams-Sonoma’s $275 bread maker was selling poorly. A consultant suggested introducing a $429 model with superior features. Sales of the $275 model nearly doubled. The $429 model accounted for negligible revenue. The price architecture change produced one of the most cited examples of anchoring in retail — and the mechanism applies identically in digital product pricing.
Why This Matters
Pricing pages are typically designed as information architecture problems: how do we clearly communicate what is included at each price point? This framing misses the more important design question: what reference point do users arrive at these prices with, and how does our presentation shape that reference point?
Research by pricing consultants Price Intelligently found that SaaS pricing pages that lead with the highest-priced tier convert to higher average contract values, independent of the product category, even when the highest-priced tier is never selected. The anchor effect on perceived value operates across the entire pricing environment, not just on the individual plan chosen.
There is also an implicit positioning argument: the first number a user sees on a pricing page communicates something about the product’s category and quality before any feature is read. A product that opens its pricing page with a free tier communicates a different category signal than one that opens with an enterprise anchor. The anchor is not only a price reference — it is a brand signal.
The implication for teams is that pricing page design is not a conversion optimization problem to be solved with A/B tests on button color. It is an anchoring environment to be designed with explicit understanding of what reference points the user encounters, in what order, and how each subsequent price is evaluated relative to those reference points.
Putting It Into Practice
Design the order of price exposure deliberately. Before considering what prices to charge, determine what order users encounter prices in. On a pricing page, the first price visible in reading order establishes the primary anchor. On a homepage, any visible price reference — including enterprise customer names, ROI claims, and market comparisons — establishes a pre-pricing anchor. Make the order explicit and intentional.
Test anchor position before testing price levels. Teams that spend significant effort optimizing price points while ignoring anchor positioning are optimizing a second-order variable. A pricing page with the highest tier on the left and a well-structured anchor environment will typically outperform a pricing page with optimized individual prices but an unfavorable anchor architecture. Test anchor position and presentation first.
Use the enterprise tier as an anchor even when enterprise is not the primary revenue source. A plan at the high end of the pricing table that says “Contact Sales” functions as a price anchor for the tiers below it, even when no one clicks through. If the product has enterprise users at any scale, making that tier visible on the pricing page — with sufficient detail to establish legitimacy — changes the anchoring environment for every other tier.
Audit the pre-pricing-page experience for anchor consistency. What price signals does the product send before the user reaches the pricing page? Homepage copy, case studies, partner logos, and enterprise customer mentions all create implicit price anchors. If the product is positioned as a premium tool in all its marketing and then reveals a free tier prominently on the pricing page, the anchor environment is inconsistent. The signals should sequence from quality establishment to price revelation.
Recognize that strikethrough pricing works even when the original price is aspirational. The anchoring mechanism does not require that the original price was ever charged — it requires that users see it before the current price. Annual pricing displayed as “save $X versus monthly” anchors the monthly price as the reference and makes the annual price feel like a discount, regardless of whether users ever considered paying monthly.
The Bigger Picture
Anchoring is not a trick applied to unsuspecting users. It is a description of how human cognition operates under uncertainty. Users arrive at a pricing page not knowing what the product should cost. They need a reference point. Every pricing page provides one — the only question is whether the reference point was designed deliberately or by default.
Tversky and Kahneman’s roulette wheel experiment was striking not because it revealed a flaw in human judgment but because it demonstrated how reliably the mind reaches for available reference points when navigating uncertain domains. Pricing is exactly this kind of domain: most users have no independent basis for evaluating whether a product is worth $15 or $150 per month. The anchor is not manipulating a previously formed judgment. It is providing the starting point for a judgment that would otherwise have no starting point at all.
Designing that starting point deliberately is not manipulation. It is product design. The alternative — leaving the anchor environment to chance — does not produce neutral pricing perception. It produces an anchor set by whatever the user saw last, which may be a competitor’s pricing page, a forum discussion, or an outdated memory of a prior product in the category.
🍪 Network Density vs. Network Size: Why More Users Is Not Always a Better Product
There is a number that product teams obsess over from day one: total users. It appears in investor decks, growth reviews, and press releases. It is the headline metric that signals momentum. And in some products, it genuinely is the most important measure of network health. But in many others — perhaps most — total users is a misleading proxy for the thing that actually creates value. What matters is not how many people are in the network. It is how connected they are to each other.
This is the distinction between network size and network density. And confusing the two has led to growth strategies that scaled users without scaling value, platforms that collapsed under their own breadth, and product decisions that optimized the wrong dimension of network health for years before anyone noticed.
Opening Hook
Two messaging apps launch in the same year. The first grows to 100 million registered users in three years. The second grows to 20 million. By most growth metrics, the first is the more successful product. But the second has a meaningfully higher proportion of users who communicate with each other daily, who use the app as their primary channel for close relationships, and who describe it as indispensable.
When both products encounter a critical feature decision — whether to add a public discovery feed — the first team reasons that more connections equals more value and builds the feed. The second team reasons that its value comes from the quality of connections between specific people, and declines.
Several years later, the first product has lost significant daily active usage to alternatives. The second has become the default messaging layer for its users’ closest relationships. The users who used the first product to talk to 300 people used it for nothing in particular. The users who used the second product to talk to 30 people used it for everything that mattered.
Network size is not network value. The distinction is density.
What Is Network Density?
In graph theory and social network analysis, network density is the ratio of actual connections within a network to the total possible connections between its nodes. A network of ten nodes in which every node is connected to every other node has a density of 1.0. A network of ten nodes in which each node connects to only one other has a density of 0.1.
The concept was formalized in sociological network analysis through the work of researchers including Mark Granovetter, whose 1973 paper “The Strength of Weak Ties” established that the character of connections — their strength, frequency, and reciprocity — matters as much as their quantity. A dense network of strong connections behaves differently from a large network of weak ones: it transmits information faster, sustains behavior change more effectively, and creates higher switching costs.
In product design, network density describes the proportion of possible meaningful interactions between users that are actually occurring. A social platform with 100 million users among whom the average user interacts with 3 others has low density. A communications platform with 10 million users among whom the average user interacts with 40 others has high density. The second platform, despite being smaller, may create significantly more value per user and exhibit stronger network effects.
The key insight is that Metcalfe’s Law — which holds that the value of a network scales with the square of its nodes — assumes connections are uniformly valuable. In real networks, they are not. A connection between two people who never interact contributes near-zero value. A connection between two people who communicate daily is the reason one or both of them stays on the platform.
Breaking Down the Distinction
Sparse Networks and the Broadcast Problem
Large social platforms tend toward low density as they scale. As user counts grow, the average user’s connection graph expands to include acquaintances, professional contacts, and algorithmically suggested connections who share no prior relationship. The platform becomes a broadcast medium: users post to a diffuse audience, receive content from people they barely know, and develop no compelling reason to return specifically to that platform rather than any other.
This is the broadcast problem. A dense network is one where users return because specific people they care about are there. A sparse network is one where users return because content is there. The second is perpetually vulnerable to a better content algorithm. The first is structurally resistant to alternatives, because the relationships themselves are not portable.
Dunbar’s Number and the Intimacy Ceiling
Anthropologist Robin Dunbar’s research on social cognition found that humans maintain stable social relationships with approximately 150 people, with a much smaller inner circle of 5 to 15 people who receive the majority of social investment. These numbers reflect the cognitive limits of meaningful relationship maintenance.
The practical product implication is that the meaningful relationship layer of any user’s social graph is small and bounded. Products that operate within that layer — that facilitate interactions among the 15 people a user genuinely cares about most — create fundamentally different value from products that operate across 500 nominally connected accounts. A product that wins the inner circle captures the most durable, highest-value portion of the user’s social attention. A product that wins the outer circle is competing on content quality and novelty, which degrades.
Negative Network Effects at Scale
Beyond a certain point, network size can actively reduce density and therefore reduce value. Research on online community behavior, including studies of Reddit and large Discord servers, consistently shows that as community size increases beyond a threshold, individual participation declines, the quality of interactions decreases, and members report reduced sense of belonging. The network effect that drove growth inverts: each additional user makes the experience slightly worse for existing users rather than slightly better.
This phenomenon — negative network effects at scale — is one of the least discussed dynamics in product strategy. It explains why large social platforms often see declining engagement per user as they grow, why Discord’s most active and loyal communities tend to be smaller servers rather than massive public ones, and why products designed for intimate use cases frequently serve their users better at constrained scale than at maximum reach.
The Density-First Growth Strategy
A growing number of products have built their growth strategies around density rather than size. Rather than maximizing user acquisition, these products focus on maximizing the connection density of acquired users before expanding the user base. This approach — sometimes described as ensuring the product works completely within a small, dense network before adding more users — produces slower headline growth but stronger long-term retention and word-of-mouth.
The strategic logic is that a dense network generates organic growth through authentic advocacy: users who find genuine value in tight-knit use cases recommend the product to their own close contacts, producing acquisition within high-affinity social graphs. This is structurally more durable than growth driven by broad targeting, because the acquired users arrive through relationships that already exist in the density layer the product serves.
Network Density in Action
WhatsApp’s design philosophy has consistently prioritized density over size. The product’s group size limit — historically far below what competing platforms offered — was not a technical constraint but a design decision rooted in the recognition that WhatsApp’s value derives from intimate group communication. Groups of 5 to 20 people communicating about specific shared contexts — families, close friend groups, team coordination — generate fundamentally different interaction patterns from groups of 500. WhatsApp’s limit enforces a density minimum: every group must be small enough that every member is a meaningful connection. The product has reached over two billion users by doubling down on the intimate use case rather than expanding toward the broadcast model that characterized Facebook.
Discord’s architecture makes density visible at the structural level. Servers are not undifferentiated populations — they are organized into channels, each focused on a specific topic or interaction type. A server with 10,000 members and 50 channels has many different density layers operating simultaneously: a general channel with low density and broad reach, a focused game-strategy channel with high density among engaged players, and direct message threads with maximum density between pairs. Discord’s product success — particularly among communities with strong shared interests — derives from its ability to maintain high-density interaction contexts within large networks. The small-channel architecture creates density within size.
Strava’s approach to social features illustrates density-conscious product design in a fitness context. The platform has consistently resisted the expansion toward public discovery and broad social following that characterized other fitness apps, instead investing in close-connection features: the “Local Legend” recognition for users who are the most active on specific segments of routes, the segment-based leaderboards that create competition among specific geographic communities, and the activity feed designed around the workout behaviors of people the user actually knows. Strava’s NPS and retention data have consistently outperformed broader fitness platforms despite smaller user counts, a pattern that correlates with its commitment to the density layer of its social graph rather than the broadcast layer.
Why This Matters
The confusion between network size and network density produces specific and predictable strategic errors. Growth teams optimize for user acquisition without examining whether acquired users are forming meaningful connections. Product teams add discovery features that increase breadth while diluting depth. Investors evaluate platforms on total users without asking whether those users are actually using the platform to interact with each other.
The result is a category of platforms that are large but fragile. They retain users through content abundance rather than relationship necessity. When a better content algorithm appears — or when a platform with deeper density wins the close-connection use case — the switching cost is low. Users leave because they were never truly embedded. The network they were part of was large but not dense.
Research from NFX, a venture firm focused on network effects, has documented that the most durable network-effect businesses are not necessarily the largest ones — they are the ones with the highest density of high-value connections within their user base. Density creates the switching costs, the word-of-mouth, and the habitual return behavior that constitute genuine defensibility. Size without density creates the appearance of those properties without the substance.
Putting It Into Practice
Measure connection density, not just connection count. For any social or communication product, the average number of meaningful interactions per user per period is more diagnostic of network health than total user count. Define “meaningful interaction” for the specific product context — a message read and replied to, a piece of content that prompted a comment, a session in which the user interacted with someone they know — and track its distribution across the user base.
Identify the density layer and design for it explicitly. Every networked product has a density layer: the portion of the user’s social graph where interactions are high-frequency and high-value. For a messaging app, it is the inner circle of close contacts. For a professional network, it may be the immediate team or working group. For a fitness platform, it may be local training partners. Make explicit product decisions to serve this layer well before optimizing for the outer layers.
Be cautious with broadcast features that increase size at the cost of density. Public discovery feeds, algorithmic content recommendations, and follower-based broadcasting increase the available surface area of a social network while typically reducing the average interaction density. These features are not inherently wrong — they serve legitimate use cases — but their effect on the density layer should be monitored. If average interaction quality per user declines following the introduction of a broadcast feature, the feature may have diluted density in the service of size.
Apply group size constraints deliberately. WhatsApp’s group size limits are a density enforcement mechanism. Products that want to preserve intimate interaction contexts can use architectural constraints — group size limits, channel member caps, notification designs that favor close connections — to maintain density minimums as the user base grows.
Evaluate growth channel quality by subsequent connection density. Users acquired through broadcast advertising or viral loops often have low subsequent connection density — they arrive without existing relationships on the platform and do not form them at the rate of users acquired through word-of-mouth from close contacts. Tracking connection density by acquisition channel reveals whether growth is building the network or merely inflating the user count.
The Bigger Picture
The emphasis on total user counts in product strategy reflects a genuine truth about certain network types: platforms where the value is in content abundance or marketplace liquidity genuinely do benefit primarily from size. A search engine, a marketplace, or a content recommendation platform is better with more nodes, and Metcalfe’s logic largely holds.
But for the large category of products where value is created between specific people — messaging, close-community platforms, collaborative tools, interest-specific social networks — the relevant question is not how many people are in the network but how many meaningful connections those people are forming with each other. Density determines whether the product is embedded in users’ lives or merely present in their app drawers.
The most defensible products in this category are not the biggest. They are the ones whose users depend on them to maintain the most valuable relationships they have — the ones where leaving would mean losing something real. That dependency does not come from size. It comes from the quality of the connections that density creates.
Build the network users need. Not just the one they have.
🍪 The Law of Shitty Clickthroughs: Why Every Growth Channel Eventually Stops Working
In 1994, the first banner ad ever displayed on the web appeared on HotWired magazine’s website. The ad, for AT&T, carried a headline that asked: “Have you ever clicked your mouse right here? You will.” Clickthrough rates for that ad were reported at approximately 78 percent.
The average clickthrough rate for display advertising today is around 0.1 percent.
That is not a story about banner ads getting worse. It is a story about a law that applies to every marketing and distribution channel that has ever existed — a law that product teams routinely learn, briefly acknowledge, and then ignore in their growth planning. Andrew Chen, now a partner at Andreessen Horowitz, named it the Law of Shitty Clickthroughs. Its implications reach much further than its name suggests.
Opening Hook
A product team discovers that in-app push notifications are driving significant re-engagement. Open rates are 35 percent, well above industry benchmarks. The team increases notification frequency. Open rates hold through the first month. By month three, they are at 22 percent. By month six, they are at 11 percent. The team writes more targeted copy, segments more precisely, and A/B tests subject lines. Open rates stabilize at 9 percent. Two years after the initial excitement, the channel that drove re-engagement reliably is now a source of opt-outs and minor churn.
Nothing went wrong in the execution. Everything went exactly as the Law of Shitty Clickthroughs predicts.
What Is the Law of Shitty Clickthroughs?
The Law of Shitty Clickthroughs states that over time, all marketing channels and distribution strategies result in declining performance, regardless of how well they are executed.
Andrew Chen formalized the concept in an essay published on his blog in 2012, drawing on the efficient market hypothesis as an analogy. His core observation: every marketing channel that works attracts competitors, who replicate the channel approach, which saturates the channel audience, which causes the audience to develop selective attention and avoidance, which reduces performance for everyone in the channel. The channel does not become ineffective because individual practitioners execute it poorly. It becomes ineffective because success attracts replication, and replication triggers habituation.
The mechanism is simple and unavoidable. Novelty drives engagement. When a channel is new, the user’s attention is not yet calibrated to filter it. The first email marketing campaigns generated open rates that current practitioners would consider fictional. The first SMS marketing campaigns had response rates that no current SMS program achieves. The first push notification campaigns drove re-engagement at rates that normalize downward within months. The first influencer campaigns on any given platform outperform every subsequent campaign on that platform, because users develop mental models that allow them to recognize and discount the format.
This is not merely an advertising phenomenon. It applies to every mechanism by which a product can acquire or re-engage users: organic search, referral programs, viral mechanics, app store optimization, content marketing, cold outreach, and in-product notification systems. Every channel decays. The question is only how fast, and what to do about it.
Breaking Down the Law
Three Mechanisms of Decay
Chen identified three primary drivers of channel degradation. The first is novelty erosion: users respond to new formats and new types of outreach with curiosity and attention, then develop pattern recognition that allows them to identify and deprioritize familiar formats. Banner blindness — the documented neurological phenomenon in which users visually process banner ads without consciously perceiving them — is the most studied example, but the same cognitive adaptation applies to any repeated format.
The second mechanism is competitive saturation. A channel that performs well for one product attracts imitators. As more products compete for attention in the same channel, the signal-to-noise ratio degrades. Email newsletters had exceptional open rates when few people were writing them. When every SaaS company published a weekly newsletter, the category became cognitively overloaded. The individual product’s quality may be unchanged, but its performance in the channel drops because the channel itself is now crowded.
The third mechanism is early adopter depletion. The earliest users acquired through any channel are disproportionately likely to be high-fit prospects: they are actively seeking solutions, predisposed to engagement, and likely to become strong advocates. As the channel continues to operate, it progressively reaches less qualified audiences — users further from the core use case, less predisposed to engage, and more likely to exhibit the low conversion rates that reflect a mismatch between channel audience and product value proposition.
The Channel Lifecycle
Every channel follows a recognizable lifecycle: discovery, efficiency, saturation, decay. In the discovery phase, early movers enjoy dramatically elevated performance because the channel is uncontested and the audience is fresh. In the efficiency phase, optimization effort produces measurable improvements as the team learns to use the channel well. In the saturation phase, the channel has attracted significant competition and performance stabilizes at a lower equilibrium despite continued optimization. In the decay phase, audience habituation and competitive crowding push performance below the threshold of efficient resource investment.
The lifecycle duration varies by channel type — paid search has operated at lower efficiency than its 2002 peak for over two decades but remains viable; some viral mechanics decay within months — but the sequence is consistent. No channel stays in the efficiency phase indefinitely.
The Efficient Market Analogy
Chen’s insight that the Law of Shitty Clickthroughs resembles the efficient market hypothesis is worth taking seriously. In financial markets, the efficient market hypothesis holds that prices reflect available information, making it impossible to consistently generate excess returns through information advantages that others also possess. Similarly, in marketing channels, any technique that generates excess returns (above-average engagement and conversion) attracts replication, which distributes the technique broadly, which eliminates the excess return. Performance regresses to the competitive mean.
The implication for product teams is identical to the implication for investors: excess returns are available only from information advantages that are not yet widely distributed. The window of advantage is real but temporary. Systematically seeking that window — rather than defending a position in channels that have already been found — is the structural response.
The Law in Action
Airbnb’s early growth depended substantially on a widely-documented tactic: cross-posting listings to Craigslist without Craigslist’s formal partnership, capturing the audience of users already searching for accommodation on a much larger platform. The tactic worked because Craigslist’s audience had not yet learned to identify and discount Airbnb-specific listings. Once the approach was widely documented and replicated, and once Craigslist actively worked to block it, the channel was no longer available. Airbnb’s growth continued through different mechanisms, but the Craigslist channel — extraordinarily effective for a specific window — decayed as the Law predicts.
Dropbox’s referral program — offering additional storage to users who successfully referred friends — is one of the most cited examples of a viral growth mechanic in startup history. The program drove exceptional growth between 2009 and 2012. By the mid-2010s, storage-for-referrals had become a standard category tactic, and its effectiveness as a differentiating growth mechanism had correspondingly declined. The mechanic had crossed from the discovery phase to saturation. Every cloud storage product offered something similar. The channel that had been Dropbox’s growth engine was no longer capable of delivering excess returns.
SEO has followed the Law’s arc across a 25-year period. Early search engine optimization, when few practitioners understood the relationship between page structure, link profiles, and rankings, delivered extraordinary returns to early adopters. The professionalization of the field, the development of dedicated SEO tooling, and the broad adoption of content marketing have progressively competed away those returns. Organic search remains a significant acquisition channel for many products, but the window of structural advantage that existed for early SEO practitioners has closed. Today, competing effectively in organic search requires either superior execution in a saturated field or the identification of keyword and content spaces where competition has not yet arrived — a continual search for the edge of the channel.
TikTok’s emergence as a distribution channel illustrates the Law’s early phase in a modern context. Brands and creators who built audiences on TikTok in 2019 and 2020 benefited from an uncontested channel with a highly engaged audience that had not yet developed filtering behavior toward branded or promotional content. By 2023, TikTok creator and brand content had become significantly more competitive, platform algorithms had evolved to address commercial content differently, and the above-average returns available to early movers had normalized. The channel remains viable but no longer delivers the excess performance of its discovery phase.
Why This Matters
The Law of Shitty Clickthroughs matters for product teams because it reframes growth strategy from a problem of channel optimization to a problem of channel discovery and sequencing. Teams that treat growth as an optimization problem — get better at the channels currently being used — will achieve incremental improvement within a declining baseline. Teams that treat growth as an exploration problem — find the next channel before the current ones have fully decayed — maintain the structural advantage of operating in the discovery and early efficiency phases.
This reframing has implications for how growth budgets are allocated, how growth teams are structured, and how success is measured. Optimization-oriented teams measure success by performance improvement within existing channels. Discovery-oriented teams measure success by identifying new channels with above-average early performance before those channels reach saturation.
There is also an honest implication for how product teams should evaluate the durability of growth. A growth rate built primarily on current channel efficiency is not equivalent to a growth rate built on product-driven word-of-mouth or structural network effects. The first degrades as the channels decay. The second is more durable because it is less channel-dependent. Product teams that attribute growth to channel performance rather than to product value may be building on a foundation that the Law will eventually erode.
Putting It Into Practice
Track channel performance trends, not just current channel performance. A channel with a 5 percent open rate that was at 8 percent six months ago is in a different strategic position from a channel with a 5 percent open rate that has held steady. Trend data reveals where a channel sits on the decay curve and provides early warning before performance reaches the threshold that triggers an explicit strategic response.
Dedicate explicit resources to channel discovery in parallel with channel optimization. Growth teams that allocate 100 percent of their capacity to optimizing current channels will be reactive when those channels decay. The team that has been running small experiments on emerging channels is positioned to scale something that already shows early efficacy rather than starting from scratch when the primary channels falter.
Distinguish between channel decay and execution quality. When a channel’s performance declines, the first diagnostic question should be whether the decline is driven by execution problems (which optimization can address) or by structural habituation and saturation (which optimization cannot address). Continuing to invest in optimization when the problem is structural is the most common expensive mistake teams make in response to channel decay.
Evaluate whether channel performance reflects excess returns or competitive equilibrium. A channel delivering above-average returns is either in the discovery or early efficiency phase, or is being run with genuine differentiation that produces sustainable above-average performance. Honest assessment of which situation applies determines how aggressively to scale the channel. Excess returns from novelty should be scaled rapidly and the team should simultaneously be building pipeline on the next channel. Excess returns from genuine differentiation can be scaled more durably.
Build distribution that is less susceptible to the Law. Word-of-mouth driven by genuine product value, structural network effects that increase value with use, and community-based distribution that operates within high-density social graphs are meaningfully more resistant to the Law of Shitty Clickthroughs than broadcast channels. Not because they are immune to it — no distribution is — but because they decay more slowly and are harder to replicate. When Andrew Chen points to the 10x solution as finding the next uncontested channel, the more durable version of that solution is building a product that creates its own distribution through the value it delivers.
The Bigger Picture
The Law of Shitty Clickthroughs is one of the most honest descriptions in the growth literature of how distribution actually works over time. It acknowledges that no channel advantage is permanent, that optimization is a second-order strategy compared to discovery, and that the history of every successful marketing channel is ultimately the history of diminishing returns.
The appropriate response to this law is not pessimism. It is realism about the architecture of durable growth. Channels decay; products can be designed to generate distribution that is less dependent on any single channel. Novelty fades; value-driven behavior is more sustainable. Excess returns normalize; the only reliable source of excess returns is operating ahead of where the competition has arrived.
The first banner ad had a 78 percent clickthrough rate because no one had ever seen a banner ad before. The lesson is not that banner ads were good and are now bad. The lesson is that novelty is always a temporary advantage. Build for what works when the novelty is gone.
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
MLA: Stakeholder Map Refresh
Why This Matters
Every product manager has a mental model of who matters. It’s not written down anywhere — it lives in the head, accumulated through experience: who tends to push back, who needs to be looped in before a decision lands, who can unblock something when it stalls. This mental model works well enough most of the time. And that’s exactly the problem.
Mental models of stakeholder landscapes don’t update automatically. They’re shaped by the last six months of interactions, which means they systematically underweight people who’ve been quiet, people who joined recently, or people whose influence shows up only at decision points rather than in day-to-day conversation. Research on stakeholder management consistently surfaces the same finding: influence often comes from unexpected places, and ignoring secondary or less visible stakeholders is one of the most common — and most costly — blind spots in product work. Nearly a third of product teams have no regular communication with customer-facing teams at all, not because they don’t value those perspectives, but because those relationships never made it onto anyone’s informal list of who needs to be engaged.
The consequence isn’t dramatic. It’s subtle. A roadmap decision gets made with incomplete input. A launch creates friction with a team that was never consulted. A priority call gets reversed at the last minute because someone with veto power — whom nobody thought to brief — raises an objection. Each incident is explainable in isolation. As a pattern, it signals a stakeholder map that’s out of date.
The influence-interest grid — one of the oldest and most durable tools in product management — exists precisely because keeping stakeholder landscapes explicit and visual forces you to notice gaps that your mental model smooths over. Not as a bureaucratic exercise, but as a calibration. Who has high influence but isn’t engaged? Who has genuine interest but no voice in current conversations? And, most importantly: who is absent from the map entirely — not because they’re irrelevant, but because they haven’t been loud enough to appear on your radar?
That last question is the one worth sitting with this week.
How to Execute
Step 1: Block 30 minutes — paper or whiteboard preferred
The physical act of drawing the map matters more than the tool. A whiteboard or a sheet of paper forces you to slow down and think spatially rather than just listing names. If you prefer digital, a simple 2x2 in Miro or on a slide is fine — but resist the pull toward a spreadsheet. This is a thinking exercise, not a database.
Step 2: Draw the influence-interest grid
Four quadrants, two axes:
Vertical axis: Influence — how much power does this person or group have to affect product decisions, resources, or outcomes?
Horizontal axis: Interest — how much do they care about what you’re building, and how closely do they follow it?
Label the quadrants:
High influence, high interest → Key Players — manage closely, engage frequently
High influence, low interest → Keep Satisfied — don’t ignore; brief proactively on anything that could affect them
Low influence, high interest → Keep Informed — they’re engaged and often a source of signal; don’t lose them
Low influence, low interest → Monitor — low investment needed, but worth knowing they exist
Step 3: Populate the grid — start fast, then slow down
Spend the first five minutes writing every name that comes to mind without overthinking placement. Get them on the map. Then slow down and ask yourself, for each person:
Is this where they actually sit, or where I think they sit based on past experience?
Has their influence or interest shifted in the last three to six months?
Am I placing them here because of evidence, or because of how much I interact with them?
The last question matters most. High-interaction stakeholders tend to be overrepresented on mental maps. Low-interaction ones tend to be underrepresented — even when their influence is real.
Step 4: Run the three gap checks
Once the grid is populated, look for three specific patterns:
Gap 1 — The missing voice. Is there a function, team, or role that affects your product or is affected by it, but has no one on the map? Customer success, legal, finance, operations, and frontline sales are common omissions. If someone regularly deals with the consequences of your product decisions but isn’t on the map, that’s a gap.
Gap 2 — The silent influencer. Is there anyone in the high-influence quadrants — kept satisfied or key players — whom you haven’t spoken to in the last 30 days? If so, you’re managing that relationship on assumptions rather than current information. Assumptions about stakeholder priorities go stale faster than most PMs realize.
Gap 3 — The underused signal source. Is there anyone in the low-influence, high-interest quadrant who is consistently engaged with your product but rarely included in conversations? These stakeholders often carry the most honest, unfiltered perspectives on what’s working and what isn’t — precisely because they’re close to users or outcomes without being close to decision-making politics.
Step 5: Name one action for each gap you found
Not a plan — just one specific next step per gap. A message to someone you haven’t spoken to recently. A meeting with a team that’s been absent from your conversations. A question you’ll bring to someone in the high-interest quadrant who hasn’t been asked for input lately.
Write each action in one sentence, with a name and a rough timeframe. If you can’t name a person, the gap is real but too abstract — keep digging until you can.
Step 6: Share the map with one teammate and compare
Show the map to someone who works closely with you — a designer, an engineer, someone from customer success. Ask them to add anyone they think is missing before you explain your thinking. What they add, and why, will tell you something your solo map couldn’t.
Expected Benefits
For you: The value of this exercise isn’t the map — it’s the moment when you realize someone important is missing from it. That realization tends to happen fast, usually within the first ten minutes, and it has a disproportionate return on the time invested. PMs who maintain an explicit, updated stakeholder map make fewer “how did this come up now?” decisions. They brief more proactively, surface resistance earlier, and spend less time in damage control after launch.
For your team: When a PM’s stakeholder map is visible — even informally — it creates shared awareness about who needs to be involved at what stage. Designers stop being surprised when legal has opinions. Engineers stop hearing about customer success concerns for the first time in sprint review. The map isn’t about bureaucracy. It’s about making the invisible infrastructure of your product visible enough to manage deliberately.
For your organization: Most stakeholder misalignment in product organizations isn’t caused by bad intentions — it’s caused by people who were never asked. A quarterly refresh habit — even a lightweight one — significantly reduces the probability of a launch derailed by a stakeholder who was overlooked, a priority reversed by someone who wasn’t briefed, or a decision undone because the wrong people were in the room. One map, updated regularly, is one of the cheapest forms of organizational risk management available to a PM.
Call to Action
Draw the grid today. Give yourself 30 minutes, and be honest about where you’ve been operating on outdated assumptions.
Then find the one missing voice — and send one message this week.
Doing this challenge? Share what you found on LinkedIn or X and tag it #MLAChallenge. The gap that surprised you most is usually the most worth naming out loud.
📝 A Roadmap Without “Why” Is a Backlog. AI Just Gave It the Name “Strategy”
Intro. Refusing to Accept Fake Roadmap Work
The roadmap in most companies is a fiction. And everyone knows it. PMs know it because they sit in meetings where priorities get changed with a single sentence. Designers know it because they do discovery whose results no one cares about. Developers know it because every quarter they build something no one will use. And yet nobody says this publicly, because admitting it looks like failure. The more I talk to people in the industry, the more I read, the more I observe, the clearer it becomes that this is not a problem of a few dysfunctional organizations. This is the state of the industry. Marty Cagan has been saying for years that most features on typical roadmaps don’t generate a positive return on investment. John Cutler coined the term “feature factory” in 2016. I’ve written about this dysfunction before in my newsletter. But 2025 and 2026 added a magic phrase to this story, one that cannot be questioned.
Two words are enough. “AI feature.” Drop them into any sentence at a prioritization meeting and the discussion ends. Not because the arguments are strong. Because in 2026 those two words have untouchable status. They’re hard to push back on, because pushback looks like resistance to progress. And so a phrase that was supposed to mean innovation started meaning a lack of discipline in saying “no.” This article is about what happens when a roadmap can be overturned by a single phrase, but it’s also about what a real roadmap should look like. In short: planned in cycles shorter than a year, based on written business hypotheses, with clear criteria for when it gets changed, and with trade-offs spelled out explicitly. Everything else is a backlog with a timeline, regardless of how nicely it’s named.
What a Roadmap Is (and What It Isn’t)
A roadmap, in the product sense, is not a list. It’s not a spreadsheet in Jira with a “Q3” column and an “AI features” checkbox. A roadmap is an organization’s commitment to specific problems it wants to solve in a specific timeframe, for specific customers, in a specific way. Every item has a “why,” not just a “what.” Every item has a trade-off spelled out explicitly and conditions under which it falls out of the plan. This is not my original theory, this is basic product hygiene that Cagan and many others have been describing for years. Any senior PM with a few years of experience would tell you the same thing if you asked them honestly, without witnesses. The problem is that nobody asks.
Operationally it looks like this. You plan in quarterly cycles, not annual ones, because in digital product nine months is an eternity and what made sense in January may be irrelevant by October. Before each cycle the team does discovery on hypotheses it’s considering for the next quarter. It checks whether the customer has the problem you’re assuming, whether they’ll pay for the solution, whether adoption will be sufficient to justify the cost. What passed the test enters the roadmap with a hypothesis, a success metric, and a deadline. What didn’t pass goes back to the ideas pool or gets abandoned. During the quarter things don’t change unless new evidence appears that shifts the calculus. Not “a competitor announced something,” but “our customer told us something that undermines our assumption.” These two situations are different, and organizations that don’t distinguish between them don’t have a roadmap. And here’s a certain irony. The product industry spent the last decade moving away from annual planning toward shorter cycles. That was progress. A quarter instead of a year, hypotheses instead of wishes, validation instead of guessing. And then all it took was someone saying “we need AI” at a meeting and all that discipline went in the trash. Ten years of work on a better process, overturned by two words.
What’s worse, even those shorter cycles turned out to be too short. Not because a quarter is too much. Because in an environment where every conference demo, every LinkedIn post, and every competitor move is treated as a reason for immediate course correction, three months of focus is an abstraction. Organizations that switched to quarterly planning were supposed to have three months to build what they planned. In practice they can’t last three weeks without throwing something new in. The cycle got shorter, but discipline within it didn’t grow. We shortened the planning horizon without raising the ability to stick to the plan.
A roadmap where you can ask “why is this item here” and not hear an answer is not a roadmap. It’s a backlog with a timeline. A roadmap that can be overturned by a single phrase is also not a roadmap, because a real one contains within itself the criteria for when it gets changed. A new business hypothesis, new evidence from the market, a new technical constraint. Those are criteria. “The competition launched AI” is not a criterion. It’s an impulse. So much for theory. The question is why almost nobody does this.
What It Actually Looks Like
How does roadmap work look in many organizations on a day-to-day basis? No ideals from books, no slides from conferences. What you see when you watch how people make product decisions Monday after Monday. You won’t see this on LinkedIn. There you get case studies, frameworks, and roadmaps that look like conference slides. The picture I’m assembling in this section comes from elsewhere: from hallway conversations with PMs and designers, from questions asked after presentations, from what people say when the camera is off. And from my own experience, where I watched product decisions being made not based on data, but based on the gut feeling of someone higher up the hierarchy. Nobody brags about this publicly. But when you dig into the topic, the pattern is the same. It’s confirmed even by companies that experiment better than anyone in the world. At Booking.com, according to Stuart Frisby, then Director of Design, 90 percent of tests don’t produce positive results. At Slack, Fareed Mosavat, Director of Product, says openly that only 30 percent of monetization experiments work out. These are organizations with a mature testing culture. Most companies in the industry don’t measure this at all, so they don’t even know how much of what they build doesn’t work.
Most organizations plan their roadmap once a year, at the very beginning. Which is itself a problem, because a plan made in January is already outdated by November. And yet this model persists, because the board likes having a document for the year that can be shown to investors. Within this annual fiction, things happen that are everyday reality. Sales comes back from a conversation with a big client, says “they need X or they won’t renew the contract,” nobody verifies whether the client will actually leave without X, the phrase “strategic client” is enough and the matter is closed. Meanwhile the CEO comes back from a conference, saw a demo, read on LinkedIn that it’s the future, the next day the product team has a new thing to build. No brief, no hypothesis, no context. And the retro that was supposed to be a place for course correction never changes priorities, only documents frustration. “We’ll get to it later” is a phrase of the same kind, and “later” never comes. Nobody talks about these things publicly, because each of them looks like a failure of the organization where it happens. And I’m arguing they’re not. Each of them is simply a portrait of an industry that never developed the discipline of saying “no.” AI didn’t change any of this. It just added something to it.
The Mechanisms of Overturning a Roadmap
What AI added to the wish list is a set of phrases you’ll hear in every company. Each of them sounds like strategy. None of them is.
“The competition already has it, we need to catch up”
This is the most common justification for shipping an AI feature in 2026, and the weakest of them all. Because it’s not a hypothesis, it’s imitation. A decision that assumes if someone else did something, we have to do it too. Without checking why they did it, whether it’s working for them, whether our customer would even use it. “Because the competition has it” is a phrase that exempts you from thinking. You just say it and the discussion about priorities ends, because “catching up” sounds like an obvious thing, and the obvious doesn’t require proof. Except the competition we “need to catch up with” often doesn’t know whether its AI feature works either. Maybe they built it in the exact mode we’re about to build ours in. Because someone else had something. This is a pyramid where everyone is catching up with someone who is themselves catching up with someone else. And nobody checks where this pyramid leads.
There’s an even worse version of this mistake. Some organizations, aware that “the competition has it” isn’t sufficient as justification, try to mask it with analysis. They check how the competition implemented the feature, whether the competitor’s customers are happy with it, what its impact on their business is. Sounds reasonable, but it’s a trap. If you copy the competition’s decision-making process, you also copy their mistakes without even knowing it. And if you spend weeks checking whether the competition was right, those are weeks you’re not spending on checking whether there’s a better move that would grow your product in a direction the competition doesn’t see. Time spent validating someone else’s decisions is time taken away from validating your own hypotheses. Every hour figuring out why they did it is an hour less figuring out what your customers need.
“AI changes everything”
This phrase gets used when you need justification for a decision you would have wanted to push through anyway. Changing the discovery process? AI changes everything. New way of prioritizing the roadmap? AI changes everything. Rebuilding the entire product pipeline mid-quarter? AI changes everything. “AI changes everything” is a universal pretext, and that’s why it means nothing, because a phrase you can use to justify any decision doesn’t justify any specific one. It’s not an argument, it’s a skeleton key. Its power comes from the fact that it’s hard to push back against, because nobody wants to come across as someone who “doesn’t understand the scale of change.” And yet. If AI truly changes everything, then why does the decision we’re making “because AI” usually not have a hypothesis underneath it that says what specifically will change.
“Customers are asking for AI”
In a depth interview a customer will say “yeah, it would be nice to have AI.” They’ll say it because you’re asking, and they want to be polite. They’ll say it because they don’t want to look behind the times. They’ll say it because at the conference everyone was talking about it. But “it would be nice” in an interview and “I’ll pay extra for this” during contract negotiations are two completely different things. An organization that reads “it would be nice” as a purchasing commitment is building product based on politeness. This is not research, it’s a projection of your own hopes onto customer responses. A good product manager knows the difference between declared interest and revealed preference. A customer who says “yes” and then doesn’t use it is not a customer who wanted it. They’re a customer who didn’t want to say no.
“AI is a fundamental expectation”
This is the most advanced form of the mechanism, because it doesn’t come from a single client or from the competition. It comes from the top. From the board, from investors, from C-level. “AI is our top priority this year.” And here’s a number that, in my opinion, says more about the state of the industry than any other. In 2025, 51 percent of product leaders declared that AI is a top priority from their C-level. In that same group, only 8 percent said AI is actually core to how they build and prioritize product. The data comes from the 2025 CPO Survey by Productboard. The mandate from the top exists in five out of ten organizations, integration into the way product is built exists in one out of twelve. This is exactly the definition of a pretext. If AI were truly a strategy and not a label, those two numbers would be closer together. A top priority from the top would have to translate into the way people work. It doesn’t. Top priority is a declaration, the way of working stays the same. 51 and 8. Remember those two numbers if you’re reading this and you feel like this is happening in your company too.
Discovery as Ritual
Time for specifics. An anecdote that’s been sitting with me for a long time. I saw this up close at one of the companies I worked at, but the truth is I saw the same pattern later in several other places, in conversations with PMs and designers from outside that company. I’ll tell one story, but this is not one story.
A B2B SaaS serving large enterprise clients. An AI-based feature meant to automate part of the user’s daily work. The competition had been using it for several months. We were supposed to “catch up.” I was the person responsible for part of the discovery. I talked to customers, collected data, tested hypotheses. Everything following the procedure the organization officially declared as its way of working.
The results gave three warning signals. In depth interviews customers said they “might use it,” not “we need this.” When we moved to legal matters and signing agreements, they pulled back. And when we talked about money, they said explicitly that this kind of feature should be part of the product they’re already paying for, not an extra option at an extra cost. Each of these signals individually should have given pause. All three together were a red light. Discovery gave an answer the organization didn’t order. They won’t buy. Or at least not the way the plan assumed.
We proposed an alternative, a cheaper and faster way to check whether customers would actually pay before we invest months of work. The decision was different. There’s no time for checking. There’s only time to build it, because the competition already has it, because the board said it’s a priority, because the quarterly plan says so. Every warning signal from discovery was treated as “interesting feedback for later consideration,” and later consideration never happened. The feature entered the roadmap alongside everything that was already in it. Nothing fell out. Nobody said “if we’re doing this, we’re not doing that.” The team that had been pulling one plan was suddenly pulling two, at the same time, with the same people. The roadmap wasn’t changed, it was stretched. The result was what you could have predicted. The feature didn’t meet customer expectations, adoption is low, customers treat it as something that should be part of the product but don’t want to pay extra for it, so for the organization it’s additional maintenance cost without revenue. And the roadmap it was written into is so tight there’s no time for fixes, because it’s already time to build the next thing the “competition has.” I don’t even know how this story ended, because I quit working in this model. I refuse to take responsibility for results that won’t be delivered if I don’t have a real ability to influence the process of checking whether what we’re building makes sense. I’m not going to pretend this is a brave stance, it’s simply the bare minimum of decency toward myself and toward customers who pay for the product.
And here I want to say one thing directly, because this is the heart of this story. Discovery was done. For real. People talked to customers, collected data, wrote notes. From the outside the organization looked like a place that works “by the book.” But the conclusions from discovery had no impact on the decision, because the decision had already been made. Discovery was a costume. A ritual that allowed the organization to say “we did research,” even though the research said something the organization didn’t want to hear. What’s worse, in many organizations discovery happens not before the decision, but in parallel with building. The team is already building while the researcher talks to customers, so it can be documented that “we checked.” Discovery whose results can be ignored when they don’t fit a decision already made is not discovery, it’s theater. And it’s far worse than no discovery at all, because no discovery is at least honest.
The Industry’s History of Dysfunction
You might think that what I described above is a 2025 invention, that AI created this problem. It didn’t. Cagan has been writing about 10 to 20 percent of features delivering ROI since the Silicon Valley Product Group has existed, which is since 2009. We have over a decade of documentation that roadmaps in most companies are badly constructed. And nobody publicly cared until AI started dramatizing it. Numbers from that era confirm the same thing. In 2023, the ProductPlan State of Product Management survey, a study of over fifteen hundred respondents, showed that 70 percent of roadmaps most influenced by senior leadership focus on outputs, not outcomes. Meaning even then, before the AI boom, most companies were building features for the sake of features, and the roadmap was a list of things to deliver, not a framework for deciding which problems to solve. Newer data says the same thing. In the State of Product Management 2026, nearly half of product managers indicate that their priorities shift under short-term pressure, and almost as many complain about resource shortages. I wrote about these numbers in one of my previous articles. The problem was documented long before ChatGPT appeared in the titles of board presentations, and it didn’t go away just because a new buzzword showed up. AI just poured fuel on it.
This is the place where we need to name one assumption this article makes very explicitly. AI didn’t overturn anything that was standing firmly. AI exposed what had been wobbling for a long time. Organizations that had a real roadmap had and still have ways to assess whether an AI feature fits their strategy. They have a hypothesis, they have criteria, they have a trade-off. These organizations are in the minority, but they exist. The rest, meaning the majority that AI “overturned,” had a backlog of whims all along. AI just added a new category of whims, more contagious than the previous ones. The language changed. Before, we shipped because “the client asked,” “the competition has it,” or “the CEO wants it.” Now we ship because “we need to have AI.” The words changed. The mechanism stayed the same.
But there is one difference. Before, when someone pushed a feature “because the client asked” or “because the CEO wants it,” you could say “no” without the risk of coming across as someone who doesn’t understand the world. The refusal was about a specific thing. Now the refusal is about a category. Saying “no” to an AI feature sounds like saying “no” to artificial intelligence as such. And this is why this new category of whims is more contagious than all the previous ones. Not because AI is more important than what came before. Because opposition to AI looks like opposition to progress. And in an industry that lives on being at the forefront of change, that’s a position very few people can afford.
And here the question returns that usually gets lost in this conversation. What happens to everything the organization had previously planned when suddenly “everything is changed by AI” and the roadmap gets overturned? From my experience the answer looks like this. Nothing. Old priorities stay in the roadmap as items alongside new ones, because nobody has the courage to say “what we planned in January no longer makes sense, we’re cutting it.” Instead, AI features get added to the same plan, as if the team’s resources were unlimited. A quarterly plan that was already ambitious gets additional weight. A sack that looks bottomless to everyone gets another layer, and the number of people on the team stays the same.
Where All of This Leads
What I described above is not my opinion. It’s a state of affairs confirmed by data, anecdotes, and every honest hallway conversation in this industry. Publicly everyone nods that the roadmap is strategic, that discovery matters, that decisions are data-driven. Privately they say something different. And this state has concrete costs. Not just in product, because I’ve already shown that with a specific example. Above all in people.
A product designer, a product manager, a researcher who see that their discovery was ignored learn one of two things. Either cynicism, meaning they start doing discovery to document compliance with procedure, not to influence a decision. Or burnout, meaning they mentally check out, do exactly enough not to get fired, and stop fighting for quality of work. People who learn cynicism stay and destroy the culture. People who burn out leave. And a junior entering such an organization in 2026 learns that this is simply how it works. That “AI feature” is sufficient justification, that discovery is a ritual, that the roadmap is a list to deliver, not a strategy to justify. In five years those are your seniors. In ten years those are your heads of product, reproducing the patterns they were raised in. Standards drop, they don’t rise.
And here’s a question almost nobody asks. Can our industry even afford people who say “no”? Because on one hand every organization declares it wants people with opinions, with a backbone, with the ability to push back. On the other hand, when such a person actually says “no, this feature doesn’t make sense, the data doesn’t support it,” they’re treated as inconvenient. As someone who blocks progress. As someone who “isn’t a team player.” An industry that on one hand complains about a lack of senior talent and on the other hand systematically discourages people from speaking openly has exactly the people it deserves.
But all of this leads to one more thing, the most insidious one: the very way decisions are made. Before AI entered the conversation, in many organizations product decisions were made by one person based on gut feeling. “I know we need to do this, I know this market.” Not a hypothesis. Not data. The gut feeling of someone sitting high enough that nobody asks “how do you know.” And the entire team followed that gut feeling, because questioning it looked like questioning authority. Hundreds of hours of work, a quarter’s budget, the product’s direction, all based on one person “feeling” the market. No success criterion, no trade-off, no condition for when to pull back. This mechanism was absurd from the start, but at least it had one advantage: it had an author. You could go to that person and say “your gut feeling didn’t pan out, the data says otherwise.” A hard conversation, but a possible one.
AI took even that possibility away. Now you don’t need a gut feeling, you just invoke “the direction of the market.” “We know we need an AI feature” works the same way as “I know we need to do this,” except it’s even harder to challenge, because it seemingly doesn’t come from a specific person. A decision based on gut feeling is at least locatable. A decision based on “we need to have AI” is impersonal, therefore beyond discussion. And this is the most dangerous part, because it destroys the very process of asking questions. If a decision has no author, nobody is accountable for it, and if nobody is accountable for it, nobody learns to question it.
Where to Start
It’s easy to read everything I wrote above and conclude “it’s the same where I work.” It’s harder to answer what to do about it. Because the answer depends on where your organization is. There’s no single recipe. An organization that doesn’t have a discovery process needs something completely different than an organization that has one but ignores it. Below are three states you might recognize yourself in. Each requires a different first step.
You don’t have the fundamentals. There’s no discovery process, no written criteria for what enters the roadmap or falls out of it. Decisions are made in meetings, driven by whoever speaks loudest or sits highest. The roadmap exists as a document, but not as a decision-making tool. If this is your state, don’t start with business hypotheses or prioritization frameworks. That’s too far. Start with one thing: establish who in your organization makes decisions about what enters the plan, and on what basis. Write it down. Not as a manifesto, as a fact. “Roadmap decisions are made by X based on Y.” If you can’t finish that sentence, you have the answer to why the roadmap doesn’t work. Until you know who decides and on what basis, everything else (discovery, hypotheses, metrics) is decoration.
You have a process, but it has no teeth. Discovery happens. People talk to customers, collect data, write reports. But the results of discovery have no decision-making power. If they fit the decision already made, they go into the slides. If they don’t fit, they’re “interesting feedback for later consideration.” This is exactly the state I described in the anecdote. If this is your state, the problem isn’t in the discovery process, it’s in its connection to the decision. Discovery needs one right that most organizations don’t give it: the right to kill a feature. If the result of discovery says “customers won’t buy this,” that has to be a sufficient reason for the feature not to enter the roadmap. Not “feedback for consideration.” Not “we’ll take it into account.” A specific condition: if discovery doesn’t confirm the hypothesis, the item falls out of the plan. Written, agreed upon with decision-makers, enforced. Without that, discovery is a ritual, not a tool.
You have discipline, but AI is testing it. Your organization has a process. Has criteria. Has discovery that actually influences decisions. But then someone says “we need AI” and suddenly the same criteria that applied to every other feature stop applying. If this is your state, the answer is simpler than in the two previous cases, but it requires courage. An AI feature is a feature. Treat it like any other. Hypothesis, trade-off, success criterion, criterion for change. If someone proposes an AI feature without a hypothesis, the answer is the same as for any other feature without a hypothesis: “show me what problem this solves and for whom.” The fact that it’s AI doesn’t change the question. It only changes how hard it is to ask it.
Each of these three states requires something different. An organization without fundamentals doesn’t need a better framework, it needs clarity on who decides. An organization with toothless discovery doesn’t need more research, it needs to connect research to decisions. An organization with discipline that cracks under AI pressure doesn’t need a new process, it needs the courage to apply the one it already has. There are no shortcuts. But there is one common point. Before you even start planning a roadmap, answer whether you have something to plan from. Whether you have a discovery process. Whether you have tools for collecting and analyzing data. Whether you have people you allow to say “no.” Without that, a roadmap is a document, not a strategy. And no framework will change that.
To Close
The data I cited in this text are not cherry-picked statistics. They form a coherent picture of an industry where most organizations don’t have the tools to manage themselves any way other than by impulse. AI didn’t break this industry. AI just gave it a new toy it can use to cover up what hasn’t been working for a long time.
I care about one thing. That building digital product has a strategy. That it has established priorities. That decisions about what we build come from something more than a new toy that showed up last quarter. Because that’s what it looks like now. We get a new tool and adjust everything to fit it, instead of asking whether the tool even fits what we’re building.
I described three states your organization might be in, and a first step for each. But organizations are different, and what works in one may not work in another. So I have a request. If you have experience introducing discipline into a roadmap, if you managed to build a process that survived the pressure of the next buzzword, share it in the comments. Not because I want to build a community or engagement. Because the more practical approaches are in one place, the greater the chance someone will find a way that fits their organization. It may not fit yours. But maybe a reader who shares their approach will hit the core of your problem.
A roadmap without “why” is a backlog. AI just gave it the name “strategy.” And as long as we accept this state as normal, we’ll keep building products nobody wants, on deadlines that can’t be met, with money we won’t earn.
📝 When a Team Starts Doing Scrum Perfectly: On the Signals of the Italian Strike in Product Work
A Scrum Master’s Perspective
The Perfect Team That Worried Its Scrum Master
Bartek had been working with his product team for two years. Six people, mixed development plus testing, one in-house Product Owner, two designers shared with another team. A standard configuration in a mid-size Polish software house. For the first eighteen months, things went in cycles — some great sprints, some disasters, two retrospectives where someone walked out angry. Normal team reality.
Three months ago, something changed. But in a way Bartek couldn’t immediately name. The team started arriving on time for Daily. Every single person. Every single day. No exceptions. Everyone spoke in turn using the classic three-sentence formula. Refinement began ending in two hours instead of two and a half. Sprint Planning was uncontested — the team simply took the stories the Product Owner proposed, estimated them together, accepted the Sprint Goal. Definition of Done was respected meticulously. Documentation was updated. Everything worked.
The director of product, Łukasz, said at the internal all-hands that this was “the best-functioning team in the company” and set them up as a model. The Product Owner, Ania, was writing a quarterly report highlighting the team’s high process maturity. Only Bartek had a strange feeling he couldn’t articulate. He looked at Daily and saw
Continue reading this post for free, courtesy of Destare Foundation.
