Andrea Bronzini, a seasoned expert in experimentation and conversion optimization, shares insights on the limitations of traditional A/B testing frameworks, the impact of noise on experiment results, and introduces innovative tools to improve decision-making in product growth.

Key topics

• Limitations of traditional A/B testing frameworks

• Impact of…

Read more

Brought to you by ExecReps.ai — AI-powered executive presence coaching for teams.

I pull out the DIKW Pyramid all the time. Data, Information, Knowledge, Wisdom. Four layers. I use it in conversations with PMs, in strategy workshops, in podcast episodes. I used it on air with Weiwei Hu when we talked about making analytics actionable, and again with Val Coin when we explored executive dashboards. It keeps showing up because it keeps being true.

These writers are product practitioners who have built, measured, and sometimes been burned by metrics in real organisations. They are writing from the trenches, not the textbook. Their work on Product Coalition captures the messy reality of what happens when you try to make numbers mean something.

Here is the framework in plain terms. Data is the raw number: 38. Information adds context: 38°C. Knowledge applies experience: that is a mild fever. Wisdom makes the call: take medication, cancel the meetings, rest. Most product teams I talk to are brilliant at collecting data and pretty good at turning it into information. Dashboards everywhere, charts in every meeting, weekly reports that nobody misses. But climbing from information to knowledge, and then from knowledge to wisdom, is where almost everyone gets stuck.

I have watched this play out across 12 years of running Product Coalition. The industry got so good at capturing numbers that we forgot why we were capturing them. As Weiwei Hu put it on the podcast: "98% of the time, the data's probably there. The analytics team did its job, but the insight never makes it into an actual decision. It stays trapped in a report that nobody reads or a dashboard that looks impressive in a meeting, but changes nothing afterwards."

That is the gap. Not a data gap. A wisdom gap.

The Data Layer: Measuring Everything, Understanding Nothing

Start at the bottom of the pyramid. Data is raw, unprocessed, context-free. A number in a cell. Product teams are drowning in it. The tools have never been better at collecting every click, scroll, hover, and abandonment. The problem is not access. The problem is that raw data creates a false sense of progress.

Ant Murphy nails this in Four Frameworks to Help You Define Product Metrics. He writes, "You can find numerous articles out there that will rattle off a list of essential e-commerce metrics or metrics for startup PMs however the universal problem with these types of articles are that you end up tracking metrics without fully understanding why or how they interplay and impact your product." His vegetable garden analogy is perfect. Measuring soil humidity and counting sprouts are leading indicators. If you are focused on the harvest when the plant is a seedling, you are going to get frustrated and stop watering the soil.

Murphy reminds us that "Every product, company, situation is different." There is no universal metric set. The data layer is necessary but it is not sufficient. It is the 38 without the °C.

The Information Layer: Context Without Consequence

One level up. Information is data that has been processed and organised. It answers who, what, where, and when. This is where most product teams live permanently. The dashboards, the weekly reports, the retention curves, the funnel charts. Information feels productive. It looks impressive in a meeting. It rarely changes anything.

Elena Seregina captures the specific feeling of dread that lives here in Metrics Hierarchy and Metrics Pyramid: Aligning Product and Business Goals. She writes, "Our business metrics were rising. But as we were cracking a bottle to celebrate, the metrics suddenly dropped." Classic information-layer trap. The top line looked great. The foundation was rotting. She argues that "On average, product leaders start building the hierarchy of metrics after a year of trying to tame the user data." A full year of drowning before you realise you need a map.

Weiwei described this beautifully on the podcast: "A lot of companies have a ton of data dashboards and reports. And now with AI, the ability to summarize from the data and to be able to generate information is very easy. But what I see is leaders and executives still struggle to decide what to do next." The information is everywhere. The decisions are nowhere.

The Knowledge Layer: Where Experience Meets the Numbers

This is where the pyramid gets steep. Knowledge is the application of information combined with experience, context, and critical thinking. It answers "How?" Most analytics teams never get here because they are too busy servicing the layers below.

Ally Mexicotte pushes into this territory in The Only Leading Metric to Measure Product-Market Fit and How to Use It. She brings up the Sean Ellis 40 percent rule: "if 40% or more of your users would be very disappointed if they could no longer use your product, then you've achieved product-market fit." That is not just information. That is knowledge. It takes a specific data point and applies a framework born from experience to make it actionable. But here is the part that requires real knowledge: Mexicotte explains that the people you should be listening to are not the ones who love everything or hate everything. It is the ones who would be "somewhat disappointed and whose main benefit was aligned to the core value proposition." The middle ground is where the work happens. You need experience to know that.

I said something on the podcast with Weiwei that I still believe: "When I think about the world pre-AI, most businesses when it comes to that analytics function had the data, could turn that into information, if they were invested in analytics teams or technologies they could acquire knowledge, but wisdom was left only to the human." The knowledge layer is where humans have always added the most value. AI is compressing the layers below it, which means the knowledge layer is now the minimum bar, not the aspiration.

Weiwei's response reinforced this: "The value for analytics actually will move away from pure execution to knowledge, insights, and judgment. Deciding whether a certain data signal or pattern really matters for a certain outcome, whether the result is trustworthy, even if it's generated by AI."

The Wisdom Layer: Judgment, Foresight, and the Courage to Ignore a Number

The top of the pyramid. Wisdom is the ability to use knowledge with judgment, foresight, and values to make sound decisions. It answers "Why?" and "What is best?" This is where you look at a metric and decide to ignore it. Not because you do not understand it, but because you understand it so deeply that you know it is the wrong signal for this moment.

John Utz writes about the seduction that keeps teams from reaching this layer in From Vanity Metrics to Actionable Insights: A Product Manager's Guide. He admits, "I've been enchanted by vanity." He warns that "vanity metrics can lure you in. They give you a dopamine hit, a surge of pleasure-inducing neurotransmitters in your brain." That dopamine hit is what keeps us trapped in the information layer. We want the chart that goes up and to the right, even if it has nothing to do with the health of the business. He cites Fab, which focused on user growth and ignored retention. Eric Ries said it plainly: "Vanity metrics may make you feel good, but they don't offer clear guidance for what to do next."

Wisdom is the test I use now. If I look at a number and I do not know what I am going to change or stop doing because of it, I delete it. That is not analytics. That is judgment. And it is the hardest thing in product to teach.

Weiwei told a story on the podcast that perfectly illustrates the gap between knowledge and wisdom. One of her team members built a price elasticity model in Databricks in just a few minutes using AI. "The model sounds really sophisticated and impressive. And then the same person came back to me the next day and say, I looked at the results, but it's completely wrong. It just sounds so confident and I almost believe it's correct, but it's just making, pulling these assumptions by itself without even asking me if this is the right assumption." The AI had data, information, and even a form of knowledge. What it lacked was wisdom: the judgment to know when its own assumptions were wrong.

Val Coin said it on another episode: "The data itself isn't sufficient. We need to understand what question is that data answering? What story is that data telling us and what does it allow us to do?" That is the wisdom question. Not what does the number say, but what does the number allow us to do next?

Climbing the Pyramid

The DIKW framework is not new. It has been around for decades. But it has never been more relevant than right now, because AI is collapsing the bottom two layers. Data collection is automated. Information generation is instant. AI can build a dashboard in seconds, write a summary in milliseconds, spot a pattern before a human has finished their coffee.

That means the competitive advantage has moved up the pyramid. The teams that win are the ones that can climb to knowledge and wisdom faster than their competitors. Not by collecting more data. Not by building more dashboards. By having the experience, the context, and the courage to make the call.

Weiwei put it best: "The best analytics teams are not just reporting or measuring or monitoring what happened. They are really the ones who help define and influence what should happen next."

When you look at your own product dashboards tomorrow morning, ask yourself honestly: which layer of the pyramid are you operating on? Are you collecting data, organising information, applying knowledge, or exercising wisdom? And if the answer is not wisdom, what would it take to climb one level higher?

These writers are the reason Product Coalition has been the home of real product thinking for 12 years. Ant Murphy's vegetable garden analogy for leading indicators, Elena Seregina's hierarchy that forces you to look at the whole house, Ally Mexicotte's reframe of who you should actually listen to, John Utz's honest confession about vanity. This is not content. This is craft from practitioners who have earned the right to teach it by doing the work first.

Sources

- Murphy, Ant. "Four Frameworks to Help You Define Product Metrics." Product Coalition on Medium.

- Seregina, Elena. "Metrics Hierarchy and Metrics Pyramid: Aligning Product and Business Goals." Product Coalition on Medium.

- Mexicotte, Ally. "The Only Leading Metric to Measure Product-Market Fit and How to Use It." Product Coalition on Medium.

- Utz, John. "From Vanity Metrics to Actionable Insights: A Product Manager's Guide." Product Coalition on Medium.

- Product Coalition Podcast. "EP103: From Data to Decisions — Making Analytics Actionable with AI" with Weiwei Hu.

- Product Coalition Podcast. "EP100: Operational Clarity — How to Make Digital Change Visible, Measurable & Scalable" with Val Coin.

- Ellis, Sean. "The Sean Ellis Test." Referenced via Mexicotte.

- Ries, Eric. The Lean Startup. Referenced via Utz.

👋 Jay

Brought to you by ExecReps.ai — AI-powered executive presence coaching for teams.

Everyone celebrates the pivot. Airbnb pivoted from air mattresses. Slack pivoted from a gaming company. Brex joined Y Combinator as a VR startup and left as a credit card company.

The writers behind this newsletter are product practitioners who’ve lived through pivots, rebuilds, and the uncomfortable silence that follows when a roadmap gets torn up. They write from the mess, not the post-mortem — and that’s what makes this community worth showing up for.

What nobody puts in the case study is the invoice. Not the engineering hours or the sunk development costs — those are obvious. I mean the other bill. The one that shows up in eroded customer trust, reset acquisition funnels, fractured team morale, and the six months of strategic drift that follows every major direction change.

93% of successful startups pivoted from their initial ideas. That statistic gets quoted like a permission slip. But here’s the part that doesn’t make it into the LinkedIn posts: startups that pivot more than twice perform significantly worse than those that pivot once or twice. The Startup Genome Project found that companies with one to two pivots saw 3.6x better user growth and raised 2.5x more capital than those with zero pivots or more than two.

The pivot isn’t free. It never was. And in the current environment, where profitability has replaced growth-at-all-costs as the default operating mandate, every direction change carries a heavier price tag than it did five years ago.

The Five Hidden Costs Nobody Budgets For

1. The Customer Acquisition Reset

This is the biggest line item nobody puts on the spreadsheet. Every pivot resets your customer acquisition engine. The positioning you spent months refining? Gone. The messaging that finally started converting? Irrelevant. The sales playbook your team just memorised? Scrap it.

As CFO Pro Analytics put it bluntly: “The lean startup framework treated the pivot as essentially costless on the customer side. Sunk costs in product development were acknowledged and written off. The team redeployed. The next experiment began. What was never written off, because it was rarely measured properly, was the customer acquisition cost embedded in the failed experiment.”

AI has made this worse, not better. Building is cheaper than ever, which means the temptation to pivot is higher. But customer acquisition remains expensive and competitive. Testing multiple products in series multiplies CAC without compounding the relationship equity that makes acquisition efficient over time.

2. The Team Morale Drain

I’ve watched this one up close. A pivot announcement lands in an all-hands meeting, and for about 48 hours the energy is high. New direction! Fresh start! Then reality settles in.

The engineers who spent three months building the feature that just got killed? They’re doing the mental arithmetic on whether this new direction will survive long enough to ship. The designer who just finished a complete design system? She’s wondering why she should invest the same effort again. Your best people don’t leave immediately. They leave three months later, quietly, after the second pivot makes them feel like their work doesn’t matter.

The Startup Genome Project found that startups need 2-3x longer to validate their market than founders expect. That gap between expectation and reality is where team morale goes to die.

3. The Trust Erosion With Existing Customers

Nicole Segerer, General Manager at Revenera and a guest on the podcast, put the monetisation version of this problem perfectly: when companies implement changes too quickly without having the right data and without a solid strategy, the model goes wrong. “And when that goes wrong, you have a customer satisfaction issue, and you never want to have that. And then you’ve got to retract and change your pricing models, and that erodes trust.”

The trust tax compounds. Customers who lived through your first pivot give you a shorter leash on the second. Enterprise buyers start adding break clauses to contracts. Your NPS score doesn’t just dip, it develops a structural ceiling. And in B2B, where relationships are the acquisition channel, that ceiling becomes a revenue ceiling.

4. The Opportunity Cost Nobody Calculates

Every pivot is a bet that the new direction is worth more than the old one. That’s rational. What’s not rational is ignoring what you stop doing when you change direction.

Dan Balcauski, founder of Product Tranquility and a pricing expert who appeared on the podcast, captured a parallel truth about product decisions: “Most tech companies obsess over acquiring customers, but really neglect how they capture value.” The same logic applies to pivots. Companies obsess over the new direction but neglect to account for the value they’re walking away from.

That half-built feature that was three weeks from shipping? The partnership that was two meetings from signing? The customer segment that was just starting to convert? These aren’t sunk costs. They’re abandoned upside. And nobody puts abandoned upside on a pivot spreadsheet.

5. The Technical Debt Reset

This one is insidious because it’s invisible for months. A pivot doesn’t just change what you’re building. It changes the relevance of everything you’ve already built. Database schemas designed for one use case become structural constraints for another. APIs built for one integration pattern need rebuilding. The monitoring and alerting you set up for the old product? Useless for the new one.

Dave West, CEO of Scrum.org and a guest on the podcast, has spent years advocating for incremental delivery precisely because it reduces this kind of waste. His model is built around “making small bets” — the idea that teams should incrementally deliver, learn, and adapt rather than making massive directional bets that require equally massive unwinding when they don’t work.

What I Am Hearing on the Podcast

The pivot conversation keeps surfacing across episodes, even when the topic isn’t explicitly about pivoting.

Dave West described his philosophy on the podcast: “Making small bets, the ideas of making things transparent, backlogs, having clear goals, product goals, sprint goals, bringing teams together to own both the process and the product — those ideas, I would like everybody to practice.” The subtext is clear: if you’re making small bets, you never have to make the expensive big pivot. You course-correct incrementally.

Dan Balcauski offered a lens that applies directly to the pivot question. He observed that “one of the things that a lot of companies just miss is they don’t have any governance at all around pricing” — and the same is true of strategic direction changes. Companies that lack governance around pivots end up with what he described: “The CEO comes in and yells at everyone because there’s a pricing problem and everyone kind of sheepishly looks around the room... nothing ever changes.”

Nicole Segerer highlighted the profitability blind spot: “80% of companies will have launched some sort of AI functionality. But when you really go deeper and you look at, okay, are customers using this? And is it something that carries some value that people would actually pay for? That creates a whole different picture.” Launching something new, whether it’s a pivot or a feature, without validating that customers will actually pay for it, is the most expensive experiment you can run.

The Pivot Decision Framework

So when should you actually pivot? Shubhi Nigam, writing for Mind the Product, outlined a framework that deserves more attention than it gets:

1. Usage: Are your metrics in sustained decline? Not a bad quarter. A structural trend.

2. Vision: Does the product no longer align with where the company needs to go?

3. Viability: Can you ever make money on this product?

4. Exhausted options: Have you genuinely tried everything, or are you pivoting to avoid doing the hard work?

That last question is the one most teams skip. Dalton Caldwell from Y Combinator nailed it: “Do not run away from doing the hard work. Sometimes you see people where they build a product, and right when it gets to sales time, they pivot, and they do that over and over again.”

The pivot is not the problem. The problem is pivoting without accounting for the full cost. Before you change direction, add up the real invoice: the CAC reset, the team morale drain, the customer trust erosion, the opportunity cost, and the technical debt reset. If the new direction is still worth it after that honest accounting, then pivot with conviction. If not, the cheaper move might be to stay the course and do the hard work you’ve been avoiding.

What the writers in this community keep proving, issue after issue, is that the messy middle is where the real product work happens. Not in the pivot announcement. Not in the “we’ve found product-market fit” press release. In the daily grind of shipping, measuring, listening, and adjusting by degrees. These writers are doing the work. This newsletter exists because of them.

Sources

Startup Failure Rate Statistics — flair

Startup Genome Project — Startup Genome

The Hidden Cost of the Pivot — CFO Pro Analytics

State of Product 2026 — Atlassian

To Pivot or to Not — Mind the Product

All About Pivoting — Y Combinator

Startup Failure Rate: How Many Startups Fail and Why — Failory

👋 Jay

👉 If you're not a subscriber yet, subscribe here so you don't miss the next issue.

Product Coalition writers have been mapping this fault line for years, from multiple continents and across company sizes most analysts never bother to study. Ron A, Pulkit Agrawal, Clayton Tarics, Chris Miles, Jon Matheson, Navneet Maheshwari, and Product Dave bring practitioner-level clarity to a debate that the conference circuit keeps oversimplifying. What follows owes everything to their fieldwork.

I sat in an advisory session last month watching a founder try to explain his software to a potential buyer. He stumbled through technical specs for ten minutes while the buyer stared blankly. It was a painful reminder of what happens when the person holding the microphone cannot tell a story that lands.

That scene is playing out across thousands of product organisations right now. Not because people lack talent, but because nobody can agree on whose job the story actually is.

The divide between the product manager and the product marketing manager started as a practical split. It has since become a philosophical one. And if the last decade of restructurings, layoffs, and AI tooling has taught me anything, it is this: the question is no longer "PM or PMM?" The question is whether the story even survives the divorce.

Era 1: One Person Did Everything (1930s–2000)

The product manager role did not begin in Silicon Valley. It started at Procter & Gamble in 1931, when a junior executive named Neil McElroy wrote a now-famous three-page memo arguing that each brand needed a dedicated "brand man" who would own the product, the positioning, the advertising, and the relationship with the consumer.

For decades, one person did it all. The brand manager was the strategist, the storyteller, and the commercial owner. There was no divorce because there was no marriage to dissolve.

Dan Balcauski, founder of Product Tranquility, made this point when he joined me on the podcast: "Product management has only existed as a function for 30, 40 years at most, borrowed from the CPG companies, the brand management companies, brand managers." The role was born whole, and it stayed whole for a remarkably long time.

When software companies began adapting the brand management model in the 1980s and 1990s, the PM inherited the same broad mandate: understand the market, build the right thing, and tell the story that makes people care. In an era of packaged software and annual release cycles, one person could realistically hold all three threads.

Era 2: The Great Specialisation (2000–2015)

Then SaaS changed everything.

Continuous deployment, freemium acquisition funnels, self-serve onboarding, and always-on analytics created a volume of work that no single role could absorb. The PM was pulled deeper into engineering sprints, API roadmaps, and backlog grooming. The story, the positioning, the launch, the competitive intelligence, all of it needed a dedicated home.

Enter the Product Marketing Manager.

Ron A captures the confusion of this era perfectly in What Does a PMM Do? It Depends: "A Product Marketing Manager is one of the least understood roles in the technology industry." He explains that "the role of the PMM can vary dramatically between companies," sometimes sitting under marketing, sometimes under product, and sometimes reporting directly to a founder who is not entirely sure what they hired.

Pulkit Agrawal went a step further and tried to pin down the role empirically. In What is Product Marketing? A Data-Backed Definition, he crawled more than 40 job descriptions and concluded that "a Product Marketing Manager plays a critical role in a company's success by connecting the dots between a product and its market." Three areas kept surfacing across nearly every listing: product launch strategy, customer engagement, and competitive analysis.

The specialisation made sense on paper. The PM would own the "what" and "why." The PMM would own the "who hears about it" and "how it lands." But in practice, the split introduced a new problem: nobody could agree where one role ended and the other began.

Chris Miles mapped this fragmentation in What Is Each Flavour of Product Manager Responsible For?, identifying four distinct PM quadrants, each with different levels of overlap with marketing. A Growth PM lives almost entirely in acquisition and retention metrics. A Technical PM barely touches the customer narrative at all. Multiply that by the PMM variants (Launch PMM, Competitive Intel PMM, Enablement PMM) and you have a Venn diagram that looks more like a Jackson Pollock.

The result? Go-to-market became a relay race where the baton kept hitting the floor.

Era 3: The Merge Heard Round the Valley (2016–2023)

By 2023, the backlash had arrived in full force.

Brian Chesky at Airbnb made headlines by flattening the PM function entirely, pulling product managers out of their traditional role and centralising design-led decision-making under creative leadership. It was controversial, polarising, and, for a lot of working PMs, terrifying.

Product Dave pushed back directly in No, Airbnb Is Not Killing the Product Function, arguing that what Chesky did was specific to Airbnb's culture and scale, not a universal playbook. The product function was evolving, not dying. But the signal was clear: senior leadership was losing patience with a system that had created more handoffs than outcomes.

At the same time, a quieter movement was happening inside mid-size companies. Teams were realising that the PM who could not tell a commercial story was stuck in a backlog, and the PMM who could not read a roadmap was stuck in a slide deck. The most effective practitioners were the ones who refused to stay in their lane.

Jon Matheson captured this perfectly in The Commercial Side of Product: What I Learned the Hard Way: "I thought building a great product was enough. I was wrong." His confession reads like a warning label for every PM who has ever shipped a technically brilliant feature that nobody bought.

Dan Balcauski put a finer point on the ownership question when I asked him who should own pricing: "My advice is product marketing should own it. I believe that pricing is a function of positioning. And so usually product marketing is at least the keeper of positioning in the organisation." But he added a caveat that every PM should hear: "Product management tends to have a little bit too much on their plate to also rigorously own pricing, but they're definitely a key stakeholder at the table."

Nicole Segerer, General Manager at Revenera, echoed the same tension from the commercial side on the podcast: "It is a topic that everyone would like to have a say and have an opinion in. But as you say, no one really wants to own it." She went on to describe the failure mode: product teams that build pricing strategies in isolation, only to have the CFO veto them at the last minute because nobody got executive buy-in early enough.

The era of the merge was not about eliminating roles. It was about acknowledging that the split had created a governance vacuum. Someone needed to own the narrative end-to-end, and the org chart was not going to solve it.

Era 4: AI Rewrites the Job Description (2024–Present)

And then AI arrived, and the question of "who owns the story" became something else entirely: "does anyone need to?"

Generative AI can now draft positioning documents, write launch copy, analyse competitive landscapes, summarise customer calls, and generate go-to-market briefs in minutes. The mechanical outputs that once justified the PMM headcount, and padded the PM's workload, are increasingly handled by tools.

Clayton Tarics anticipated this shift in Strategy Storytelling: The Product Narrative Canvas, where he argued that "the magic formula for high-impact product strategy presentation is to utilise a [product narrative] + [system of stories] approach." His point was that the value is not in the document. It is in the thinking. "A narrative is a contextual container for a system of stories," he wrote, and no AI tool is building that container on its own. Not yet, anyway.

Navneet Maheshwari's GTM Strategy template makes a similar argument from the execution side: "A GTM strategy is the plan that a company puts in place to bring a product to market." The template is only useful if a human has done the hard thinking about customer segments, value propositions, and channel strategy. AI can fill in boxes. It cannot decide which boxes matter.

So where does that leave us?

The PM who refuses to think commercially is a backlog administrator. The PMM who cannot influence the roadmap is a PowerPoint artist. And the AI that does both is still a tool looking for a strategist to point it in the right direction.

The practitioners who will thrive in this era are the ones who treat the PM-PMM boundary as a collaboration surface, not a property line. They are the ones who understand that the story is not an afterthought bolted onto a feature release. It is the product. It always has been.

What I Am Hearing on the Podcast

Dan Balcauski (EP83) told a joke that was not really a joke: "A CMO, a CRO, and a CPO all walk into a boardroom. Who's accountable for pricing? Well, it's always the CEO. The CEO is responsible for everything." His point was that the absence of explicit governance around pricing, and by extension around the narrative, creates a vacuum that defaults upward. If nobody owns the story, the CEO ends up telling it, and they are usually the least close to the customer.

Nicole Segerer (EP93) reinforced this from the commercial side: "Build a good team, bring the right people together, always make sure that sales and channel are part of the discussion, and then let's make sure that there is executive sponsorship." The teams that get this right are not arguing about whether the PM or the PMM writes the positioning doc. They are sitting in the same room, with the same data, building the same narrative.

I keep coming back to that founder. He had possibly the best product in his category. He had the data to prove it. And he lost the deal because nobody had helped him turn the specs into a story.

That is the cost of the divorce. Not the org chart reshuffling. The real cost is the silence where a narrative should be.

The PM and the PMM do not need to merge back into one role. They need to stop treating the story like a baton to be passed and start treating it like a fire to be tended. Together.

What are you seeing on your team? Has the PM-PMM boundary helped or hurt the way your product reaches the market? I would love to hear from the messy middle.

These writers are doing the real work. Ron A mapped a role that most job descriptions still get wrong. Pulkit Agrawal brought data to a debate drowning in opinion. Chris Miles showed us that the PM role itself has fractured into at least four distinct flavours, each with its own relationship to the market. Clayton Tarics built a canvas that forces strategists to think about narrative before they think about features. Navneet Maheshwari gave teams a template that turns vague GTM ambitions into actionable plans. Jon Matheson admitted out loud what most PMs only whisper to themselves: that building a great product was never enough. And Product Dave kept the conversation honest when the industry wanted to panic about Airbnb. This is what Product Coalition exists for: giving working practitioners a platform to share what they have actually learned, not just what sounds good on a conference stage.

Sources: - Ron A, What Does a PMM Do? It Depends, Product Coalition - Pulkit Agrawal, What is Product Marketing? A Data-Backed Definition, Product Coalition - Chris Miles, What Is Each Flavour of Product Manager Responsible For?, Product Coalition - Clayton Tarics, Strategy Storytelling: The Product Narrative Canvas, Product Coalition - Navneet Maheshwari, A Template for Great Go-to-Market (GTM) Strategy, Product Coalition - Jon Matheson, The Commercial Side of Product: What I Learned the Hard Way, Product Coalition - Product Dave, No, Airbnb Is Not Killing the Product Function, Product Coalition - Dan Balcauski, EP83: Profit by Design — Mastering SaaS Pricing and Packaging, Product Coalition Podcast - Nicole Segerer, EP93: Monetize This — Data, AI and the Future of Software Pricing, Product Coalition Podcast

👋 Jay

Brought to you by ExecReps.ai, AI-powered executive presence coaching for teams.

👉 If you're not a subscriber yet, subscribe here so you don't miss the next issue.

Kodak invented the first digital camera. They held a vast portfolio of digital photography patents. And in 2012, they filed for bankruptcy. The reason? They were too afraid to cannibalize their own film business. Meanwhile, Apple looked at the iPod, its most successful product at the time, and said "let's kill it" by launching the iPhone. Same decade. Opposite instincts. Wildly different outcomes.

This issue's articles hit different because the writers aren't theorizing from the sidelines. John Utz, Gaurav Nukala, and Noa Ganot are in the trenches, wrestling with the exact tension that killed Kodak: when do you protect what's working, and when do you burn it down for something better?

The thing I keep coming back to is how emotional this decision is. It's not a spreadsheet problem. It's a courage problem. John Utz captured Kodak's failure perfectly: "Despite being a pioneer in the photography industry and holding a vast portfolio of digital patents, Kodak failed to prioritize the transition to digital photography effectively. This reluctance stemmed from a fear of cannibalizing their highly profitable film business."

They had the technology. They owned the patents. But the comfort of existing revenue held them hostage.

John continues: "Kodak's hesitation and misaligned priorities led to its inability to capitalize on its technological advancements, ultimately resulting in the company filing for bankruptcy in 2012." That's the quiet tragedy of product cannibalization anxiety. It doesn't look like a crisis at the time. It looks like prudence. It looks like protecting the business. Until it's too late.

Steve Jobs understood this better than most: "People think focus means saying yes to the thing you've got to focus on. But that's not what it means at all. It means saying no to the hundred other good ideas that there are." And sometimes that 'no' is aimed at your own current cash cow.

I wonder if most product teams even have the vocabulary for this conversation. Our roadmaps are full of "new features" and "growth initiatives." I almost never see "product sunsetting" or "feature deletion" as a top priority. John Utz addresses this head-on in Delete to Accelerate: Transforming Your Product with a Reverse Roadmap. He points out something that made me pause: "We have a roadmap that is largely, if not entirely, focused on releasing new stuff while maintaining what we have. But for some reason, we don't have a roadmap focused on decluttering and simplifying the product."

I found myself nodding at that. Launches get celebrated. Retirements get mourned, or worse, avoided entirely.

John describes his own frustration: "I was pissed. So what did I do? This was around the time that the idea of a separate, reverse roadmap came to mind." His proposal is simple and a bit radical: "Spend as much time planning for what you will get rid of as you do planning for what you will add." Adobe, Atlassian, and Salesforce all maintain separate retirement roadmaps. It's not a fringe idea. But it still feels rare in practice.

This isn't about arbitrary deletion though. Gaurav Nukala brings the bigger picture with How To Determine Product Priority: A Portfolio Management Framework. He makes the uncomfortable case that sometimes you have to sacrifice individual product success for the health of the whole portfolio. "We have to sub optimize individual products to optimize the portfolio," he writes. That sounds like a tough conversation to have with the team that just shipped a solid quarter on a product you're about to sunset.

And then there's the AI acceleration. Noa Ganot's Product Strategy in the AI Era hits this point hard. "Without a clear product strategy, AI will help you go fast in every possible direction at once." That line has been rattling around in my head since I read it. Everyone is shipping AI features. But without a strategy for what to keep, what to replace, and what to let go of, you end up with a bloated mess. Noa warns, "You can't afford to do it blindly, spray and pray, and hope that somehow one of your attempts will work."

Jeff Bezos put it another way, as quoted in John Utz's The Power of Product Lifecycle Management: "All businesses need to be young forever. If your customer base ages with you, you're Woolworth's." That's not about ageism. It's about relevance. And staying relevant sometimes means your best product today becomes the thing you retire tomorrow.

What I Am Hearing on the Podcast

This tension between protecting what works and building what's next keeps surfacing in my podcast conversations.

I was talking with Dan Balcauski in EP83 about pricing and packaging when he asked something that stuck with me: "Is this new set of capabilities, the benefits, the use case that we're talking about, is this talking to the same buyer? Is this an extension of that same buyer's life? Or are we talking to the person in the cube next to him or in the building next to him?"

That question matters for cannibalization more than people think. If you're building for the same buyer, you're creating a choice. And if the new thing is better, the old thing has to go. Dan also said something that's hard to hear but important: "The customers don't care about how many story points it took to build your feature and they don't care about the variable costs of your expenses. The value is not in the feature. The value is in the mind of the customer." Internal effort doesn't equal external value. And when the new product delivers more value, sentimentality about the old one becomes a liability.

In EP93 with Nicole Segerer, the conversation got into AI and cloud migration. Nicole shared something sobering: "80% of companies will have launched some sort of AI functionality. But when you really go deeper and you look at, okay, are customers using this? And is it something that carries some value that people would actually pay for? That creates a whole different picture."

She also named the classic cannibalization standoff: "Sometimes the profitability is still sitting with on-premise products. That's okay. But then you also need to think about how do I grab that customer cohort and move them to my cloud and SaaS products." The old product is still paying the bills. The new product is the future. Managing that transition without blowing everything up is one of the hardest things in product.

Nicole finished with something that keeps echoing for me: "People need to unlearn to just build features and capabilities for the sake of it. It doesn't work, especially when you think about AI use cases." Unlearning. That might be the most important skill in product right now. Unlearning the instinct to protect, to add, to preserve. Learning instead to subtract, to sunset, to cannibalize your own work before someone else does it for you.

I keep wondering though. How do you build that muscle? How do you create a culture where killing your own successful product isn't career suicide but career-defining? I don't have a clean answer for that. Maybe nobody does yet.

John Utz, Gaurav Nukala, and Noa Ganot are doing the work that matters here. John isn't just writing about reverse roadmaps as a concept. He lived the frustration, got mad about it, and built the framework. Gaurav is bringing rigour to portfolio decisions that most teams make on gut instinct. And Noa is asking the hard questions about AI strategy that everyone is thinking but few are writing down. These are practitioners sharing what they've learned in the middle of doing it, not from the comfort of having figured it all out. That's what makes their work worth reading.

👋 Jay

Sources:

• John Utz, Delete to Accelerate: Transforming Your Product with a Reverse Roadmap

• John Utz, It Means Saying 'No': How to Master Prioritization Like Steve Jobs

• Gaurav Nukala, How To Determine Product Priority: A Portfolio Management Framework

• Noa Ganot, Product Strategy in the AI Era

• John Utz, The Power of Product Lifecycle Management

• EP83, Dan Balcauski

• EP93, Nicole Segerer

Brought to you by ExecReps.ai — AI-powered executive presence coaching for teams.

Somewhere around 72% of SaaS companies will change their pricing model within the first 18 months of launch. Not because the product failed, but because the way they asked people to pay for it did.

These are product practitioners who've wrestled with the question most teams avoid: not "what should we build?" but "how should we get paid for it?" Nick Chasinov, Bart Krawczyk, Noa Ganot, Scott Middleton, Advait Lad, Bhavik Patel, and their fellow writers have turned monetisation from a finance team afterthought into a genuine product discipline, and their work in Product Coalition is a masterclass in thinking about money as a design problem.

I have been guilty of treating pricing as the last slide in the deck. You build the thing, you ship the thing, and then someone in a meeting asks "so what do we charge?" and the room goes quiet. The truth is, the pricing model is the product experience for a lot of your users. It shapes what they try, what they ignore, and whether they come back.

Nick Chasinov puts it bluntly in How To Select the Right Pricing Model for Product Monetization Opportunities: "The success of a product, apart from the product itself, often hinges on how a company chooses to leverage its monetization opportunities." He's right. And he goes further: "Setting a price involves several factors: costs, competition, profit margins, demand, pricing objectives, and more." Most product teams I know handle maybe two of those variables well and guess the rest.

The problem gets more interesting when you zoom out from individual pricing decisions to the business model itself. Bart Krawczyk wrote what I think is one of the most underrated articles in our publication: Products Don't Exist in A Vacuum: A Product Manager's Guide to Business Models. It is a reminder that the monetisation model isn't a lever you pull after the product is built. It is the architecture the product lives inside.

The Freemium Trap and the Upgrade Nudge

Here is a number that should make you uncomfortable: according to industry benchmarks, typical freemium conversion rates sit between 2% and 5%. That means up to 98% of your free users may never pay you a penny. The question is whether that 98% is working for you or against you.

Advait Lad digs into this in Freemium to Premium: How Companies Nudge You To Upgrade. The article maps out the psychological machinery behind the upgrade moment, from feature gating to usage limits to the subtle art of making the free tier feel generous but incomplete. It is a fascinating read because it sits right at the intersection of product design and commercial strategy, the exact space where most PMs feel least confident.

But here is the thing about freemium that rarely gets discussed honestly: it is not just a pricing model. It is a distribution model. The free users are not freeloaders. They are your marketing department, your word-of-mouth engine, your living proof that the product works. The conversion rate matters, but the virality coefficient matters more. If your free users are not talking about you, freemium is just an expensive demo.

Beyond the Subscription Box

The SaaS pricing conversation has gotten stale. Sriram Parthasarathy does a thorough job of mapping the landscape in The Right SaaS for You: How to Break Down SaaS Pricing Models. He explains that "Companies may need to experiment with different pricing models to find the best fit for their particular product and audience." That sounds obvious on paper. In practice, most companies pick a model at launch and defend it like a castle wall, even when the moat has dried up.

Serhat Pala takes this further in SaaS 2.0: When the Software Becomes the Worker, arguing that AI agents are about to blow up the per-seat pricing model entirely. When software does the work that humans used to do, charging per person makes no sense. You start charging per outcome, per task, per unit of value delivered. This is not a future prediction. It is happening right now.

The API Economy's Quiet Revolution

One of the most thoughtful monetisation frameworks I have read came from Scott Middleton. His multi-part series, API Monetisation: A Comprehensive Guide (Part 1) and A Comprehensive Guide to API Monetisation (Part 3): Indirect Monetisation, lays out how APIs have created entirely new monetisation surfaces. The indirect model is the most fascinating part: you give the API away or charge a nominal fee, and the real revenue comes from the ecosystem it creates. It is Stripe's playbook. It is Twilio's playbook. And increasingly, it is the playbook for any product with developer-facing surfaces.

The Price Experiment Nobody Wants to Run

Bhavik Patel asks the question that keeps pricing teams up at night: Are Pricing Experiments Unethical? It is a genuinely brave article because most product people will A/B test a button colour without blinking but refuse to test a price point because it "feels wrong." Bhavik makes a compelling case that not experimenting with pricing is the more dangerous option, because you end up charging based on gut feel and competitor mimicry rather than evidence.

He follows it up with You're Using the Wrong Metric for Pricing Experiments, which gets into the mechanics of what you should actually measure. Spoiler: conversion rate alone will mislead you. Revenue per visitor is a better north star.

When Customers Don't Actually Want Cheaper

Noa Ganot drops perhaps the most counterintuitive insight in this entire collection. In Do Your Customers Really Want to Pay Less?, she compares two service providers. One optimised for minimum cost and effort. The other optimised for maximum value delivered. The one that charged more won, because "even in times of an economic downturn lowering your prices blindly is not necessarily the right thing to do." Every PM who has ever panicked and slashed prices during a tough quarter should read this piece. Sometimes the customer does not want to pay less. They want to feel like they are getting more.

Marketplace Models: Aligning Incentives

Lucas Fonseca Navarro rounds out the picture with The Marketplace Starter Pack, arguing that "commission is always preferable when possible, and the reason for this is that you guarantee the greatest retention of value for your company." Commission-based models are the ultimate incentive alignment: you only make money when your users make money. He notes that platforms like eBay capture around 10% in commission while advertising-based models capture less than 1%. The gap tells you everything about which monetisation model has real staying power.

And then there is Gabriyel Wong with A Revenue Growth Model That Breaks the Price War Conundrum, who brings behavioural economics into the conversation. When everyone in your market is racing to the bottom, the answer is not to race faster. It is to change the race entirely.

What I Am Hearing on the Podcast

Three recent conversations on the podcast have all circled around the same uncomfortable truth: most product teams treat monetisation as someone else's problem until it is too late.

Dan Balcauski, founder of Product Tranquility and pricing strategist who teaches at Northwestern's Kellogg School of Management, put it most directly on EP83:

Dan's advice was to spend most of your time on what the price tag goes on and very little time on what number goes on the price tag. The packaging decisions, the price metric, whether you charge per seat or per outcome or per API call, those structural choices are where the real leverage lives. He also called out a pattern I have seen everywhere: "There's really only three ways to grow a SaaS company: acquisition, retention, and monetization. In that zero interest rate environment, the only thing that gets any oxygen is acquisition. Retention is not really considered and monetization is sort of an afterthought." That afterthought era is over.

Nicole Segerer, a monetisation specialist with over a decade at Revenera and Flexera, reinforced this on EP93:

She was talking about usage intelligence, the practice of instrumenting your product to understand how customers actually consume it before you build a pricing model around it. Her warning was sharp: "When companies implement too quickly, without having the right data, monetization models go wrong. And when that goes wrong, you have a customer satisfaction issue. Then you've got to retract and change your pricing models, and that erodes trust."

Nicole also challenged the lazy use of "subscription" as a catch-all: "Subscription always gets used as this broad talk term. 'Oh yeah, we monetize as a subscription.' But really that's not the statement. The statement is what is your subscription based on?" With AI reducing the number of human users in many software products, she argued that per-seat subscription models may need to be fundamentally rethought.

And Dave West, CEO of Scrum.org, connected it all to a wider product leadership crisis on EP74:

He is talking about Scrum and agile, but the monetisation parallel is exact. We have spent a decade training PMs to be technically excellent, to understand APIs and data pipelines and system architecture, while the commercial muscle has quietly atrophied. Monetisation strategy is not just a finance problem. It is a product problem. And if you cannot have a meaningful conversation with your CFO about how your product makes money, you are only doing half the job.

So here is the question worth sitting with: if your product's pricing model was invented before your product existed, who is actually making the monetisation decision? The answer, for most teams, is "someone who left three years ago." And that should terrify you more than any competitor launch or market downturn. Because the companies that win the next decade will not be the ones with the best features. They will be the ones who figured out that how you capture value is itself a product decision, one that deserves the same rigour, the same experimentation, and the same creative ambition as anything else on your roadmap.

The writers featured in this issue are doing something that matters: they are treating monetisation as a product discipline, not a business team handoff. They are the PMs who sit in pricing meetings and actually have opinions backed by frameworks. They are the builders who understand that how you charge shapes what you build. Nick Chasinov mapping monetisation opportunities, Bart Krawczyk connecting business models to product architecture, Noa Ganot challenging the "cheaper is better" assumption, Scott Middleton dissecting API economics, Advait Lad reverse-engineering the freemium nudge, Bhavik Patel making the case for price experimentation, and Lucas Fonseca Navarro aligning marketplace incentives. This is what Product Coalition exists for: giving working practitioners a platform to share the commercial thinking that rarely makes it into product conference talks.

If you are not already part of our community, subscribe below for more content like this, delivered to your inbox every week.

Sources

- Nick Chasinov, How To Select the Right Pricing Model for Product Monetization Opportunities, Product Coalition - Sriram Parthasarathy, The Right SaaS for You: How to Break Down SaaS Pricing Models, Product Coalition - Advait Lad, Freemium to Premium: How Companies Nudge You To Upgrade, Product Coalition - Bart Krawczyk, Products Don't Exist in A Vacuum: A Product Manager's Guide to Business Models, Product Coalition - Scott Middleton, API Monetisation: A Comprehensive Guide (Part 1), Product Coalition - Scott Middleton, A Comprehensive Guide to API Monetisation (Part 3): Indirect Monetisation, Product Coalition - Bhavik Patel, Are Pricing Experiments Unethical?, Product Coalition - Bhavik Patel, You're Using the Wrong Metric for Pricing Experiments, Product Coalition - Noa Ganot, Do Your Customers Really Want to Pay Less?, Product Coalition - Lucas Fonseca Navarro, The Marketplace Starter Pack, Product Coalition - Gabriyel Wong, A Revenue Growth Model That Breaks the Price War Conundrum, Product Coalition - Serhat Pala, SaaS 2.0: When the Software Becomes the Worker, Product Coalition - Stephen Butts, Monetizing Your Product: A Guide to Pricing Strategies and Techniques, Product Coalition - Dan Balcauski, EP83: Profit by Design: Mastering SaaS Pricing and Packaging to Maximize Growth, Product Coalition Podcast - Nicole Segerer, EP93: Monetize This! How You Can Turn Data, AI, and Innovation Into Revenue, Product Coalition Podcast - Dave West, EP74: Embracing the Product Mindset with Scrum.org CEO Dave West, Product Coalition Podcast

👋 Jay

Brought to you by ExecReps.ai — AI-powered executive presence coaching for teams.

If you are not already part of our community, subscribe below for more content like this, delivered to your inbox every week.

There is a question I keep turning over in my head. When did product managers stop talking to people and start talking to dashboards instead?

I do not mean this as an accusation. I mean it as a genuine puzzle. Because somewhere along the line, something shifted. The industry went from "go talk to your customers" to "check your Amplitude dashboard," and nobody quite noticed the switch happening.

This issue draws on the work of thirteen practitioners who wrote about product discovery in Product Coalition. Not consultants selling frameworks. Not influencers optimising for reach. Working product people, from Tel Aviv to Madrid to Melbourne, sharing what they learned in the messy middle of building products. That is the kind of writing that changes how you think.

The story of how discovery evolved is also the story of how product management grew up. And like most growing-up stories, it involves a few wrong turns.

Era 1: The Requirements Document (1990s-2000s)

If you were building software in the late 1990s, "discovery" meant something very specific. It meant writing requirements. Lots of them. In enormous documents that nobody fully read.

Noa Ganot captured this era perfectly in Let's Say "Discovery": Why "Validation" Is the Wrong Word. She recalled her days as a system architect at the Israeli Air Force, where the prevailing belief was that if you planned well enough, nothing would need to change. "The idea that if only you planned well enough your code wouldn't need to change seems so naive today," she wrote. But back then, it was simply how things worked.

The assumption was simple. Gather every requirement upfront. Write them all down. Hand the document to engineering. Wait. Get exactly what you asked for. Ship.

Except it never worked that way. John Utz, writing in Start Without the End in Mind, described the fundamental flaw: "I wasn't solving their problem; I was solving my own." He had built a feature he was sure users would love, only to watch engagement flatline. The problem was not the feature. The problem was that he never asked anyone if they wanted it.

This was the era of the 200-page specification. Of waterfall timelines that stretched across years. Of "requirements gathering" as a distinct phase that happened once and was never revisited.

And the thing I keep coming back to is how confident everyone was. Nobody thought they were guessing. They thought they were planning.

Era 2: Get Out of the Building (2008-2015)

Then Steve Blank said four words that changed everything: "Get out of the building."

The Lean Startup movement landed like a bomb in product teams that had spent years arguing over requirements documents. Customer Development said something radical for the time, that you could not know what customers wanted by sitting in a conference room debating it. You had to go ask them.

Scott Middleton, in his Product Discovery Playbook, described the core of this shift: "Product Discovery is an exercise in working out whether there are customers that want the product (or feature) you're working on and that you can deliver a solution to them." It sounds obvious now. In 2010, it was a revelation.

This era introduced ideas that are now so embedded in product practice that we forget they were once controversial. Minimum viable products. Hypothesis testing. Pivots. The idea that building the wrong thing was worse than building nothing at all.

Scott Middleton also wrote about an underappreciated side effect in Discovery for Non-Product People. As product teams embraced discovery, a gap opened up with the rest of the organisation. He shared an actual quote from a General Manager: "We gave an outstanding idea to the Lab, but they just told us our idea was no good and we had to go do more work." Discovery created power. It also created friction.

Meanwhile, Fitra Akbar was documenting the craft of the customer interview in How to Run a Customer Interview Correctly. The rules were simple but counter-intuitive: don't talk about your solution, don't share your own opinions, create a comfortable environment. The interview was supposed to be about them, not you.

The Lean Startup era gave product managers permission to be wrong. That was its gift. Its limitation was that discovery still felt like a project with a beginning and an end. You "did discovery," then you "did building." The two tracks ran separately.

Era 3: Continuous Discovery (2015-2022)

Teresa Torres changed the game again. Her book, Continuous Discovery Habits, introduced the idea that discovery was not a phase. It was a practice. Something you did every single week, forever.

Austin Nichols, in Five Lessons on Continuous Discovery, quoted her definition directly: "Weekly touchpoints with customers, by the team building the product, where they conduct small research activities, in pursuit of a desired outcome." That was it. No six-week research sprint. No discovery "phase." Just a steady habit of staying close to the people you are building for.

Nichols also flagged something important: "The antithesis of modern Product is mindlessly building a list of features. It's an anti-pattern to rarely talk to your customers." The bar was no longer "have you done any research?" The bar was "are you doing research this week?"

Anthony Rousounelos built on this in A Continuous Product Discovery Framework for Agile Teams, pointing out the irony that most product teams lived in: "product teams are agile in their implementation efforts while lacking an agile approach in the whole feature prioritization process." Teams were using Scrum to build things fast. They were not using anything resembling agility to decide what to build.

Ant Murphy, in How to Kickoff Product Discovery Like a Pro, addressed the practical question that came up most often when he coached PMs: "I know what I want to do discovery on, but how do I get started?" His answer was Assumptions Mapping and Experiment Boards. Simple tools. Low ceremony. The kind of thing you could do in an afternoon, not a quarter.

And Jerel Lee, in Designers, Forget Lengthy Discovery Activities, Start With Jobs-To-Be-Done Instead, pushed back on discovery becoming its own bureaucracy. His argument was practical: "context matters, in the private sector, business needs dictate quicker turnarounds and an expedient go-to-market approach." Jobs-To-Be-Done, he argued, could compress weeks of discovery into something far tighter.

The continuous discovery era was a genuine breakthrough. But it also created a new failure mode.

Era 4: The Dashboard Trap (2020-Present)

Here is where things get uncomfortable.

Somewhere around 2020, product analytics tools got very, very good. Amplitude. Mixpanel. Pendo. FullStory. Hotjar. Suddenly you could watch exactly what users did without ever talking to them. You could run A/B tests, track funnels, measure retention cohorts, all from the comfort of your laptop.

And slowly, quietly, discovery started to become a dashboard exercise.

I wonder if this is the biggest risk product management faces right now. Not that teams skip discovery entirely. That would be too obvious. The risk is that teams believe they are doing discovery because they look at data. They check metrics. They review dashboards. But they have stopped having conversations.

Michael Goitein captured the extreme version of this in Let's Rethink How We Build Products. He described a leader who dismissed his team's user research with: "I don't care what some random customers told you. You're going to build what I tell you to build." The irony, as Goitein pointed out, was devastating: "Without continuous product discovery, we never would have come to this leader's attention." The very practice that made the team successful was the first thing to get squashed.

Keren Koshman sounded a different alarm in The Balance Between Product Discovery and Delivery. Her concern was that "in the zeal to innovate and strategize, the pendulum has swung too far toward the discovery end of the spectrum." Some teams were doing so much research that they had forgotten to ship anything.

And Afonso Franco wrote what might be the most honest diagnosis of all in How to Escape the "Analysis Paralysis" Trap in Product Discovery: "Endless refinement of your idea. Completely lost in customer insights. Drawn in data. And not much progress apart from more and more user interviews. In essence, you're stuck." His list of causes reads like a mirror: perfectionism, fear, misunderstanding what good discovery looks like, and something he called "discovery fanaticism," where a PM "sees her/his job as to 'do discovery and design', usually following a certain framework religiously."

Maret Kruve brought mathematical rigour to this tension in The Discovery Dilemma: When to Just Ship It. Her framing was brilliant: "Think of discovery as buying risk insurance: you pay a premium to reduce the probability of a larger potential loss." And then the punchline: "Insurance is worth the price only when the potential loss is high compared to the premium. It makes little sense when the potential loss is trivial. You insure your house, not your stapler."

That last line should be tattooed on every product team's wall.

Era 5: The AI Discovery Frontier (2024-Present)

And now we are here. In the era of synthetic users and AI-assisted research.

Tools are emerging that promise to simulate customer interviews. AI can summarise transcripts, cluster feedback, generate personas, even suggest opportunity spaces. The question is no longer whether AI can help with discovery. It can. The question is whether it can replace the part that matters most.

And the part that matters most has never been the data. It has been the surprise.

John Utz put it best: "Great product strategists fall in love with the user's problem, not the solution." You cannot fall in love with a problem you have never seen up close. You cannot be surprised by a dashboard. You can only be surprised by a person saying something you did not expect.

Noa Ganot's argument about language matters here too. She argued that "validation" was the wrong word because it implied you already had the answer and were just checking it. "Discovery" was better because it implied you were genuinely looking for something you did not already know. As AI makes it easier than ever to "validate" at scale, the danger is that we lose the genuine looking-for-something-new part entirely.

The thing I keep coming back to is this: every era of discovery has been a reaction to the previous era's failure mode. Requirements documents failed because they assumed you could know everything upfront. Customer Development failed because it was a one-off phase. Continuous Discovery risks failing because it can become performative. And AI-assisted discovery risks failing because it might give us answers to questions we should not have been asking in the first place.

So here is my open question for you. If you replaced every customer conversation with an AI simulation, and the simulation gave you the same insights, would you have learned the same thing? Or would you have missed the thing that only shows up in the awkward pause, the offhand comment, the thing the customer says after you have already stopped recording?

What I Am Hearing on the Podcast

Three recent podcast conversations keep circling back in my thinking around this topic.

Dave West, CEO of Scrum.org, came on EP 74: Embracing the Product Mindset and described a problem that sits at the root of the dashboard trap. He talked about teams whose "connection to the users, and to the stakeholders, and to the problem domain is tenuous at best." These teams work on something, then work on something else, then something else again. They never stay close enough to any one set of users to develop real understanding.

Dave also painted the picture of what good looks like, drawing from startups: "continuously innovating, everybody's motivated, everybody connects to the customer, everybody's flexible because you have to be." That is the environment where discovery happens on its own, not because someone scheduled a research sprint, but because everyone is close enough to the problem that they cannot avoid learning.

And when asked about what matters most in complex product work, Dave cut right to the core: "if it's a complex problem, are you incrementally delivering, learning against that problem, that's defining your understanding of it and delivering more value?" That is discovery in one sentence. Not a phase. Not a dashboard. Learning against the problem.

Then Dan Balcauski, founder of Product Tranquility and a program leader at Northwestern's Kellogg School of Management, came on EP 83: Profit by Design and said something that landed hard. Talking about how companies understand the value they create, Dan was blunt: "the value is not in the feature. The value is in the mind of the customer."

Dan went further, pushing back on the idea that you can understand customers from data alone: "understanding customer value, you can't just do in a room with a couple of spreadsheets. You have to go talk to customers." He described running qualitative interviews before any pricing work, asking not about numbers but about context, what customers were trying before, what caused them to look for a new solution, why alternatives fell short. Discovery, it turns out, is not just a product management practice. It is how any function that touches customers should be thinking.

And Ana Bello-Elliott, founder of Bello Insights Lab, came on EP 94: Do We Really Need Research for This? and brought something I had not heard anyone frame so clearly before. Ana started her career in cybersecurity, and she drew a direct line between risk documentation and product discovery: "In the cybersecurity world, risks have to be documented. They have to be acknowledged... I think we need something similar in our discipline, where we are at least having the discussion of what is the risk that we're taking on by not taking an action."

That reframe hit hard. Discovery is not a nice-to-have. It is risk management. And Ana had the four questions to back it up: Do we know what customer needs we are solving for? How do we know, what is the evidence? Is this impacting more than one customer? And what is the risk if we move forward without research?

Ana also gave the most honest assessment I have heard of AI-assisted research. She described using an AI moderator for a recent study: "There were things that the tool was not very good at, like my user was sharing their screen. It could not interpret what was happening on the screen." A participant thought they were sharing their screen but were not, and the AI had no way to notice. A human moderator would have caught it immediately. But then the flip side: "If we need 100 interviews overnight, you can get 100 interviews overnight." The power is real. The gaps are real too.

And then the line that ties it all together: "Research is, at the end of the day, strategic. And something that we often forget because UX and UX research lives within the little box of UX design. But at the end of the day, research is strategy. It feeds into your strategy." That is the argument for discovery that cuts through every era of this newsletter. Not a phase. Not a checkbox. Strategy.

What these thirteen writers and three podcast guests are doing is the work that Product Coalition exists for. They are not waiting for someone to hand them a framework. They are building in the open, sharing what they learn, and being honest about what does not work.

Ant Murphy is building Assumptions Maps with his teams. Maret Kruve is doing the maths on when discovery is and is not worth the investment. Afonso Franco is naming the failure modes that nobody else wants to talk about. Michael Goitein is pushing back against leaders who would rather dictate than listen. Austin Nichols is running small experiments every week. Noa Ganot is questioning the very words we use to describe what we do. And Ana Bello-Elliott is treating discovery as the risk management discipline it always should have been.

These are the people doing the work. Not from stages. From desks and calls and sprint reviews and awkward customer interviews. This is what open practice looks like.

Discovery has been many things over the decades. A requirements document nobody read. A post-it wall in a WeWork. A Dovetail dashboard with 400 tags and zero conviction. Each era tried to solve the same problem: how do you build something people actually want when you are not the person who will use it?

The answer has never changed. You talk to them. You watch them. You sit in the discomfort of being wrong. The tools will keep evolving. AI will get better at summarising transcripts and worse at noticing that someone is not actually sharing their screen. But the discipline underneath, the willingness to be surprised, that part is not automatable. It never was.

The best discovery teams I see right now are not choosing between human and machine. They are using AI to move faster and humans to move deeper. That is not a compromise. That is the frontier.

👋 Jay

If you are not already part of our community, subscribe below for more content like this, delivered to your inbox every week.

Sources

- Ant Murphy, How to Kickoff Product Discovery Like a Pro, Product Coalition - Noa Ganot, Let's Say "Discovery": Why "Validation" Is the Wrong Word, Product Coalition - Maret Kruve, The Discovery Dilemma: When to Just Ship It, Product Coalition - Austin Nichols, Five Lessons on Continuous Discovery, Product Coalition - Keren Koshman, The Balance Between Product Discovery and Delivery, Product Coalition - Afonso Franco, How to Escape the "Analysis Paralysis" Trap in Product Discovery, Product Coalition - Scott Middleton, Product Discovery Playbook, Product Coalition - Anthony Rousounelos, A Continuous Product Discovery Framework for Agile Teams, Product Coalition - Scott Middleton, Discovery for Non-Product People, Product Coalition - Fitra Akbar, How to Run a Customer Interview Correctly, Product Coalition - John Utz, Start Without the End in Mind, Product Coalition - Michael H. Goitein, Let's Rethink How We Build Products: How Product Discovery Works, Product Coalition - Jerel Lee, Designers, Forget Lengthy Discovery Activities, Start With Jobs-To-Be-Done Instead, Product Coalition - Ana Bello-Elliott, EP 94: Do We Really Need Research for This?, Product Coalition Podcast

I found a box of old notebooks in my garage last week. Index cards with user stories scribbled in pencil, acceptance criteria that read more like legal contracts than promises of value. I remember being proud of those cards. I thought the process was the work. Looking at them now, I see a graveyard of features nobody ever used.

That got me thinking. So I went back through our archive to trace how we went from "let's talk about what the user needs" to "please fill in the Jira template correctly."

Brought to you by ExecReps.ai — AI-powered executive presence coaching for teams.

Product Coalition is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

The Template Era (2018–2019)

In 2018, Bindiya Thakkar wrote what might be the most earnest guide to user stories ever published on Product Coalition. She laid out the whole thing: epics with four sections, stories with acceptance criteria, design requirements, engineering requirements. Every piece accounted for, every edge documented.

"Writing a good epic and user story is the most basic and the most important task at hand when you enter the role of Product Management."

I don't say that dismissively. If you were a new PM in 2018, that article was a lifeline. You had no idea what you were doing, and here was someone who'd been in the trenches laying out exactly how to write the thing your team was going to build from. Not a VP giving a keynote. A practitioner, sharing what she'd figured out.

That was the energy of user stories when they still worked. They were conversation starters, not paperwork. Bindiya's article reads like someone who genuinely believed that if you wrote the story well enough, the team would build the right thing. And for a while, that was probably true.

The Ticket Factory (2020–2022)

Then something shifted. The tool became the process. The process became the bureaucracy.

J.A. Becker captured it perfectly in 2022: "I used to slave over these things. They had to be perfect." His manager would review every Jira ticket and make him rewrite it again and again. Some companies were actually reviewing ticket quality for performance evaluations.

Think about that. We took a format designed to start a conversation and turned it into something you could be graded on.

"Perfect tickets are perfectly scoped to do a given task perfectly in a perfect world. And it's not a perfect world."

That same year, John McDonald pointed out that most product teams were building with no real map of where they were going. "Too much focus on getting things shipped and too little focus on the who, what, why and how." His solution was story mapping, which at least tried to reconnect the stories to a bigger picture. But the fact that he had to write that article tells you how far we'd drifted. Teams were cranking through backlogs of perfectly formatted tickets that added up to nothing.

Here is the part nobody on stage at conferences talks about. The PMs writing those tickets were not lazy or incompetent. They were doing exactly what the system asked of them. Write the ticket. Get it estimated. Ship it. Repeat. If the output didn't create outcomes, that was somehow also their fault. The messy middle of product management, the place where most of us actually work, had been reduced to a ticket queue.

The Rebellion (2023)

By 2023, practitioners started saying what they'd been thinking for years.

Lee Fischman published a piece called "A meditation on how user stories can be really stupid." Not the kind of title you'd hear at a product leadership summit. But the kind of thing you'd say to a colleague over coffee.

His point was subtle: the format itself creates tautologies. "As a user, I want X because I want to do X." We'd turned a communication tool into a fill-in-the-blank exercise where the blanks didn't even make sense half the time. His advice? "If its purpose ends up looking silly, maybe try to improve it, or leave it out." Radical honesty from someone in the middle, not the top.

Lisa Mo Wagner took a different angle that same year. She was still teaching the craft, still showing people how to write good stories, but she'd quietly moved to the "job story" format instead. "When [situation], I want to [motivation], so I can [expected outcome]." Notice what changed. The user is in a situation, not a persona. The motivation is real, not a template fill. It was an evolution driven by the people doing the actual work.

And then Ant Murphy dropped the hammer: "Ditch Epics and User Stories and Focus on Outcomes."

Ant had been helping organisations shift from output to outcome thinking, and he kept seeing the same problem. "I've seen too many places get stuck in a perpetual hamster wheel arguing over what an Epic is. Epics vs Initiatives vs User Stories? Who owns what? Who prioritises what? Where do they belong?" All that energy wasted on semantics while nobody was measuring whether the work actually changed anything.

His reframe hit hard: going from "I want" to "we believe" shifts from certainty to uncertainty. "We believe" admits you might be wrong. "I want" pretends you already know.

What Replaced Them?

I am not sure anything cleanly replaced user stories. The best teams I talk to have moved toward a hybrid that looks less like a template and more like a thinking tool.

Ram Maganti wrote about the synergy between problem statements and user stories on Product Coalition: "Failure to thoroughly understand these pain points can increase the risk of product failure." He argued that user stories work when they're paired with problem statements that provide the context. Without the problem, the story is just a task.

Lavaneesh Gautam pushed for smaller, more valuable backlog items. "A product is a vehicle designed to deliver value and each Product Backlog Item should deliver incremental value." His warning is one I've ignored too many times: "Many teams sometimes break down units of value into tasks and consider them as product backlog items, please don't do this." When you do, you end up managing a list of chores instead of a product.

And Noa Ganot flipped the whole customer request problem on its head: "The product manager doesn't need to be the voice of the customer. That's on sales and customer success. Instead, the product manager needs to be the voice of the market." She gave PMs permission to let customer requests sit in the backlog, reframing them as "a treasure trove of raw market signals" rather than orders at a restaurant.

None of these people are CEOs of billion-dollar companies. They are practitioners sharing hard-won lessons from the middle of the work. That is exactly why it matters.

What I Am Hearing on the Podcast

Back in 2020, I sat down with James Sear and Tim Ramage from Avion in a WeWork in Holborn to talk about user story mapping. They built a digital story mapping tool because they kept seeing the same problem: teams would do the hard work of mapping everything out on a wall, have brilliant conversations, and then dump it all into a backlog tool and forget the map ever existed.

James put it plainly: "You have really great conversations. You get everyone involved, and then you put everything into a backlog tool manually, and you forget about the user story map. And all of that context and conversation that you had is lost."

That loss of context is the thread running through everything I've traced in this issue. The format was never the point. The conversation was the point. And the conversation got lost somewhere between the Post-it wall and the Jira board.

Tim made a distinction that has stuck with me: "It's less about what's our velocity and how many points can we deliver in the next sprint, and it's more about what's our hypothesis here. Let's create a release around what we think we want to solve." That shift, from velocity to hypothesis, is exactly what Ant Murphy and the 2023 practitioners were pushing toward. The podcast conversation in 2020 was already pointing where the written discourse would land three years later.

One detail that made me laugh: Tim said the biggest pitfall with physical story mapping is that "they fall off the wall after you've moved them at least twice, or the cleaners come in." Coming into the room and seeing five Post-it notes on the floor with no idea where they belonged. If you've ever been on a product team, you've lived that moment. Nobody puts that in a conference keynote, but everyone in the messy middle knows exactly what it means.

Listen to the full conversation

So Where Does That Leave Us?

User stories did not fail because the format was bad. They failed because we stopped using them as conversation starters and started using them as compliance documents. The original idea, a placeholder for a human conversation about what we're building and why, was always sound. We just buried it under process.

The people I've quoted in this piece are not famous. They are product managers, product coaches, and practitioners who sat down and wrote about what they were seeing in their own teams. That's what Product Coalition exists for. Not to tell you what the top of the industry thinks, but to give you access to what your peers have figured out.

If you stopped using the standard user story format tomorrow, what would you replace it with to make sure your team still builds the right thing? Hit reply and tell me. I want to hear what's working in your world, not just what the textbooks say should work.

You're reading the Product Coalition newsletter. Every week, I dig into the archive of 3,500+ articles and 100+ podcast episodes to trace how product thinking has evolved. If someone forwarded this to you, subscribe here so you don't miss the next one.

👋 Jay

Sources

Bindiya Thakkar — How to Write Epics and User Stories (Nov 2018), J.A. Becker — Writing the Perfect Jira Ticket Doesn't Matter (Mar 2022), John McDonald — Why Product Managers Should Be Story Mapping (Jun 2022), Lee Fischman — A meditation on how user stories can be really stupid (Oct 2023), Lisa Mo Wagner — How to Write the Best User Stories (Jul 2023), Ant Murphy — Ditch Epics and User Stories and Focus on Outcomes (Jul 2023), Ram Maganti — It's About Synergy: The Power of Problem Statements and User Stories, Lavaneesh Gautam — How To Create Small Product Backlog Items, Noa Ganot — Building Trust Around Customer Requests

In this episode, Weiwei Hu, an analytics and AI leader, discusses how data analytics can be transformed from mere reporting to driving strategic decisions. She explores the disconnect between analytics and business strategy, the impact of AI on analytics workflows, and how to leverage data for better decision-making.

Take aways

• Disconnect between analytics and strategy

• AI’s role in transforming analytics workflows

• The importance of decision-focused analytics

• Storytelling and stakeholder communication in analytics

• The evolving role of analytics teams in the AI era

Chapters

• 00:00 Introduction to Analytics and AI in Product Leadership

• 02:53 The Disconnect Between Analytics and Strategy

• 10:08 The Role of AI in Enhancing Analytics

• 22:04 Shifting from Data-Driven to Outcome-Driven Culture

• 28:53 Deciding What Analytics to Retire

• 33:31 The Importance of Tailored Storytelling in Analytics

Between 20% and 60% of users churn after their first session with a product. I had to read that number twice. Not after a month. Not after a quarter. After a single session, up to six out of ten people decide they've seen enough and leave.

The numbers in this issue come from product people who got tired of watching dashboards turn red and decided to do something about it. They are not retention consultants selling frameworks. They are practitioners who opened their spreadsheets and shared what they found.

I think about this stat every time I see a startup announce a huge funding round alongside a user acquisition number. The number always goes up. The retention number is never mentioned. There is a reason for that, and it is not flattering.

Brought to you by ExecReps.ai, AI-powered executive presence coaching for teams.

Product Coalition is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

The Sign-Up Is Not the Win

I spent an hour last week trying to unsubscribe from a meal kit service that I signed up for during a moment of late-night ambition. It took four clicks and a forced survey just to stop the boxes from arriving at my door. I sat there watching the screen and realised that I was just another data point in a very expensive game of musical chairs.

Ant Murphy captured this distinction perfectly in Acquisition vs Activation and How to Predict Churn. He writes: 'Acquisition is when you get a user on board. Activation is when you get them to use your product in a meaningful way.'

I wonder how many product teams confuse those two moments. Ant asks a question that I find genuinely uncomfortable: 'Just think how many things have you signed up for and never used?' I look at my own phone and see at least a dozen apps gathering digital dust. Every one of those was someone's acquisition metric. None of them became an activation story.

He had a FinTech client whose mobile team was tracking daily active users as their core metric. His challenge to them: 'How often do you look at your bank account? Do you check your app every day? I don't.' They were measuring engagement on a cadence that did not match how people actually use banking products. The number looked good on a dashboard. It meant almost nothing.

His advice is the bit that stays with me: 'Don't just track acquisition, activation and retention. Track the nuanced states between each of them.' The space between active and churned is not a cliff. It is a slow, quiet drift that most dashboards are not designed to show you.

The 90% Problem

If you ignore those nuances, you end up fighting a war you cannot win. The team at UXCam laid out the stakes in How to Measure, Analyze, and Reduce App Churn: 'All the user acquisition in the world won't matter if you've got a high churn rate on your app.'

It is a simple truth that most teams acknowledge and then proceed to do nothing about. They also note that 'it's generally much easier to retain customers than it is to gain new ones.' Everyone nods at this in meetings. Very few teams actually resource retention work the way they resource acquisition campaigns.

The statistic that I keep coming back to from their piece: 90% of users have stopped using an app due to poor performance. Not missing features. Not bad pricing. Poor performance. The app was slow, or it crashed, or the thing they wanted to do took too many steps. Product teams obsess over building the next feature while the foundation is cracking under their feet. I suspect that fixing a slow loading screen is often a better investment than building a new dashboard, but that fix never makes it into the quarterly roadmap presentation because it is not exciting enough.

The Unicorn Graveyard

Nick Chasinov puts the human cost of this in focus in User Retention Defines Your Product's Success: Here Are 3 Ways to Improve It. He mentions that 'the number of users who churn in the first session ranges from 20% to 60%.' That is the stat I opened with, and it is a sobering thought for anyone whose job depends on growth.

He also cites research showing that 'improving retention by just 5% can boost revenue by 25% to 95%.' A five percent improvement. Not a rebuild. Not a pivot. Five percent less leaking from the bucket.

The examples he picks are the ones that should keep product leaders up at night. Fab, the design e-commerce site, 'was valued as a unicorn and raised a $336 million funding round prior to closing its doors.' Homejoy, the home services platform, raised almost $40 million and shut down 18 months later. Both grew fast. Neither retained.

His framing is the one I wish more product teams would internalise: 'It's easy to show investors top-line growth, such as gaining 100,000 new users in a week, but retention paints a more accurate picture of long-term success.' The leaky bucket looks full if you keep pouring water in fast enough. It is still leaking.

Putting a Number on the Leak

If you want to move this from philosophy to action, Scott Middleton provides a framework in How to Calculate the Value of Your Retention Improvements. He acknowledges upfront that 'calculating the return on investment of improvements to retention can seem like a daunting or complex task.'

His approach is deliberately simple: take your churn rate, multiply it by the number of customers, and multiply that by your lifetime value. The number you get is what churn is costing you right now. I find this math useful because it removes the emotion from the room. It turns a product problem into a business reality that a CFO can understand and act on. No philosophical debates about user experience. Just a number on a spreadsheet that says 'this is what we are losing every month because people leave.'

The simplicity is the point. Scott argues that without a clear and uncomplicated formula, your calculation would get caught up in sensitivity analysis and endless debates about the inputs. Most retention initiatives die not because they are bad ideas but because nobody could agree on how to measure whether they worked.

The Ratio That Matters Most

Nick Chasinov returns in Why Are Customer Acquisition Cost and Lifetime Value Important to Calculate? to explain the core tension that sits underneath all of this. He states that 'the money, time, staffing, and other resources used to acquire a new customer must be lower than that customer's lifetime value for the business to be successful.'

He suggests aiming for a 3-to-1 ratio between lifetime value and acquisition cost. If it costs you $1,000 to acquire a customer, you need at least $3,000 in lifetime value to have a sustainable business. I find this useful as a North Star because it forces product and marketing teams to have the same conversation instead of optimising in opposite directions.

The detail that landed hardest for me: '93% of people trust friends and family to obtain information about services and brands, while only 30% of consumers trust companies.' If you focus on retention, on making the product so good that people actually stay and tell others about it, you build the best acquisition channel that exists. Not an ad campaign. Not a growth hack. A product worth talking about. That is the cheapest customer acquisition cost there is, and the one least likely to show up in your marketing budget.

The Question I Keep Asking Myself

When I look at the products I have worked on, the honest answer is that I spent far more time on acquisition than retention. Most of us do. New users are exciting. Churned users are depressing. It is easier to celebrate a sign-up than to investigate a cancellation. But the math does not care about what is more fun to work on.

The practitioners I have quoted in this issue are not writing from corner offices. They are product managers, founders, and consultants who sat down and worked through the numbers because they were tired of watching their buckets leak. That is what Product Coalition exists for. Not the view from the top, but the lessons from the people doing the work.

When you look at your own product, are you spending more time trying to plug the holes in the bucket, or trying to find a bigger hose to fill it?

You're reading the Product Coalition newsletter. Every week, I dig into the archive of 3,500+ articles and 100+ podcast episodes to trace how product thinking has evolved. If someone forwarded this to you, subscribe here so you don't miss the next one.

Got a product story worth telling? Whether you're an exceptional talent shaping the future of product, or you've got a career journey others can learn from, I want to hear from you. Apply to be a guest on the Product Coalition podcast.

👋 Jay

Sources

Ant Murphy, Acquisition vs Activation and How to Predict Churn (Apr 2023); UXCam, How to Measure, Analyze, and Reduce App Churn (Jun 2022); Nick Chasinov, User Retention Defines Your Product's Success: Here Are 3 Ways to Improve It (Nov 2022); Scott Middleton, How to Calculate the Value of Your Retention Improvements (Mar 2022); Nick Chasinov, Why Are Customer Acquisition Cost and Lifetime Value Important to Calculate? (Jun 2023)

98% of PMs use AI daily, but only 39% have role-specific training. Beatrice led a major GA research survey of 117 PMs across US, UK, Canada, and Singapore. Episode covers the skills gap, shadow AI risks, vibe coding, and what AI can't replace.

Key topics

• Essential skills for future-proof PMs

• Safe AI experimentation practices

• Critical evaluation of AI outputs

Chapters

• 00:00 The Journey of Beatrice Partain

• 04:14 Future Proofing Product Management

• 10:36 Developing Skills Safely

• 13:22 Innovation vs. Governance in Product Management

• 16:29 The Human Element in AI

• 19:47 Lived Experiences in Product Management

• 23:46 Training for Product Management

• 26:54 Agentic AI in Daily Workflows

• 28:21 Personal Use of AI

• 34:40 Curiosity and Cultural Insights

Got a product story worth telling? Whether you’re an exceptional talent shaping the future of product, or you’ve got a career journey others can learn from — we want to hear from you. Apply to be a guest on the Product Coalition podcast: go.productcoalition.com/become-a-guest

And I hated it.

Not the articles themselves. Oh no. We had thirteen of them. Deep dives into Bayesian Knowledge Tracing, spaced repetition science, the psychometrics behind our scoring system. Real substance. We’d spent weeks during v1.4 writing rigorous science communication pieces. They explained why ExecReps works, not just that it works.

There they sat. Under a tab labeled “Blog.”

Blog. The word itself felt like an apology. ‘Here’s our blog, where we publish stuff sometimes, mostly to appease the SEO gods.’ Every startup has a blog. Every startup’s blog is mostly ignored. The word has been so thoroughly colonized by low-effort content farms that it now signals the opposite of what it used to mean. It signals noise.

I pulled up Gong’s website. ‘Gong Labs.’ Google’s research division. ‘Google Labs.’

It clicked. This was a conceptual model problem. Don Norman’s work on design shows this. The words you use create mental models that shape every interaction that follows. ‘Blog’ triggers one set of expectations. Opinion pieces, SEO filler. ‘Lab’ triggers an entirely different model. Experiments, data, discoveries. Same content. Completely different user expectation.

That distinction changed everything.

The Content Marketing Graveyard

Most founders get content wrong. I did, too, for a while. We treat our blog as a marketing channel. Write posts. Target keywords. Sprinkle in CTAs. Hope Google sends traffic.

This model? It’s broken.

AI-generated content has flooded the internet. Every B2B SaaS blog reads like it was written by the same middle-management chatbot. ‘In today’s fast-paced business environment…’ You’ve already stopped reading, haven’t you?

Cialdini’s research on social proof shows this. When everyone does something, doing it too doesn’t signal quality. It signals noise. A hundred identical B2B blogs create negative social proof. The presence of a ‘blog’ tab now means ‘we do what everyone else does.’

I wonder if this applies to other areas too. Like those ‘thought leader’ LinkedIn posts that all sound the same. It’s not just content marketing that’s broken. It’s the entire model of generic validation.

When we wrote our science communication articles for v1.4, something different happened. People didn’t just read them. They referenced them. A PM shared our Bayesian Knowledge Tracing piece in Slack. Someone bookmarked the spaced repetition article. These weren’t posts people skimmed and forgot.

If you think about Nir Eyal’s Hook Model, what was happening was subtle but important. The articles created what Eyal calls the Investment phase. Readers bookmarked them, shared them, built them into workflows. That investment loaded the next trigger. When a colleague asked ‘how does spaced repetition work?’, our article got pulled from someone’s bookmarks. Trigger → Action → Reward → Investment, repeating without us doing anything.

That was the signal I almost missed. The value wasn’t in content-as-marketing. It was in content-as-authority.

Why “Lab” Changes Everything

Words shape perception.

Any product team applying Norman’s design principles would recognize this. The label you put on something isn’t branding. It’s a UX decision that shapes every subsequent interaction.

When you see ‘Blog’ in a navigation bar, your guard goes up. You expect to be sold to. When you see ‘Lab,’ your predictions shift. You expect data, research, things that have been tested. Your guard comes down.

We made the switch in one commit. Changed the nav label. Added categories: Engineering, Voice, Science, Business Case. So the thirteen articles weren’t just a chronological feed. They were an organized body of research. We added search.

Small changes. But the positioning shift was massive. We weren’t a startup with a blog anymore. We were a research-driven company with a lab.

The thing I keep thinking about is this: your content should be a product, not a channel.

Gong Labs exists because Gong’s research on sales conversations is genuinely valuable on its own. Independent of whether you ever buy Gong. We asked ourselves: if ExecReps disappeared tomorrow, would The Lab still be worth visiting? If the answer is no, you’re doing content marketing. If the answer is yes, you’re building a research authority.

Building Calculators That People Use

The articles were a good start. But articles are still passive. You read them, you nod, you close the tab. I wanted something that would make the abstract cost of poor communication viscerally real.

This is where Don Norman’s Gulf of Evaluation was useful. The ‘gulf’ is the gap between what a system shows you and what you need to understand. Every HR leader knows bad communication costs money. But they can’t feel it. The cost is abstract, spread across thousands of hours nobody tracks. The gulf between ‘communication is expensive’ and ‘this costs your team $847,000 per year’ is enormous.

A calculator bridges it.

So we built three interactive calculators. Genuine analytical instruments, not lead-gen forms dressed up as tools.

The Communication Waste Calculator. Grammarly’s research shows knowledge workers lose 7.47 hours per week to poor communication. Our calculator lets you plug in your team size and average salary. It computes exactly how much miscommunication costs your organization annually. In dollars.

[SCREENSHOT: The Communication Waste Calculator interface showing sliders for team size and average salary, with a real-time output showing annual communication waste in dollars and hours, with the Grammarly citation visible below.]

The Meeting Tax Calculator. Microsoft’s Work Trend Index: 57% of work time in meetings. Atlassian: 72% of meetings considered ineffective. Our calculator combines these data points. A manager can see, in hard numbers, what their meeting culture costs.

The Coaching ROI Calculator. The International Coaching Federation found a median ROI of 700% on coaching investments. Most HR leaders I’ve talked to can’t articulate the return on their coaching spend. Our calculator makes that possible.

The critical product decision came from thinking about BJ Fogg’s B=MAP model. Applied to buying, not just using. In B2B, your internal champion has to convince their CFO. That’s a behavior. Motivation, Ability, and Prompt all at once.

The champion’s motivation is already high. But their ability to make the business case? That’s where it collapses. Composing the internal pitch means deciding what numbers to cite, finding credible sources, framing the ROI, writing the email. Five cognitive steps before ‘send.’ Fogg is explicit: reducing friction on the Ability chain is almost always more effective than increasing motivation.

So we designed the calculators as ammunition. A champion pulls one up in a procurement conversation. ‘Look, here’s what this costs us. And here’s the source.’ We eliminated the mental effort bottleneck.

The Citations Are the Point

I want to zoom in on something here. It matters more than most founders realize. We cited everything.

Every number in every calculator links to its source. Grammarly’s State of Business Communication report. Microsoft’s Work Trend Index. Atlassian’s research on meeting effectiveness. The ICF’s global coaching study. Specific studies, specific findings, specific data points.

This is Cialdini’s Authority principle in its purest form. Authority isn’t about claiming expertise. It’s about demonstrating evidence. Showing your work is more persuasive than showing your credentials. When someone follows your citations, checks your sources, and finds you represented them accurately, they trust you. Because you gave them reasons to.

Most startup content falls apart here. ‘Studies show communication training improves performance by 40%.’ Which studies? Whose performance? The vagueness is a tell.

When we published The Lab, an enterprise prospect replied: ‘This is the first time a vendor has shown me research I can verify.’ That single sentence justified the entire effort.

Content As Product, Not Decoration

The era of content marketing is ending.

Not because content doesn’t matter. But because the bar has risen past the point where ‘helpful blog post’ clears it.

Any PM who’s used the Kano Model would recognize what’s happening. Traditional blog content is a ‘must-be’. Expected and ignored. Interactive tools grounded in verified research are ‘delighters’. They exceed expectations. And Kano’s insight is that delighters create disproportionate satisfaction precisely because nobody expects them.

I wonder if this applies to product features too. What was once a delighter quickly becomes a must-have. It’s an optimization target. The moment something new appears, the market catches up.

Apply three tests:

Does it solve a real problem? Our Communication Waste Calculator arms an internal champion with a dollar figure they can take to their CFO.

Is it differentiated? Anyone can write a blog post about meeting culture. Very few companies build an interactive tool that lets you model your own meeting tax with data from Microsoft and Atlassian studies.

Will people return to it? A blog post gets read once. A calculator gets used every time someone builds a business case. That’s the retention principle at the core of the Hook Model. Content that creates a return loop compounds. Content that doesn’t, decays.

What I Got Wrong First

I should be honest. We didn’t arrive at this on day one. Our first content efforts were conventional. Write blog posts. Share on social media. Hope for traction.

The v1.4 science articles were a step in the right direction. Genuinely rigorous. But they were still passive. Still organized chronologically in a format that signaled ‘blog.’

The leap to The Lab required killing a mental model I’d carried for years. That content exists to serve the funnel. I’d internalized the playbook so deeply that I initially saw our calculators as ‘bottom-of-funnel conversion tools.’

They’re not. They’re standalone products.

Daniel Pink’s research on intrinsic motivation maps onto this. When you give people tools that serve their Autonomy (use it on their own terms), Mastery (understand their problem better), and Purpose (make the case for change), they develop a relationship with your work that no conversion funnel can manufacture.

You’d think creating tools useful without your product would cannibalize the need for it. In practice, it does the opposite. Cialdini calls this Reciprocity. Genuine, unconditional giving creates obligation that no sales email can replicate. You build trust not by convincing people, but by helping them.

The Uncomfortable Truth About Authority

In the space we’re building in, communication, executive presence, voice coaching, there’s enormous noise. LinkedIn influencers selling ‘10 phrases that make you sound like a CEO.’ YouTube videos promising to ‘fix your voice in 7 days.’ Quick fixes from people who’ve never read a peer-reviewed study.

The people we’re building for, professionals told they ‘talk wrong,’ passed over because of an accent, they’ve been burned by quick fixes. They need to trust that what we’re building is grounded in something real.

The Lab is how we earn that trust. Not by saying ‘trust us.’ By saying ‘here’s our evidence, here are our sources, here’s a tool you can use yourself to verify the problem is real.’

Every time I look at The Lab, I think about that design agency phone call. ‘We can’t employ people who talk like you.’ A blog post telling them they were wrong wouldn’t have changed anything. But a calculator showing them exactly how much communication bias costs their organization? That might make them pause. Kahneman and Tversky’s research on loss aversion tells us people feel losses roughly twice as intensely as equivalent gains. A dollar figure attached to communication waste makes that loss tangible in a way no argument about fairness ever could.

Research doesn’t just build authority. It builds the case for change.

If we’re serious about the mission, that executive presence should not be a privilege, we need to be serious about the evidence that proves why it matters.

That’s why we killed our blog and built a lab. Not for the branding. For the mission.

What does this mean for every other startup with a ‘blog’ section? I wonder if the next wave of ‘content’ will look less like articles and more like tools.

“Jay, can I see your security architecture?”

She didn’t ask, “do you have SOC 2?” She didn’t ask “are you GDPR compliant?” She wanted to see the architecture. The actual policies. The scanning pipeline. How data flows and who can touch it.

I pasted a link into the chat: execreps.ai/security.

Thirty seconds of silence stretched.

Then: “Okay. This is more than I expected.”

That page is why I’m writing this post. Building security as a first-class product feature, not a compliance afterthought, has been one of the highest-ROI investments I’ve made. I even built it when I was a team of one.

Don Norman would recognize what happened on that call. The buyer had a ‘Gulf of Evaluation’. She needed to answer, “Can I trust this vendor with my company’s data?” Most startups force buyers to dig through questionnaires and schedule follow-ups to close that gap. A public security page closes it in thirty seconds.

The First RLS Policy (October 2025)

Back in October 2025, I shipped v0.5 of ExecReps. The product was barely functional. People could record themselves practicing a presentation, get AI feedback, track their scores. Maybe two dozen active users.

That release included Row Level Security across six database tables.

If you’re not a backend engineer, Row Level Security means the database itself enforces who can see what. It isn’t application logic saying ‘don’t show User A’s recordings to User B.’ It’s the database saying ‘this row does not exist for you.’ Even if someone bypasses the API, even if there’s a bug in the code, the database won’t hand over data that doesn’t belong to you.

Overkill for two dozen users? Absolutely.

The thing I understood, after fifteen years of product work, was this: security debt compounds faster than any other form of technical debt. Kahneman and Tversky’s research on loss aversion explains why. Losses are felt roughly twice as intensely as equivalent gains. You can refactor a messy UI. You can optimize a slow query. You cannot un-leak data. A breach isn’t a setback you recover from. It’s a loss your users feel viscerally. That asymmetry makes early security investment disproportionately valuable.

Six tables. Every query filtered by the authenticated user’s ID. A day and a half of work that’s paid for itself a hundred times over.

The Recursion Bug That Almost Ruined Everything

You might expect this part to be smooth. It wasn’t.

When I started building team functionality, managers seeing team data, admins needing org-wide visibility, the original RLS policies became a problem. The naive approach was policies that check team membership by joining against the teams table. Which had its own RLS policies. Which tried to check membership. Which queried the teams table again.

Infinite recursion. In the database layer.

Supabase doesn’t give you a helpful error for this. The query just… dies. I spent an evening staring at Postgres logs, convinced I’d broken my approach.

The fix was security definer functions that bypass RLS for specific trusted operations, restructured team membership verification, and extreme deliberation about which policies reference which tables. Sounds simple in a blog post. Had me questioning my life choices at midnight on a Thursday.

The critical part, though, was this: I found the bug during development, not in production. Nielsen’s Error Prevention heuristic (H5) says the best error message is no error message. The best data breach is one that’s structurally impossible. Because the RLS foundation already existed, I was forced to solve multi-tenant complexity before real enterprise data was at stake. If I’d waited, if I thought ‘we’ll add security later when we have enterprise customers,’ I’d have been retrofitting access control while actual company data flowed through the system.

That is exactly how breaches happen.

Building the Wall Higher (v2.4)

v2.4 is ‘Enterprise Security Hardening’. It’s the release that transformed our security story from ‘solid foundation’ to ‘genuinely enterprise-grade.’

Product teams who use the Kano Model know the categories: must-be, performance, and delighter. For enterprise buyers, security is firmly must-be. Absence kills a deal instantly, but presence alone doesn’t win one. What wins is when the implementation exceeds expectations. When a must-be quality is delivered at a delighter level, buyers notice.

On every pull request, we now run these checks:

Semgrep. This is Static Application Security Testing, scanning for vulnerability patterns like SQL injection, XSS, insecure auth patterns, and hardcoded secrets. Every PR, every time.

Gitleaks. This scans for accidentally committed secrets: API keys, tokens, passwords. Because sooner or later someone (or some AI, I’ll come back to this) pastes a token in a config file.

Dependency auditing. Every npm package is checked against known vulnerability databases. A critical CVE? The build fails.

Content-Security-Policy headers. These tell the browser exactly which domains can execute scripts, load images, or open connections. Most startups don’t implement this until past Series B.

Aikido DAST integration. This is Dynamic Application Security Testing, monitoring the running application. It probes endpoints, tests real-world attack vectors, and reports continuously.

The /security page itself ties it together. A public, human-readable overview of everything above. Not a compliance PDF. A web page that an IT buyer can read, share with their team, and use to make a procurement decision. Norman’s Gulf of Evaluation and Gulf of Execution, closed simultaneously. Buyers can evaluate without scheduling a call, and act by forwarding the URL to their CISO, without needing us in the room.

The AI Engineer Problem

Something I haven’t seen discussed much is this: what happens when one of your engineers is an AI?

I use Devin, an AI software engineer, for significant portions of development. Devin is remarkably capable. Clean code, follows patterns well, handles complex refactoring. Devin doesn’t have security intuition, though. It doesn’t think ‘this input should be sanitized.’ It won’t instinctively avoid hardcoding a token in a test file.

BJ Fogg’s B=MAP model describes the AI security problem perfectly. Devin has high ability to write code and zero motivation around security, no concept of consequence. There’s no built-in ‘prompt’ for ‘check for vulnerabilities before you commit.’ The SAST pipeline becomes that prompt. Devin opens a PR, scanners run, a vulnerability is found. The build fails. Period.

It’s not about trusting or not trusting the AI. Human engineers ship vulnerable code too. Security automation doesn’t care about intent. It enforces rules. Like guardrails on a mountain road. They aren’t there because you’re a bad driver. They’re there because the cliff doesn’t care how good you are.

Not sure where the industry lands on this in a year or two. I had a podcast guest recently who was convinced AI-written code would be more secure than human-written code within 18 months. Maybe. The scanning pipeline doesn’t care either way.

Feature Flags as a Security Mechanism

One surprise from v2.4: feature flags became a security tool.

We built an admin UI for feature flags, turning features on or off for specific users, teams, or globally. The obvious use is gradual rollouts.

Feature flags also give you a kill switch. Vulnerability in a feature? Disable it in seconds. No emergency hotfix, no midnight deployment. Toggle it off.

Norman would call this a strong affordance. The toggle looks like instant control because it is instant control. For a solo founder without a 24/7 on-call rotation, mean time to mitigation drops from ‘however long it takes to write, test, and deploy a fix’ to ‘however long it takes to click a button.’

Enterprise buyers get this immediately. “Any feature can be instantly disabled without a deployment” translates to “if something goes wrong, it gets fixed immediately.” That’s not just a product feature. That’s a purchasing decision.

Security as Moat

I think many startups miss the mark on this: they treat enterprise security as compliance theater.

The scramble for SOC 2 before the first enterprise deal. The ‘we take security seriously’ banner on a website with Access-Control-Allow-Origin: * in production. The security questionnaire answered by Googling in real-time.

Cialdini’s research on Authority explains why this fails. Authority isn’t claimed, it’s demonstrated. Telling a buyer ‘we take security seriously’ is a claim. Showing them automated scanning pipelines and row-level data isolation is a demonstration. The buyer’s brain processes those inputs completely differently.

Security is a competitive moat. Not because your competitors can’t build it, but because they won’t. It’s unglamorous. It doesn’t move metrics VCs ask about. Nobody tweets about CSP headers.

Enterprise buyers, the ones writing the big checks, care a lot. The gap between ‘we’ll get to security eventually’ and ‘here’s our security architecture, publicly documented’ is enormous in their eyes.

I’m a solo founder competing against funded teams. I shouldn’t be winning security conversations. But when the review happens, I’m not scrambling. I’m sending a link.

What This Costs

The SAST pipeline runs in GitHub Actions. A few hours to configure, almost no ongoing cost. Aikido has a generous startup tier. CSP headers: half a day. RLS policies: three to four days across iterations. The /security page: an afternoon.

All in? Maybe two weeks of engineering time over five months.

This is loss aversion math in your favor. Enterprise buyers overweight security risk. Two weeks of your work neutralizes months of their perceived risk. Compare that to losing a deal over a question you can’t answer, or spending three months rushing SOC 2 because a prospect demanded it. I wonder if this kind of upfront investment is often undervalued by founders focused solely on new feature velocity.

The Deeper Connection

I think about why I care this much about security for a communication practice tool. ExecReps isn’t handling financial data or medical records. We hold voice recordings of people practicing presentations, pitch rehearsals, feedback conversations.

That’s exactly why it matters.

Someone records themselves practicing a difficult conversation. Asking their boss for a raise, rehearsing for a board presentation, delivering bad news. That’s vulnerable. That’s someone exposing the gap between where they are and where they want to be.

Deci and Ryan’s Self-Determination Theory identifies three needs for intrinsic motivation: autonomy, competence, and relatedness. The prerequisite, though, is psychological safety. You can’t pursue competence if you’re afraid of being exposed. The practice loop that makes ExecReps work, record, get feedback, improve, repeat, only functions when users trust the container.

Executive presence should not be a privilege. The willingness to practice it, though, requires trust. Trust requires infrastructure, not just promises.

A Question for Builders

If you’re building a product right now, especially if you’re thinking ‘we’ll handle security later,’ ask yourself:

What would it mean for your customers if their data leaked tomorrow? Not legally. What would it mean for them?

The answer tells you when to invest. For many of us, it probably should have been yesterday.

The good news: ‘yesterday’ is closer than you think. A few days of intentional work now can be worth months of panic later.

Security isn’t just a phase of your product development. It’s a core feature. It’s probably worth building like one.

Brought to you by ExecReps — AI-powered executive coaching for product leaders. Product Coalition members get extended access.

The Convert Era (2016–2017)

In 2016, Amit Badlani came out of Stanford’s d.school and wrote about it like someone who’d found religion:

“The design thinking framework has helped me traverse the problem space and stay patient. Design thinking is all about iterating. It is not a magical process that guarantees solutions to the challenging problems. It will, however, lead you to the right answers eventually.”

“Lead you to the right answers eventually.” That’s pure faith. And I don’t mean that dismissively. If you’d gone through that program in 2016, you probably felt it too. The prototyping, the reframing, the permission to throw your first idea away. It felt new.

By 2017, demand had outrun supply. Yasith Abeynayaka built a self-study guide for people who couldn’t get to Palo Alto, calling design thinking “a mandatory skillset” for professionals. The d.school-to-IDEO-to-Google-Ventures pipeline was becoming the canonical path. If you cared about product, you were supposed to care about this.

The Bumper Sticker Problem (2019–2021)

Then the sloganization kicked in. Sefi Keller wrote a piece in 2019 that I keep coming back to:

“The problem is that as time goes by, many people find it hard to unpack the depth behind the idea’s ‘sticker version’ and might dismiss it altogether.”

She was talking specifically about empathy, and how it had been reduced to a step on a diagram. Her point was subtle and important: the people who created design thinking made it catchy on purpose, because leaders need bumper stickers to rally teams. But catchy eats nuance for breakfast.

Meanwhile, by 2021, Nathan Mckinley was writing five-stage explainers citing Apple, Disney, IBM, and Microsoft as proof that design thinking worked. Stanford teaches it. Harvard endorses it. This was DT at its most institutional, and maybe its most hollow.

“You Can Learn 90% of It in Five Minutes” (2023)

The backlash didn’t arrive as a single takedown. It crept in.

Lee Fischman wrote a piece in 2023 that basically said the quiet part out loud:

“The Design Thinking folks say ‘It’s method, not magic’ and they’re right, but I’d go one step further: it’s obvious and you already do it.”

His framing: before design thinking, design was a priesthood. After, it was democratized. Involve diverse people. Iterate. That’s it. The $3,000 MIT certificate was teaching you something you probably already knew.

Jackie Colburn published a workshop guide that same year acknowledging what everyone felt: people have been “burned in the past by inefficient, unproductive, and boring sessions that feel like a waste of time.” We’d turned design thinking into a calendar invite people dreaded. Post-Its were still there. The magic wasn’t.

The Quiet Dissolution (2024)

Here’s what surprised me. I pulled up Connor Joyce’s 2024 piece on building AI products, expecting at least a nod to design thinking. Nothing. The whole article is about LLM integration, deployment strategy, user outcomes. The closest you get is “just because it’s powerful doesn’t mean it’s the answer for everything,” which is basically empathy wearing different clothes.

Design thinking didn’t die dramatically. Nobody published a eulogy. It just… stopped being named. The principles got absorbed into how competent teams work. Table stakes now, not a framework.

What I’m Hearing on the Podcast

Rachel Wolan, CPO at Webflow, came on the show recently and put it well: “Human creativity remains vital in the design process, even with AI automation.” She never used the phrase ‘design thinking.’ She didn’t need to. The human-centered instinct is still there. It’s just no longer branded.

So What Actually Replaced It?

I’m not sure anything replaced it so much as the industry grew out of needing a name for it. The best PMs I talk to empathize with users, prototype quickly, iterate constantly. They just call it product management.

Maybe design thinking succeeded so completely it became invisible. Or maybe we just got tired of the Post-Its.

What’s your read? Did design thinking win by dissolving, or did we just collectively agree to stop talking about it? Reply and tell me. I genuinely don’t know the answer.

You’re reading the Product Coalition newsletter. Every week, I dig into the archive of 3,500+ articles and 100+ podcast episodes to trace how product thinking has evolved. If someone forwarded this to you, subscribe here so you don’t miss the next one.

Jay Stansell · Lisbon, Portugal · Product Coalition

“My entire leadership team needs this. Can I buy ten seats? Also, I need to see their scores. Is that possible?”

I remember reading it twice. Then I closed my laptop. I walked out the door and headed along the Tagus River here in Lisbon, because I knew what those four sentences meant.

They meant the hardest product decision I’d ever have to make was no longer theoretical.

It was time to build for teams.

The Graveyard of Products That Went Team Too Early

If you’ve been in product long enough, you’ve seen this movie play out. A product works beautifully for individuals. Users love it. Then someone says the magic words: “We need to go multi-seat.” And often, the product dies. It doesn’t happen overnight. It dies slowly. The dashboard gets cluttered with admin panels. Onboarding asks seventeen questions about org structure before you can even do anything useful. The individual user, the one who loved your product, suddenly feels like they’re using enterprise software.

The Kano Model explains why this often kills products. The individual experience, the thing that created genuine excitement, is what Kano would call the ‘attractive quality’. Team features, though, are ‘must-be’ qualities: admin panels, permissions, billing. They don’t generate delight. They just prevent dissatisfaction. If those ‘must-be’ features degrade the ‘attractive quality’, you’ve traded the very reason people cared for infrastructure nobody loves.

With ExecReps, the stakes felt even higher. This is a product where people practice speaking. Out loud, vulnerably, sometimes badly. That requires psychological safety that most team software never even considers.

The First Attempt: v0.6 and the Flat List

Back in October 2025, we shipped v0.6. These were our first team accounts. It was basic. A team owner could invite members via email, see aggregate analytics, and manage billing through Stripe.

It worked. Just barely. But within weeks, the feedback exposed every assumption we’d made.

“Can my team members see each other’s scores?” We hadn’t decided.

“We have regional sub-teams. Can I create groups within the team?” No.

“I want to add thirty people at once.” You’ll need to type thirty email addresses, one at a time.

“I manage two teams: product and design. Can I be in both?” Also no.

Every one of those questions was a canary in the coal mine. In Don Norman’s language, we had a massive conceptual model mismatch. We’d built a mental model of ‘team’ that meant ‘flat list of people under one admin’. Our users’ mental model was messy, overlapping, hierarchical, and fluid. Because that’s how organizations operate. The Gulf of Execution, the gap between what users wanted to do and what our interface let them do, was enormous.

The Privacy Problem Nobody Mentions

What makes ExecReps different, what makes the team pivot entirely different from adding team features to a design tool or a project tracker, is this:

When someone practices a high-stakes conversation, maybe a board presentation or a salary negotiation, they’re being vulnerable. They’re getting feedback that says their pace is too fast, they use “um” forty-seven times, their confidence score is 520 out of 1000. That data is intimate. Now imagine their manager can see all of it.

Kahneman and Tversky’s loss aversion research is painfully relevant here. The fear of losing something, like privacy or psychological safety, is roughly twice as powerful as the motivation to gain something, like a better score or team recognition. If a team member even suspects their boss can see a bad session, the fear of exposure outweighs any motivation to practice. They’ll stop using the product. Or worse, they’ll only practice things they’re already good at.

The VP of L&D who emailed me? She needs to see her team’s progress. That’s the entire value proposition for an enterprise buyer. She’s spending budget. She needs ROI.

But the individual needs to feel safe enough to be bad at something.

Our solution:

Aggregation is the answer.

Managers see trends, not transcripts. They see that someone’s EPS has improved 15% over the last month, not that they bombed a specific practice session on Tuesday. They see engagement patterns, who’s practicing regularly, but not the content of what anyone practiced. The individual owns their detailed data. The team sees the trajectory.

Deci and Ryan’s Self-Determination Theory says people need autonomy, competence, and relatedness to stay intrinsically motivated. Full transparency to managers kills autonomy. Our aggregation model preserves it. The member controls what they practice and when, and their boss sees only the trajectory of growth, not the vulnerable process behind it.

It’s the difference between a fitness tracker that tells your boss you worked out three times this week, versus one that shows them the video of you wheezing on the treadmill. I wonder if there’s an equivalent in other domains, like a coding practice tool. Would a manager want to see every syntax error, or just the overall improvement in code quality?

v2.1: Making Teams Find Themselves

By March 2026, we were ready for the real team rebuild. The first thing we tackled was the most fundamental question: How do teams form in the first place?

In most enterprise tools, team creation is top-down. An admin buys seats, manually invites people, and assigns them to groups. From a BJ Fogg B=MAP perspective, it’s an ability disaster. Every email address the admin has to type is friction. We saw this firsthand: admins who bought ten seats would invite three people, get distracted, and never finish.

We built domain-based team discovery instead. When you sign up with your work email, say sarah@acmecorp.com, we check if there’s already a team associated with the acmecorp.com domain. If there is, you see it. You can request to join. An admin approves. No invitation needed.

This sounds simple. It was not simple. Domain matching has a hundred edge cases: personal Gmail addresses, multiple company domains, embedded consultants. The perfectionist in me wanted every edge case solved before shipping. The product manager in me knew domain matching would cover 80% of signups.

We saw immediate change. An L&D manager would sign up, invite three people, and within a week we’d see twelve more from the same domain requesting to join. Any product team familiar with Cialdini’s social proof research would recognize what was happening. “Your teammates are already here” did the selling for us.

We also built multi-team membership with a sidebar switcher. The real world isn’t a neat org chart. People belong to functional teams, project groups, and leadership cohorts. Forcing single-team membership tells your users you don’t understand how they work. Nielsen’s “Match Between System and Real World” heuristic is clear: the system should reflect how people organize, not force them into the system’s preferred structure.

v2.3: When “Enterprise” Stops Being a Dirty Word

Two weeks later, we shipped v2.3. This was enterprise team management. Flat team lists work for ten people. They break at fifty. They’re laughable at five hundred. We built nested team hierarchies with unlimited depth.

‘Unlimited depth’ scared me a bit. Every product instinct says to constrain. The moment you say “maximum three levels of nesting,” someone’s org chart has four. And you’ve lost the deal.

Bulk onboarding was the other critical piece. That VP of L&D didn’t want to type thirty email addresses. She wanted to paste from a spreadsheet. So we built multi-email paste (smart parsing for commas, semicolons, newlines) and CSV import for larger teams.

This is pure BJ Fogg Ability Chain work. Fogg identifies six friction factors: time, money, physical effort, mental effort, social deviance, and non-routine. Typing thirty emails one-by-one fails on three of six. CSV import collapses the entire action into a single file upload. We didn’t increase the admin’s motivation to onboard their team. We made the behavior so easy that their existing motivation was enough.

Nobody writes blog posts about CSV import. It’s the difference between a product that can be used by teams and one that teams adopt.

The Security Audit That Changed Everything

During the v2.1 build, we ran a security audit. This is standard practice when you’re building team features. You’re now handling data relationships between users, and that’s often where vulnerabilities hide.

The audit found an XSS vulnerability. Someone could inject malicious code through a team name or display name, and it would execute in other users’ browsers. In an individual product, the blast radius is limited. In a team product, one compromised input affects every team member who views that page.

We fixed it immediately. It changed how I thought about the entire architecture. We implemented timing-safe token comparisons for join requests and hardened every data input that crossed team boundaries.

The team pivot reveals hidden technical debt. If you’re making this pivot, audit everything. Assume every user input displayed to another user is an attack vector.

The Product Lesson: Individual Magic Is Your Moat

If you’re a founder or PM standing at the edge of the individual-to-team pivot, I’d tell you this:

The individual experience is not a stepping stone to the team product. It IS the team product.

Nir Eyal’s Hook Model makes this concrete. The hook loop: trigger, action, variable reward, investment, lives entirely at the individual level. The trigger is a morning prompt to practice. The action is completing a workout. The variable reward is the AI feedback that surprises you with a specific insight. The investment is the data that accumulates in your profile, making the next session more personalized. Every piece of that loop belongs to the individual user. The team layer doesn’t create a new hook. It amplifies the existing one by adding social proof (“your teammates practiced today”) and Daniel Pink’s relatedness dimension (“you’re growing together”).

Every feature we built for teams is worthless if the individual hook isn’t working. A manager can buy fifty seats. If the individual user doesn’t feel safe, doesn’t see improvement, doesn’t find each practice session genuinely valuable? Usage drops to zero within a month and the contract doesn’t renew.

The team layer should be a window into individual value, not a replacement for it.

I’ve seen products get this backwards. They build the admin panel first, the reporting first, because that’s what the buyer asks for. In Norman’s terms, they collapse the Gulf of Evaluation for the buyer at the expense of widening the Gulf of Execution for the user. The admin gets beautiful dashboards. The user gets a worse product.

Don’t let the buyer’s requirements cannibalize the user’s experience.

Where We Are Now

We’re eight months past that first “can I buy ten seats?” email. We’ve gone from a flat member list to nested enterprise hierarchies, domain discovery, multi-team membership, bulk onboarding, and engagement analytics that give managers what they need without exposing what they shouldn’t see.

When an individual user opens ExecReps and starts practicing, it still feels like the same product. Intimate. Safe. Focused on them.

I’m not sure if we’ve gotten it perfectly right. Every week I talk to a team admin who wants more visibility and a team member who wants more privacy. I think that tension is the point. The moment you resolve it fully in either direction, you’ve built something that serves half your users at the expense of the other.

The best team products hold that tension. They don’t resolve it. They design around it.

In 2017, Kate Bennet surveyed 50 product managers on Product Coalition and found something that should embarrass the entire industry. “In 46% of respondents’ companies the leadership team or head of product decide what will be built next. Only 13% of product managers have the authority to decide themselves.”

Gut feel and CEO preference were each cited by about 43% of respondents as inputs to what gets built. We invented an entire profession around deciding what to build, then gave the actual decision to someone else.

Since then, the framework machine has been working overtime. RICE. MoSCoW. Kano. WSJF. ICE. Opportunity scoring. Value vs. Effort matrices. Jordan Lamborn reviewed over 100 of them on Product Coalition and found they almost all share the same blind spots. “Unsurprisingly, some type of value is the most prevalent [factor]. This includes anything like impact, benefits, or return. Second place is the effort category.”

Over 100 frameworks, and most of them are just impact-vs-effort wearing a different hat. The variables that actually matter, customer centricity, confidence in your hypothesis, strategic alignment, barely show up.

Carlos Gonzalez de Villaumbrosia walked through the textbook trio in 2020, but even he acknowledged the limits: “So much of Product Management has to be unscientific. Although data should be used as much as possible, sometimes you have no choice but to rely on intuition and gut-feeling.”

I think he is right that gut feel is unavoidable. But the gut feel needs guardrails. Garrett Rysko made the counter-argument on Product Coalition and called it the McClane Mentality, after John McClane from Die Hard. PMs shooting from the hip, hoping nothing explodes. “When you’re working on a portfolio worth millions, with employees’ jobs banking on the success of your product, your decisions need to be as informed as possible.”

Fair point.

Here is what I think the framework conversation consistently misses. Every feature on your roadmap is an investment, and the cost goes well beyond the sprint points.

Caio Flores wrote about this on Product Coalition: “It’s easy to think that the lack of features is causing your startup to not grow enough, but remember that you have an infinite number of variables that could be causing that.” The instinct is always to add. Build feature X and Y, then growth happens. Except sometimes you have the wrong market, wrong timing, or wrong value proposition entirely, and no feature fixes that.

Hans-Jörg Roser pushed this further, pointing out that even sophisticated frameworks like WSJF miss the downside: “Also a new risk is created! Think for example of IT systems that could lead to new security aspects or simply the risk that comes with the future maintenance you have to do for a software feature.” Every feature you ship creates new liabilities. Security surface. Maintenance burden. Complexity that compounds quietly until it doesn’t.

John Utz was blunt about what this actually feels like: “The pain of prioritization almost made me quit.” No framework removes the emotional cost of telling someone their idea did not make the cut. That part is on you.

Margaret-Ann Seger said something on my podcast that keeps nagging at me: “Empowering teams leads to better outcomes than top-down mandates.” If the CEO is still picking what gets built, no RICE score will save you. You are just laundering someone else’s opinion through a spreadsheet.

The PMs I have seen get this right don’t treat prioritization as a feature-ranking exercise. They treat it as capital allocation. Each item on the roadmap has an expected return, a risk profile, and a maintenance cost that extends years past launch. When you frame it that way, the conversation changes. You stop asking “what should we build next” and start asking “where should we invest, and what is the cost of being wrong.”

What does your team actually use to prioritize? And does it work, or is it theater? Hit reply and tell me. I am genuinely curious whether anyone has cracked this.

Sources: Kate Bennet - “Product Prioritization by the Numbers” (Nov 2017), Jordan Lamborn - “Throw Away Your Prioritization Framework” (Feb 2021), Carlos Gonzalez de Villaumbrosia - “3 Prioritization Techniques” (Jan 2020), Garrett Rysko - “McClane Mentality” (Oct 2021), Caio Flores - “The Real Cost of Adding a New Feature” (Aug 2020), Hans-Jörg Roser - “Feature Prioritization: Apply the Highest Counter-Value First” (Sep 2022), John Utz - “It Means Saying No” (Sep 2024), Margaret-Ann Seger - Product Coalition Podcast EP98. All published on Product Coalition.

Brought to you by ExecReps — AI-powered executive coaching for product leaders. Product Coalition members get extended access.

When ‘Ping Them Again’ Was the Plan (2019)

Before anyone was saying ‘product-led retention,’ the playbook was straightforward. A 2019 Product Coalition editorial on app retention laid out the accepted wisdom:

“A good onboarding experience can improve retention by up to 50%.”

The toolkit: onboarding flows, push notifications, personalization, re-engagement campaigns. Nudge the user. Remind them you exist. Hope they come back.

It wasn’t wrong. But it treated retention like a marketing problem. The question was always ‘how do we get them to open the app again?’ Nobody was asking ‘why did they close it?’

The Structural Turn (2018–2020)

The smarter thinking was already percolating. In 2018, Rob Finney wrote about network effects using the VHS vs Betamax story:

“What I had witnessed was a platform based network effect kicked off by a small advantage. The small advantage was then accentuated by a positive feedback loop.”

A system where more users equals more value equals less reason to leave. Retention was becoming structural, not tactical.

Then 2020 cracked things open. Carlos Gonzalez de Villaumbrosia named the shift to PLG: “It’s getting easier to build a business, but not easier to grow one.” When competitors replicate your features in six months, the product itself has to be the retention engine.

But my favorite retention concept in the entire archive came from Derek Skaletsky that same year. He’d built a search engine with genuinely excellent tech. Users kept churning after 90 days. His diagnosis was brutal: “Search is the most perishable activity on the web. You search for something, find your answer, and… close the tab.”

His conclusion? When users pour their data, workflows, and routines into your platform, switching feels like losing a part of yourself. He called this the ‘All My Shit’s In There’ factor. Still the most honest description of SaaS retention I’ve read.

The Number That Stops You Cold

That same year, Dennis Meisner pulled the Amazon Prime data:

“A stunning 93% of Amazon Prime members renew their subscription after the first year. After the second year, this number goes up to an incredible 98%!”

98%. By year two, Prime isn’t competing for your loyalty. It has become infrastructure. You don’t cancel your water bill. That’s the endgame of retention done right: you stop being a product and start being a utility.

From Tool to Infrastructure (2024–2025)

Lee Fischman wrote in 2024 about maintaining 90%+ B2B retention, and his framing was disarmingly simple: “The first reason our retention was so high was simply because customers needed our stuff. When they didn’t, they cancelled.”

No growth hacks. Just be so embedded in your customer’s context that removing you requires rewiring how they work.

Then Asher Atlas wrote in 2025 about a retention crisis when a music service lost its catalog overnight. His team’s reframe changed everything: “What if this isn’t a search problem? What if this is a discovery problem?” They turned a broken search into a trust-building experience. Retention, it turns out, lives in how you handle the moment when things go sideways.

What I’m Hearing on the Podcast

Nesrine Changuel (ex-Google, Spotify, Microsoft) came on the show and pushed this further. Her argument: “User loyalty is significantly enhanced by emotional connections.” The products people stay with longest are the ones they genuinely love, not just the ones they can’t figure out how to export their data from.

(Listen to EP82 with Nesrine Changuel)

So Where Does This Leave Us?

The arc is clear if you step back far enough. Retention went from ‘remind them you exist’ to ‘make leaving expensive’ to ‘make them not want to leave at all.’ I think most teams are still stuck in the ping-them-again era, measuring retention without asking what’s actually retaining people.

If your retention strategy starts with ‘how do we reduce churn,’ you might be asking the wrong question. The better one: why would someone choose to stay?

Reply and tell me where your team sits on this spectrum. I’m genuinely curious whether the AMSIT factor resonates, or if you’ve found something completely different keeping people around.

You’re reading the Product Coalition newsletter. Every week, I dig into the archive of 3,500+ articles and 100+ podcast episodes to trace how product thinking has evolved. If someone forwarded this to you, subscribe here so you don’t miss the next one.

Jay Stansell · Lisbon, Portugal · Product Coalition

Then I hit delete.

That single action, hitting delete, was one of the best product decisions I’ve made on ExecReps. Maybe it’s also the most contrarian thing I’ll write in this entire series.

The Seduction of the Easy Answer

Nobody talks about this in product right now. LLMs have become the new ‘just throw it in a database.’ Every feature. Every recommendation. Every personalisation decision. The default instinct in 2026 is to ask a model. I get it, I’ve done it too. ExecReps uses GPT–4 for assessment, and it’s brilliant there.

But recommendations are a different beast.

When we started planning personalisation, that moment a user logs in and sees curated practice scenarios instead of a generic wall of content, the temptation was overwhelming. Embed the user’s profile. Embed the content. Cosine similarity. Done. Ship it. Put ‘AI-powered recommendations’ on the marketing site.

Except I kept hitting one problem I recognized from Don Norman’s work. I couldn’t explain why the model would recommend what it recommends. Norman calls this the Gulf of Evaluation, the gap between what the system did and why it did it. I wonder if this is the biggest long-term trust issue with LLMs. When your user can’t bridge that gulf, you’ve built a black box. They’ll eventually stop trusting it.

The Explainability Problem Nobody’s Solving

In EdTech, and executive coaching is EdTech even if we don’t always dress it that way, recommendations aren’t like movie suggestions. If Netflix recommends a mediocre rom-com, nobody gets hurt. You scroll on.

If ExecReps recommends the wrong practice scenario to someone preparing for a board presentation next Tuesday, and they spend their limited practice time on a scenario that doesn’t stretch the right muscles? That’s someone’s career development time wasted. I was talking to a product leader last week, and he mentioned how frustrating it is when ‘AI’ gives him generic suggestions. He just wants to know why. So when they ask ‘why did the platform have me practice this?’, ‘well, the embedding similarity was high’ isn’t an answer.

Any product team that’s applied Nielsen’s Heuristics knows this tension. His sixth heuristic, Recognition over Recall, says users should never have to guess why the system made a decision. They should see the reasoning. With an LLM, the honest answer was we couldn’t show it. With math, we could.

Nir Eyal’s Hook Model shaped our thinking too. The Hook cycles through Trigger → Action → Variable Reward → Investment. In a coaching context, the variable reward needs to feel earned and understood, not random. If users can’t connect the recommendation to their own growth, the reward loop breaks. The thing I keep coming back to is this. We needed variability in the content surface, yes, but not opacity in the logic underneath.

Five Factors, Zero Magic

So we built what I now think of as the honest recommendation engine. Five scoring factors. Each weighted. Each grounded in learning science. And each, I’d later realize, maps to established behavioral frameworks that any product team would recognize:

1. Content Relevance. Does this scenario match what you need to practice? A structured mapping between your stated goals, your role, your industry, and the content metadata we’ve tagged on every scenario.

2. Difficulty Match. Straight from Vygotsky’s Zone of Proximal Development, which anyone who’s studied Csikszentmihalyi’s Flow theory will recognize. Optimal challenge sits just beyond current ability. Daniel Pink calls this the Mastery component of his Drive framework, the intrinsic pull toward getting better at something that matters. The engine doesn’t just serve content. It serves the right difficulty to keep users in that Flow channel.

3. Skill Gaps. Where are you weakest relative to where you need to be? If your scores show strong Command but shaky Eloquence, the system pushes you toward scenarios demanding clarity and articulation. The Kano Model would call this ‘must-be’ quality. Users expect a coaching platform to know where they need work. Not a delighter. Table stakes.

4. Recency. When did you last practice a particular skill area? Spaced repetition works. Kahneman and Tversky’s research on memory availability tells us the same thing from a different angle. Recently practiced skills feel more accessible than they are, creating an illusion of competence the system needs to counteract.

5. Diversity. This one’s mine, not from any textbook. I kept noticing in user testing that people got stuck in loops, practicing presentations over and over because that’s what felt comfortable. From a Hook Model perspective, this is where variable reward design becomes critical. Eyal is explicit: predictable rewards lose power. The diversity factor nudges you into unfamiliar territory. Difficult conversations, upward feedback, client escalations. The things you avoid are often the things you need most.

Each factor produces a normalized score. The weighted combination gives us a final ranking. No black box. Every recommendation traces back to defensible reasoning. ‘We recommended this because you haven’t practiced delivery skills in 12 days, this scenario is one level above your last difficulty rating, and it targets the dimension where your gap is widest.’

Norman would call that bridging the Gulf of Evaluation. Nielsen would call it Visibility of System Status. I just call it treating adults like adults.

141 Skills Walk Into a Bar

Let me be honest about a mistake here. It’s one that any PM who’s read Norman’s work on conceptual models should have seen coming.

When we first built skill tracking, I let users self-report their target skills. Free text. ‘What skills do you want to develop?’ Very user-friendly. Very product-manager-who-reads-too-many-UX-books, me included.

We ended up with 141 unique skills in the database. Think ‘Executive presence.’ Then ‘Executive communication.’ Then ‘Presence in meetings.’ Then ‘Being more present in executive meetings.’ Four users, four entries, functionally the same thing.

The recommendation engine couldn’t work on top of that. In Norman’s terms, we had a catastrophic conceptual model mismatch. Every user had built a different mental model of what they were working on, and the system had no shared language to operate from. You can’t do gap analysis when the gap dimensions are fuzzy, overlapping, and user-generated.

So we did something painful. We threw all 141 away and started from psychometric research. Validated communication competency frameworks. Published, peer-reviewed dimensions of what ‘communication skill’ means when you measure it rigorously.

We landed on eight dimensions. Eight.

That collapse, 141 to 8, was one of the hardest product decisions I’ve made. In Self-Determination Theory terms (Deci & Ryan), it felt like violating the Autonomy principle. It felt like telling users ‘we know better than you what you’re working on.’ The psychometric evidence was overwhelming though. When you let people self-categorize communication skills, they create endless synonyms and miss critical dimensions entirely. Almost nobody listed ‘consistency’ as a target, for example. I’m not sure if this is a universal human trait or specific to communication skills, but it’s a pattern I’ve seen often. Consistency, maintaining quality under pressure, across contexts, is one of the strongest predictors of communication effectiveness in the literature.

User-generated taxonomies feel democratic. Validated taxonomies work. The Kano Model has a concept for this. Users will say they want freeform input, but their satisfaction doesn’t improve from getting it. What improves satisfaction is getting recommendations that work.

Solving Cold Start Without Asking Boring Questions

The classic cold start problem. New user, no data, and you need good recommendations immediately. Most platforms solve this with a questionnaire. ‘Rate your interest in these 15 topics.’

BJ Fogg’s B=MAP model told us that was wrong. Behavior equals Motivation plus Ability plus Prompt. A new user arriving from their manager’s email has moderate motivation at best. A fifteen-question onboarding form tanks their Ability. Too much time, too much mental effort, too much friction. Fogg is clear: when motivation is low, make the action trivially easy. A questionnaire is the opposite of easy.

We built two things instead.

First: industry/role/seniority profiles. Before any user tells us anything personal, we know statistical priors. A VP of Engineering at a Series B startup has different communication challenges than a Marketing Director at a Fortune 500. We built baseline profiles from research. What skills matter at each seniority level, what scenarios each role encounters, what difficulty level fits each experience bracket.

Second, and this is the one I’m proudest of, the Challenge Picker and Confidence Slider.

Instead of asking ‘what do you want to improve?’ we show three real scenarios and let users pick which feels most relevant. Steve Krug would call this ‘Don’t Make Me Think.’ Recognition, not recall. Show options, let them point.

Then, before their first practice: a Confidence Slider. ‘How confident do you feel about this scenario?’ Zero to ten. Two seconds.

That slider is pure signal. It’s where Kahneman and Tversky’s work on cognitive bias becomes directly useful in product design. Someone who rates themselves 8/10 confidence and delivers a 550 EPS score has a calibration problem, what Kahneman calls overconfidence bias. Someone who rates 3/10 and delivers the same 550 is underestimating themselves. The recommendation engine treats them completely differently, and it should. The gap between self-assessment and performance is one of the richest signals any coaching product can capture.

All of this runs without a single API call to any language model. Zero tokens. Zero latency. Zero risk of prompt injection or model drift affecting what learning path someone follows.

The Quiet Confidence of Boring Technology

I’m not anti-AI. ExecReps runs on AI, yes. Our assessment engine is genuinely powerful and would have been impossible three years ago. AI was the wrong tool for recommendations though, because the recommendation problem was well-defined enough to solve with math.

Here’s my rough heuristic, for what it’s worth:

Use AI when: the input is unstructured, the output needs to be generative, and you can’t write rules for what ‘good’ looks like. Assessment of free-form speech? That’s AI.

Use algorithms when: the input is structured, the output is a ranking, and you can define ‘good’ with research. Matching users to content? That’s math.

Use neither when: the problem is a UX problem disguised as a technical one.

There’s a confidence that comes from building something you can fully explain. When a user asks ‘why did you recommend this?’ and you can say ‘because your skill gap in Eloquence is 23% wider than your gap in Command, you haven’t practiced client-facing scenarios in 9 days, and this sits one difficulty tier above your last successful attempt’, that’s a different conversation than ‘our AI thought you’d like it.’

In executive coaching, where people are developing skills that affect their careers, their livelihoods, their sense of professional identity, they deserve the transparent answer. Someone making decisions about their own development should understand the reasoning behind the recommendations shaping that development.

Executive presence should not be a privilege. Neither should understanding why your learning platform steers you in a particular direction.

It’s not the flashiest thing we’ve built, I know. ‘Startup uses math instead of AI’ isn’t exactly clickbait. Still, when I look at our recommendation accuracy, users completing recommended scenarios at a significantly higher rate than self-selected ones, I think about that moment with the GPT–4 prompt written and ready to ship.

I’d delete that prompt again every time.

I keep hearing the same pitch: “We replaced three FTEs with an agent workflow.”

Cool. But who owns the budget line when that agent hallucinates a contract clause? Who absorbs the cost when your inference bill triples because a customer’s edge case sent your agent into a retry loop? And when you show up to quarterly review, is that agent spend capex or opex?

These are the conversations happening in every finance review I hear about right now. And most product leaders are walking in unprepared.

The 95% problem is a money problem

Here’s a number that should keep every CPO up at night: 95% of GenAI pilots deliver zero return on investment. Bulbul Pandya put it bluntly in Product Coalition last year: “AI doesn’t absolve us from doing the product work. It magnifies the consequences of skipping it.”

That’s not a technology problem. That’s a commercial discipline problem. Teams are shipping agent features without a unit economics model. No cost-per-task target. No margin threshold. No kill switch when the math stops working. And CFOs are starting to notice.

The cost of inference dropped 99% in two years. Sounds like a gift, right? It is, until you realise that cheaper tokens mean teams use 100x more of them. I’ve talked to product orgs where their monthly AI compute bill went from a rounding error to their third-largest line item in under a year. When nobody owns the P&L for agent spend, nobody notices until the quarterly close.

Per-seat is dead. Per-outcome is terrifying.

Serhat Pala wrote something in Product Coalition this week that crystallised what I’ve been thinking. He called it SaaS 2.0: “SaaS 1.0 charged per seat. Customers paid for access. SaaS 2.0 charges per outcome. Customers pay for work completed. A support ticket resolved. A tax return filed. A contract reviewed.”

That sounds clean on a slide. In practice, it flips the entire risk model. When you charge per outcome, your margin depends on how efficiently the agent delivers. If the agent needs human intervention 20% of the time, your gross margin might be 60%. If it needs help 40% of the time, you’re running a service business with software pricing. And good luck explaining that variance to your board.

This is the part most product leaders haven’t internalised yet. Per-seat pricing meant predictable revenue regardless of whether the customer got value. Per-outcome pricing means you eat the cost of every failure. Your agent’s accuracy rate isn’t just a product metric anymore. It’s a margin metric.

The three questions your CFO will ask (and you’d better have answers)

I’ve been collecting the questions that finance teams are actually asking product leaders about agent spend. Three keep coming up:

First: “What’s the fully loaded cost per agent-completed task, including compute, orchestration, evaluation, and human escalation?” If you can’t answer this, you don’t have a business case. You have a demo.

Second: “What’s the error rate, and what does each error cost us?” Jon Matheson learned the hard way that product managers who don’t understand how their decisions affect revenue, COGS, and margin are doing half the job. With agents, the stakes are higher because the cost of a wrong output isn’t just a bug ticket. It can be a compliance event.

Third: “At what volume does this become cheaper than the alternative?” Not cheaper than the old software. Cheaper than the humans, contractors, or BPO teams doing the same work today. Thomas Schwenger described it perfectly: “The translation layer between business ideas and working software has been the most expensive bottleneck in technology for decades. It is collapsing.” True. But collapsing doesn’t mean free. It means the cost moved from headcount to infrastructure. Your CFO wants to know exactly where it landed.

The product leaders who thrive in this era won’t be the ones who ship the most agents. They’ll be the ones who can show the unit economics on a single slide and defend every number on it.

What’s the hardest financial question your CFO or board has asked you about AI agent spending - and did you have an answer? Hit reply. I want to hear the real stories.

Brought to you by ExecReps, AI coaching that helps product leaders practice the conversations that matter most

Just Ship Something, Please (2015–2019)

In December 2015, Fabrice Wegner wrote ‘The Vicious Circle of Preparation’ for Product Coalition, and reading it now feels like stepping into a time capsule. Fabrice was watching teams get stuck in endless preparation loops. Stakeholders would prioritize half-baked epics, product owners would scramble to validate them, engineers would wait around, and nobody shipped anything. His frustrated question cut through the noise:

“Is it wrong to want ship fast?”

The answer back then was a loud no. Speed was the gospel. Fabrice also dropped a line that I think most MVP evangelists never fully internalized: “Your customers won’t get happier or pay you a dollar if your team has learnt something. But the learning increment is the basis of a successful product.” Learning was supposed to justify shipping ugly. The trouble was, a lot of teams took that permission and ran with it.

Four years later, Vaibhav Gupta published ‘How to Define MVP’ on Product Coalition as part of a Product Management 101 series. His framing was textbook Lean Startup: “It is the smallest thing that you can build that would deliver some value to your customers and also help you gather validated learning about customers with least effort.” He walked through the Uber example (Travis Kalanick driving a car, a basic web app for hailing it), the skateboard-to-car analogy, the Build-Measure-Learn loop. All the hits.

This was still peak MVP optimism. The assumption was clear: build the smallest useful version and the path forward reveals itself. What nobody was really asking yet was whether the smallest useful version might also be the version users hate.

Ship Fast, But Please Make It Good (2020)

OK so here’s where it gets interesting. I pulled up two articles from 2020 and they basically argue with each other without meaning to.

In March of that year, Yellow Systems wrote ‘An MVP Can Save Your Product’s Life’ and was still firmly in the pro-MVP camp. Their argument: “launch delays have killed millions of startups and will probably kill millions more.” Fair enough. Ship now. Worry later. But then they snuck in a line that stopped me: a reduction in features is expected, they wrote, but “there should be no reduction in quality.”

Wait. Quality? In an MVP? I had to reread that. The whole MVP playbook, at least how most teams ran it, was basically trading quality for speed. Yellow was drawing a line nobody had drawn before. Strip the features, sure. But the stuff you keep? It better work. And it better look like someone cared.

Then Carlos Gonzalez de Villaumbrosia dropped ‘What Is a Minimum Lovable Product?’ that same summer and I remember reading his opening line twice. He basically said: meeting needs isn’t enough. Your users want to be delighted. They don’t want to tolerate your product. They want to love the thing.

I keep coming back to his next line: “being Viable just doesn’t cut it anymore. You need to be Lovable.” Carlos wasn’t really killing the MVP. He was renaming it, adding a higher bar. The MLP, he explained, is like an MVP “but with more thought and care taken in design and UI.”

And honestly? He was right about the timing. By 2020, users had lived with Slack and Notion and Figma. Their baseline for ‘acceptable first version’ was miles above where it sat in 2015. The floor had moved and a lot of teams hadn’t noticed.

RIP MVP? (2025)

This is where the backlash got loud. Garima Srivastava, one of our contributors, wrote a piece titled ‘Minimum Viable Product (MVP) is Dead’ earlier this year and she pulled zero punches. The MVP, she wrote, was supposed to get you early feedback. What it actually does? It produces “half-baked products that nobody loves.”

Garima’s analogy is the kind that stays with you. She compared most MVPs to someone serving you an uncooked pizza and telling you to imagine how great it’ll be once it’s done. Nobody wants that. Nobody shares that with friends. Her point: viability isn’t the bar anymore. Loveability is. People don’t recommend products they merely tolerate.

I’m not sure I fully agree. The original MVP concept, the one Eric Ries actually described, was never supposed to be a product you ship to the market and walk away from. It was a learning tool. But the PM community took ‘minimum viable’ and heard ‘minimum effort,’ and that misreading created a decade of products that launched to crickets.

The correction isn’t wrong. It’s just late. And honestly, I wonder if MLP will get misread the same way in another five years.

What I’m Hearing on the Podcast

Raksha Vashishta joined us on the podcast for an episode she called ‘The MVP of My Career.’ She talked about her journey as an immigrant woman in tech, applying MVP thinking not just to products but to her own career path. Start small. Validate. Pivot when the data says to. Her story of building from an accounts receivable internship to a product leadership role mirrors the MVP-to-MLP arc in a way I wasn’t expecting: the first version of your career doesn’t need to be polished. But at some point, you stop iterating on the minimum and start building something you’re genuinely proud of.

So What Does This Mean for You?

The MVP isn’t dead. But the era of shipping something ugly and calling it strategy? That part is over. What actually changed isn’t the framework itself. It’s the floor. User expectations in 2025 are so far above where they were in 2015 that the ‘minimum’ in ‘minimum viable’ now means something completely different.

When was the last time you shipped a true MVP, the ugliest working version you could get away with, and actually got useful feedback from it? Or has your team already moved past that into MLP territory without calling it that? Reply and tell me. I genuinely want to know if the skateboard still works.

You’re reading the Product Coalition newsletter. Every week, I dig into the archive of 3,500+ articles and 100+ podcast episodes to trace how product thinking has evolved. If someone forwarded this to you, subscribe here so you don’t miss the next one.

Jay Stansell · Lisbon, Portugal · Product Coalition