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 a…

Read more

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

I had one of those mornings recently. You know the kind. Staring at a screen, coffee going cold, and the data just… mocks you. Not the company, not the product, but the dashboard itself made me want to quit.

We’d spent weeks building acoustic voice analysis into ExecReps. Pace, filler words, clarity, confidence. Now, users could see everything.

Their content scores, broken out across structure, persuasion, and relevance. Their delivery scores, measured across four vocal dimensions we called Command, Eloquence, Engagement, and Consistency. Eight archetype classifications. Historical data on every dimension. Charts for days.

It was, objectively, impressive engineering. It was also terrible product design.

I knew this because I watched myself use it. I’d finish a practice session, get my results, and then spend two minutes trying to figure out whether I’d gotten better. Was my Eloquence going up, but my Command going down? Did the content improvement offset the delivery dip? Was a 620 in Engagement good? Compared to what?

This is the bit I keep getting stuck on with some of the data visualization trends. We collect so much, but what do we dowith it?

Don Norman calls this the Gulf of Evaluation: the gap between what a system shows you and your ability to figure out what it means. Our dashboard had created a canyon-sized gulf. Tons of data, zero answers. If I, the person who built this thing, couldn’t quickly answer ‘am I improving?’, no user stood a chance.

The Data Trap

Engineers and PMs love data. Users love answers.

I’ve learned that the hard way, multiple times, across multiple companies.

There’s a seductive logic to giving users more information. More data means more transparency, more trust, more engagement. It’s a clean little story that falls apart the moment a real human opens your app.

Barry Schwartz’s Paradox of Choice shows more options create more anxiety, not more satisfaction. Nielsen’s eighth usability heuristic, aesthetic and minimalist design, exists because every extra element on screen competes for cognitive bandwidth. Show someone eight metrics and you haven’t given them eight insights. You’ve given them decision paralysis wearing a dashboard costume.

The mistake isn’t in collecting the data. It’s in thinking the data is the product.

What Fitbit Already Figured Out

The breakthrough came from a conversation I had with a friend who’d just gotten a Garmin watch. She was showing me her stats: heart rate variability, VO2 max, sleep stages, body battery. I asked her what her resting heart rate was.

She had no idea.

What she did know was that her ‘body battery’ was at 73 that morning, which was higher than last week. Her training status said ‘Productive’. That’s all she needed.

In the Kano Model, Garmin’s raw biometric data is table-stakes quality: expected but not exciting. The ‘body battery’ synthesis is the delighter. Same sensors, but the experience shifts from ‘here’s your data’ to ‘here’s your answer’.

Fitbit figured this out years ago. It wasn’t ‘here are your steps, your distance, your calories, your active minutes’. It was: you hit your goal today. You’re on a streak. You’re improving. The raw data lives behind a tap for the nerds who want it. The product is the answer.

We needed our own version of that. I wonder if this lesson applies to every ‘pro’ tool. Do finance professionals want every row of a spreadsheet, or just the insights from it? I’m not sure.

Building the Executive Performance Score

So in late November, we built what we call the Executive Performance Score. The EPS.

One number. 400 to 1,000 scale. It tells you how effective you are as a communicator. Full stop.

Under the hood, EPS combines two systems we’d already built. Think of it like this:

Content quality. Our GPT–4 analysis layer evaluates what you say. Structure, clarity, persuasion, relevance, depth of thinking. This is the stuff traditional coaching often focuses on.

Delivery quality. Our acoustic analysis layer evaluates how you say it. Command, Eloquence, Engagement, and Consistency. This is the stuff that usually requires a live coach or, more often, never gets measured at all.

In Norman’s terms, we were creating a new conceptual model. Instead of ‘I have eight separate scores I need to track’, the mental model becomes ‘I have one number that goes up when I get better’. One number. Two systems. A graspable picture.

The 60/40 Fight

This is where it got contentious. If EPS combines content and delivery, what’s the weighting?

My instinct was 50/50. Clean. Fair. Democratic.

But content and delivery don’t matter equally. Pretending they do is the kind of elegant-sounding product decision that makes your product worse.

We went back and forth on this for longer than I’d like to admit. The arguments for 50/50 were aesthetic. The arguments against were practical.

First, content has a higher ceiling of differentiation. Two people can deliver a message with nearly identical vocal quality but wildly different levels of insight and persuasion. Academic communication research suggests content predicts audience perception of competence more strongly than delivery alone.

Second, we’re building for professional contexts. In a board meeting, a pitch, a difficult conversation, what you say carries more weight than how you say it.

Third, and this is the one that settled it, a 50/50 split created a perverse incentive. Kahneman and Tversky’s work on framing effects applies directly. How you frame a metric changes what people optimize for. A 50/50 split would tell users with strong voices but weak content that they were ‘good’ when they were just pleasant-sounding. That’s not what we’re building. We’re not a voice beautification tool.

So we went 60/40. Content gets 60%, delivery gets 40%.

It’s not a perfect split. It does create the right incentive structure: if you want a high EPS, you need to think well and communicate substantively. A beautiful voice won’t carry you past 700.

The product lesson is that ‘weights are product decisions, not math decisions’. Every composite metric encodes values. Spotify’s Discover Weekly weights novelty against familiarity. Google’s search algorithm weights freshness against authority. The weights aren’t neutral, they’re your product’s opinion about what matters. Own that opinion explicitly, or you’ll end up with a metric that doesn’t drive the behavior you want.

The 400–1,000 Scale (And Why Not 1–100)

Small decision, but it mattered more than expected: the scale.

Early versions used 1 to 100. It felt intuitive. Everyone understands percentages. It created two problems though.

First, nobody wants to be a 43. This is Kahneman and Tversky’s anchoring bias in action. Decades of school grades have anchored everyone to read anything below 70 as ‘bad’. A score of 52 out of 100 is above the mathematical median, but it feels like failure. The anchor is stronger than any disclaimer you put next to it.

Loss aversion tells you why this kills a self-improvement product. If users feel they’re ‘failing’ on their first session, the emotional cost of continuing outweighs the potential gain. They don’t come back. You’ve lost them to a technically accurate but emotionally devastating number.

We borrowed the 400–1,000 scale from standardized testing (SAT, GRE, GMAT). It’s population-normalized, so a 600 means you’re at the median, not ‘failing’. A 580 doesn’t trigger the same shame response as a 58.

Same underlying data, different emotional frame. That’s product design. I wonder if there’s a limit to how much you can ‘gamify’ negative feedback. Or if all products should just avoid grading entirely.

The Backfill Decision

This is the part I’m most proud of. It was almost the part we didn’t do.

When we launched EPS, every user had existing data. Practice sessions from weeks or months of using the platform. They didn’t have EPS, because EPS didn’t exist when they did those sessions.

The easy path: EPS starts now. Old sessions get old scoring. New sessions get EPS. A clean cutover.

But that meant users would open the dashboard and see… nothing. No trend line. No trajectory. Just a single data point. The whole promise of ‘am I getting better?’ requires comparison over time. One data point isn’t a trajectory. It’s a dot.

So we went back and calculated EPS for every historical submission in the system. Every practice session, every scenario, every user. We applied the same 60/40 weighting, the same population normalization, the same scale. When users opened the new EPS dashboard for the first time, they didn’t see a blank slate. They saw their entire journey.

This matters more than it sounds like it should. Multiple well-established frameworks explain why.

Teresa Amabile’s progress principle research at Harvard shows that the single strongest driver of motivation at work is the sense of making progress on meaningful work. Not recognition, not incentives. Progress. Deci and Ryan’s Self-Determination Theory identifies competence, the feeling that you’re getting better, as one of three fundamental human needs. Daniel Pink’s mastery research in Drive makes the same case. The trajectory line directly feeds the deepest drivers of human motivation.

From a behavioral design perspective, Nir Eyal’s Hook Model would call the backfill data ‘stored value’, the Investment phase of the habit loop. Users who see their history have something invested in the system. That investment loads the next trigger: ‘I wonder if my next session will push me past 700.’ Without the backfill, zero stored value. With it, they start already hooked.

When users opened ExecReps and saw a line going up, even slightly, something clicked. I could see it in the engagement data. Session frequency increased. Users who’d been doing one practice a week started doing two or three. They weren’t responding to a new feature. They were responding to evidence that they were getting better.

BJ Fogg’s B=MAP model explains the mechanism: Behavior = Motivation × Ability × Prompt. The backfill didn’t change ability or the prompt. It changed motivation. Seeing a rising trajectory makes the next session feel not just possible, but inevitable.

The engineering cost was maybe two days. The impact on retention was disproportionate. If you’re building any kind of self-improvement product, I’d argue the backfill is the feature. Not the score itself. The score is just a number. The trajectory is the product.

Measure What Matters, Show What Motivates

We ended up with a design philosophy we still use: ‘measure what matters, show what motivates.’

We still collect all the granular data. Every acoustic dimension, every content sub-score, every archetype shift. That data lives one tap away. Progressive disclosure in Nielsen’s terms. Or what Dan Saffer’s microinteraction patterns might call a ‘long tap to reveal’ secondary layer. Some users dig into it and love it.

The product surface, the thing you see first, is one number, one trend line, and one answer: you’re getting better.

This philosophy cuts against every instinct a data-driven PM has. We want to show our work. We want credit for the engineering. All of that is ego, not product sense.

The best products are like the best coaches. They take in a huge amount of information, synthesize it, and tell you the one thing you need to hear right now. That’s what EPS became. Not just a metric, a design principle. Every feature we’ve built since, I ask: are we showing what motivates, or are we showing what we measured?

The Uncomfortable Truth About Metrics

I’ll end with something that still makes me slightly uncomfortable.

EPS is an opinion. It’s our opinion about what makes effective communication, encoded as math. The 60/40 split is a product decision. The population normalization is a modeling choice. The scale is a psychological design. None of it is ‘objective’ in the way users might assume when they see a number with decimal precision.

Every metric in every product is like this. Your credit score is an opinion. Your Uber rating is an opinion. Useful approximations dressed up as measurements.

I think founders and PMs have an obligation to be honest about this. Cialdini’s research on commitment and consistency shows that once people anchor their identity to a number (‘I’m a 720’), they’ll work to stay consistent with that identity. That’s powerful. The behavior your metric incentivizes should be the behavior you want. Get the weights wrong, and you build a precise system that makes users worse at the thing they’re trying to improve.

We spent more time on the values behind EPS than on the engineering. I think that’s exactly right.

It reminds me of a conversation I had with one of our Product Coalition podcast guests, Marty Cagan, who often talks about how product strategy is value decisions. Metrics are just a manifestation of those values.

Because that’s the point. Not the number. Not the dashboard. It’s the person on the other side of the screen, trying to close the gap between where they are and where they want to be. They’re trusting us to tell them whether it’s working.

If this idea resonates with you, and you’re curious about how a tool like ExecReps could help your team communicate with greater impact, you can learn more about it on our website. It’s been a fascinating journey building it in public, and I’m genuinely excited about what we’re helping people achieve.

“Should we add streaks?” Our designer sent it.

I typed “yes” immediately.

Then I deleted it.

Then I typed a longer answer. Deleted that too.

I stared at the cursor for a solid minute. Behind those six words was one of the most consequential product decisions we’d make. Not technically. Streaks are trivial to build. Philosophically, though, it was huge. Because the answer would define whether ExecReps helps people build a practice, or just guilt-trips them into opening an app.

Very different things, those two.

The Duolingo Problem

Let me back up a little. We’d just shipped v2.5, our personalized experience release. We had role-based navigation. Smart empty states. Progressive disclosure that showed people only what they needed. Don Norman would call that reducing the “Gulf of Execution,” narrowing the gap between intent and interface.

But we had a retention problem. People who practiced three times stuck around. The challenge was getting people to practice three times in the first place. Our activation curve looked like a cliff with a plateau. You either fell off in the first week or stayed for months.

When we ran our engagement features through Nir Eyal’s Hook Model, we scored about 4 out of 10. We had a decent trigger (email invite) and a reasonable action (do a workout). Our Variable Reward was flat, though, and our Investment phase was nonexistent. Users completed a workout and… nothing loaded the next trigger. No real reason to come back tomorrow. Any product team using the Hook Model would recognize that open-ended loop as the problem.

So, the conversation turned to engagement mechanics. And someone said “streaks.”

If you’ve ever uninstalled Duolingo, you know why that word made me pause. Duolingo’s streak system is a masterclass in behavioral design. And, I think, an object lesson in crossing the line from helpful to hostile. The sad owl. The passive-aggressive notifications. The sheer guilt of it all. That thing where you feel worse about breaking a streak than you ever felt good about maintaining one.

I’ve talked to people who kept their Duolingo streak alive for 300 days without learning a single new word. The metric had completely decoupled from the outcome. In Kano Model terms, what should be a ‘delighter’ – a sense of momentum – had degraded into a ‘must-be’ obligation that only generated dissatisfaction when broken.

That isn’t retention. That’s a hostage situation. A podcast guest told me something similar about fitness apps a few months back. The moment the streak becomes the point, you’ve lost the plot on what the product was supposed to do.

BJ Fogg Changed My Mind

I almost killed the streaks idea entirely. Then I re-read BJ Fogg’s Tiny Habits, and his B=MAP model reframed everything.

Fogg’s framework is pretty standard product science now. Behavior = Motivation × Ability × Prompt, all converging at the same moment. Miss any one, nothing happens. The mistake most products make is trying to increase motivation. More notifications, more badges, more guilt. Fogg argues you should instead decrease the effort required. Make the behavior so easy that even low motivation is enough.

That distinction changed everything. The question wasn’t “how do we motivate people to practice?” It was “how do we make practicing the path of least resistance?”

We spent two weeks mapping the behavioral science before writing a single line of code.

BJ Fogg’s B=MAP. Design for the low-motivation moment. Not eager Monday morning, but exhausted Thursday afternoon. If the streak system only works when people are fired up, it’s not a system. It’s a fair-weather friend.

Kahneman & Tversky’s Prospect Theory. People feel losses roughly twice as intensely as equivalent gains. The engine behind every streak system ever built. We’d use loss aversion, but carefully, with an escape valve.

Nir Eyal’s Hook Model. Trigger → Action → Variable Reward → Investment. Our 4/10 audit exposed the missing Investment phase. Our morning nudge system needed to close that loop.

Deci & Ryan’s Self-Determination Theory. Intrinsic motivation requires autonomy, competence, and relatedness. Daniel Pink popularized this as Drive’s AMP framework: Autonomy, Mastery, Purpose. This became our ethical guardrail. Any engagement system that undermines autonomy will eventually backfire.

What We Built (And What We Didn’t)

Streaks, But With an Exit Ramp

Yes, we built streaks. But with one critical difference. We designed the break as carefully as the streak itself.

When you practice, your streak increments. You see a small visual celebration. Dan Saffer calls this a ‘signature moment’ in his microinteractions framework. Not confetti cannons, just enough feedback to trigger Fogg’s “celebration” mechanism. The key is immediacy. Celebration fires within 200ms of completion. Delayed celebration doesn’t wire the habit. Hit milestones (7 days, 30 days, 100 days) and the feedback gets richer. It’s a progressive loop where the microinteraction evolves as your behavior matures.

The part I’m quite proud of? Streak freezes. Miss a day, spend a ‘freeze credit’ to keep your streak alive. You earn these by practicing consistently. It’s Kahneman’s loss aversion working for you instead of against you. You’re spending a resource you banked through good behavior. Cialdini’s Commitment & Consistency principle is baked in. The freeze credits are earned through past commitment, making the current streak feel like something you’ve invested in, not something imposed on you.

If your streak does break? We don’t show a sad owl. We show your best streak as a personal record. “Your best: 23 days. Let’s start a new one.” The streak dies quietly. No funeral. No guilt. Just a clean slate.

Someone on the team argued a broken streak should feel like something. They thought mild pain of loss is what makes streaks work. They weren’t wrong about the psychology. But they were wrong about the ethics. Our users are professionals trying to get better at communication. If they miss a day because their kid got sick, the last thing they need is an app eroding their confidence. That’s a direct violation of SDT’s autonomy principle. Once autonomy is undermined, Deci & Ryan’s research shows intrinsic motivation doesn’t just dip. It collapses.

Morning Nudges, Timed to the B=MAP Window

Our nudge system sends a morning email, not a push notification. That’s deliberate. It’s timed based on engagement patterns. Content varies. It could be a prompt related to something you’re working on, a micro-insight from your last session, or simply “Your 3-minute warm-up is ready.”

The timing isn’t random. We anchored nudges to what Fogg calls ‘anchor moments’. That’s the Tiny Habits recipe: “After I [existing behavior], I will [new behavior].” Most professionals have a cortisol spike in their first waking hour. Alert, but not yet consumed by chaos. That’s when B=MAP converges. Motivation is fresh, ability is high, and the email is the prompt.

The variable reward, straight from Eyal’s Hook Model, comes from the content. You don’t know what the nudge will contain. It might surface a skill gap you hadn’t considered, or a scenario relevant to a meeting that afternoon. Variable rewards of the “hunt” type create curiosity. Curiosity beats obligation every time.

Every nudge has a one-click opt-out. Not buried in settings. Right there in the email. Nielsen’s Heuristic #3, “User control and freedom,” in practice. The moment a nudge feels like spam, trust is gone permanently.

Re-engagement, An Invitation Not an Intervention

For users who go quiet: one email after two weeks. “Here’s something new since you’ve been away. No pressure.” One email. Not a drip campaign. If they don’t come back, we leave them alone. That’s Pink’s Autonomy principle in action. And it matters more than juicing a metric.

The “What We Don’t Build” List

Every product team has a roadmap. Very few have a formal anti-roadmap. We started one during v2.6 planning, and it’s become one of our most valuable documents.

No leaderboards. Communication skills aren’t a competition. Ranking people against each other undermines what Deci & Ryan call ‘relatedness’. That’s the sense you’re part of a supportive group, not fighting for position.

No public scores. Your EPS, streak, practice frequency. All private by default. Nielsen’s Heuristic #7: flexibility and efficiency of use means users control their own data.

No shaming mechanics. No “you’re falling behind” messaging. We learned from our social proof analysis that showing “3 of 15 members practiced today” is negative social proof. Cialdini warns that framing the minority as the example normalizes inaction. We use absolute counts instead. “3 team members practiced today.” No denominator, no implied judgment.

No engagement theater. No features that increase time-in-app without increasing value-to-user. Norman calls this a conceptual model violation. When the product’s goals diverge from the user’s, the relationship erodes.

The Product Lesson: Easiest Beats Loudest

This is an insight I keep coming back to. It applies to virtually every product with a retention challenge.

The best retention features don’t motivate people to do hard things. They make the right thing the easy thing.

The B=MAP alternative to amplifying motivation: make the behavior so frictionless that even a bad day’s motivation is sufficient.

• Shorter sessions, not longer ones. A three-minute warm-up is better than a thirty-minute workout you skip. That’s Fogg’s “Starter Step.” An entry point so small it feels absurd to say no.

• Fewer choices, not more. Progressive disclosure means one clear next step, not twenty options. Norman calls this ‘constraints’. Limiting action possibilities to guide behavior without instructions.

• Gentler nudges, not louder ones. A calm morning email beats five push notifications. Saffer’s microinteraction principle: triggers should match the emotional context, not overwhelm it.

• Graceful failure, not punishment. A quiet streak reset beats a guilt-trip notification.

Our early v2.6 data is encouraging. Streak cohort users practice about 40% more frequently. More importantly, session quality metrics haven’t dropped. People aren’t checking a box to keep a number alive. They’re doing the work. Not sure yet whether that holds over six months, but it’s the right signal.

That’s the difference between a habit and an obligation.

The Uncomfortable Truth About Behavioral Design

Building this system forced me to confront something uncomfortable. Every behavioral design technique is morally neutral. Kahneman & Tversky’s loss aversion can build a healthy practice or trap someone in a toxic loop. Eyal’s variable rewards can spark curiosity or create compulsive checking. Cialdini’s social proof can inspire action or manufacture peer pressure. The framework doesn’t care about your intentions.

I wonder if that’s the biggest design challenge we face today. Not building the features, but building the ethics around them.

We optimized for practice quality, not app opens. For skill growth, not session count. We built explicit escape valves, too. Freeze credits, quiet resets, one-click opt-outs. Because these tools were powerful enough to do real harm if deployed carelessly. I’m not sure we got every detail right, but the intent was right.

That three-week internal argument about streaks – the one that started with six words in Slack – was the most valuable product discussion we’ve had. The most important product decisions aren’t about what you build. They’re about why you build it. And what happens when it works exactly as designed.

If you’re building engagement systems, write your own “what we don’t build” list before you write a single user story. You might be surprised how much clarity it provides. It sure did for us, and it’s why we built ExecReps the way we did.

And if you ever find yourself designing a sad owl, stop. Close your laptop. Go for a walk. You’ve lost the plot.

I asked a VP of Product last week what her product’s LTV-to-CAC ratio was. Smart person, ten years in product, ran a team of twelve.

She did not know. Not roughly. Not ballpark.

She could tell me her NPS was 62, her activation rate had improved 14% quarter over quarter, and her team shipped 23 features in the last cycle. All good numbers. But the one number the board asks first? Blank.

I keep seeing the same pattern. The product team walks into a QBR with activation funnels and cohort charts. The board wants to know when customers pay back their acquisition cost. Both sides leave frustrated, and nothing changes until someone gets cut from a budget review.

Nick Chasinov put it bluntly on Product Coalition: ‘If your CAC is higher than your LTV, it’s only a matter of time before the business closes its doors.’ Nick recommends a 3-to–1 ratio as the minimum healthy benchmark. I suspect most PMs reading this cannot say whether their product hits that or not.

And honestly, I do not blame them. I never learned this in any PM course I took either. Most of us pick it up only when a CFO forces the conversation, which usually means we are already behind.

John Utz shared a story that still bothers me. Fab, the e-commerce darling once valued at a billion dollars, tracked user registrations and website traffic religiously. John writes that they ‘overlooked the necessary metrics of customer retention and lifetime value.’ They poured money into acquisition, the top-line numbers looked incredible, and then the whole thing cratered.

Every metric Fab tracked was trending up. The business was dying anyway.

Olivia Tanuwidjaja explained on Product Coalition that CLV measures ‘the healthiness of our customer acquisition.’ I keep coming back to that word. Healthiness. Not size, not speed. Health. If your acquisition costs outpace what customers generate over their lifetime, you are not growing. You are spending faster.

The PMs who figure this out tend to move differently. Jon Matheson described the shift in his own career: he structured pricing so that ‘the LTV of premium users offsets the CAC within six months.’ That is not product language. That is board language. And it completely changed how his finance team engaged with the product roadmap.

Nicole Segerer made a related observation on my podcast. Most teams sit on mountains of usage data but have almost no visibility into how those numbers connect to revenue per customer. The data exists. Nobody is wiring it together.

Here is what I keep thinking about. Everyone in product is scrambling to learn AI tools and prompt engineering right now. Fair enough. But the PM who can walk into a board meeting and connect their roadmap to payback periods and gross margin? That person is rarer. And probably more valuable.

So here is what I want to know. What is the one unit economics number about your own product that you genuinely cannot calculate today? LTV-to-CAC ratio? Payback period by channel? Gross margin per feature? Hit reply and be honest. I am collecting these because I think there is a pattern in what product teams struggle to measure, and I want to write about it next.

Sources: Nick Chasinov - “Why Are Customer Acquisition Cost and Lifetime Value Important to Calculate?” (Jun 2023), John Utz - “From Vanity Metrics to Actionable Insights” (Aug 2024), Olivia Tanuwidjaja - “Customer Lifetime Value Explained” (Mar 2023), Jon Matheson - “Make Product Make Financial Sense” (Nov 2024), Nicole Segerer - Product Coalition Podcast. All published on Product Coalition.

I’ve been pulling North Star Metric articles out of our archive all week, and honestly? The pattern surprised me. In 2019, our contributors were so sure. One metric. One number. That’s all you need. Three years later, some of those same people were writing about how that advice nearly wrecked their product teams. I don’t think most of us caught the shift as it happened.

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

One Metric to Rule Them All (2019-2020)

If you want to feel the vibe of peak single-metric evangelism, go read Smit Shah’s ‘Tracking ‘One Metric That Matters’ (OMTM)‘ from September 2019. I pulled it up again this week. The certainty in it is wild:

“The concept of One Metric that Matters (OMTM) states that any organization should focus on optimizing only one metric that matters at that particular stage of the product’s lifecycle.”

Smit was channeling the spirit of the time. Pick one number. Align the team. Ship toward that number. He even acknowledged that the metric should shift as the product matures, but the core belief was unwavering: at any given moment, there is ONE number you should care about.

Six months later, Rashmi Shukla wrote ‘Product Metrics — How to Measure a Product‘ and slipped in the first crack. She argued for “chasing a north star metric accompanied by a few major metrics.” A few. Not one. Rashmi also dropped a warning that didn’t get enough attention at the time: focusing on MAU is “just another vanity metric” that hides the real picture of product stickiness.

I almost skipped that ‘a few’ caveat when I first read it. Seemed like a throwaway line. Turns out it was probably the most important sentence in the piece.

The Year the North Star Cracked (2021)

OK so here’s where it gets uncomfortable. Two pieces from 2021 basically describe the wreckage. People who followed the OMTM advice, did everything right by the book, and still ended up in trouble.

Tiziano Nessi wrote ‘How to Position Yourself as a Strong Product Manager From the Get-Go‘ and did something I don’t see often enough in our industry: he confessed to the exact mistake that the previous era’s advice had produced.

“I did the mistake to set the total number of users as an NSM. This led to a focus on the wrong value lever, and despite constant growth, the engaged users were decreasing...”

Read that again. Growth was going up. Engagement was going down. The North Star was shining and the product was quietly dying underneath it. That kind of failure mode doesn’t show up in a framework diagram.

Around the same time, Sebastian Straube published ‘North Star Metric — Measure the Right Thing‘ and reached back to 1956 for ammunition. He cited Ridgway’s classic critique:

“What gets measured gets managed — even when it’s pointless to measure and manage it, and even if it harms the purpose of the organisation to do so.”

Sebastian proposed a three-tier system: vanity metrics at the bottom, proxy metrics in the middle, business-aligned metrics at the top. The North Star should sit at Tier 1, sure, but only if it demonstrates “a clear and direct relationship between your product’s problem and the degree to which it is solving it.” Even that wasn’t enough on its own, because you still needed the lower tiers for context.

From Star to Constellation (2022-2023)

This is where the thinking got genuinely interesting.

I remember reading Elena Seregina’s May 2022 piece ‘Metrics Hierarchy and Metrics Pyramid‘ and thinking: finally, someone said it. She named the thing that had been bugging me for months:

“NSM is a product metric: most likely, it will measure customer behavior, not business goals.”

That distinction sounds small. It changes everything. Your North Star can be humming along perfectly while your business loses money. Elena proposed a layered pyramid with business goals at the top and product metrics below, each level checking the one above it. She also shared a story that stuck with me: “Our business metrics were rising. But as we were cracking a bottle to celebrate, the metrics suddenly dropped.”

By 2023, even the evangelists were hedging. Sriram Parthasarathy wrote ‘Decoding Business Growth: The Art and Science of Choosing the Right North Star Metric‘ and spent most of the piece making the case for NSMs. Then he landed here:

“While the North Star metric is a critical guide, it’s not the only measure of success. Companies should monitor other KPIs to ensure a balanced approach to growth.”

Sit with that for a second. Sriram just spent a whole article making the case for North Star Metrics. And his own conclusion is ‘not the only measure of success.’ That hedging at the end? That’s the sound of a correction happening in real time, right on the page.

What I’m Hearing on the Podcast

Bhav Patel came on the podcast to talk about fighting feature factories, and his rant connected directly to this whole metrics story. His argument: PMs became “feature managers” precisely because they lost the discipline of measurement. Not because they measured too little, but because they measured the wrong things and then stopped owning the numbers altogether.

“Product folks need to get their head out of their asses and start measuring what they do,” Bhav told us. His point isn’t that the North Star idea was wrong. It’s that most PMs never did the hard work of picking the right one, and when the single-metric approach failed them, they abandoned measurement entirely instead of fixing the metric.

So What Does This Mean for You?

The North Star didn’t die. It got demoted from solo act to lead instrument. The product community learned (sometimes painfully) that a single metric can focus a team, but it can also blind one. The fix isn’t to stop measuring what matters most. It’s to make sure ‘most’ isn’t doing all the work alone.

Here’s what I want to know: does your team still rally around one North Star, or have you moved to something more layered? Reply and tell me. I’m genuinely curious whether the correction has reached the teams doing the work, or if it’s still mostly happening in the articles.

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

The user, a senior PM at a mid-size SaaS company, had scored well on our platform. Her content was structured, her arguments logical, her delivery measured. By every objective metric we’d built, she was a strong communicator.

Her feedback, though, said: “I guess I’m just not a natural speaker. My scores are fine but I still don’t feel like I know what I’m doing.”

Fine scores. No identity.

That’s when I realized we’d built a measuring stick when people wanted a mirror. The thing I kept coming back to was this idea of identity.

The Score Trap

Let me rewind. By November 2025, ExecReps had acoustic voice analysis working. V1.0 shipped with AssemblyAI-powered analysis of pace, filler words, clarity, confidence.

Users would record a practice response to a scenario like ‘Your CEO just asked you to explain why the roadmap is slipping, go,’ and we’d break down both content quality and vocal delivery.

The scores were… fine. People used them. People improved. Something, though, was missing.

I’m not sure if it was the numbers themselves, or just how we were presenting them. I wonder if it’s just human nature to want more than a number.

I kept hearing the same questions: “What’s a good score?” “Am I normal?” “How do I compare?”

These aren’t questions about improvement. These are questions about identity. People weren’t asking “How do I get better?” They were asking “Who am I as a communicator?”

Anyone who’s read Deci and Ryan’s Self-Determination Theory would recognize the pattern. Scores satisfy competence (one of three basic psychological needs) but completely miss relatedness and autonomy.

A number tells you where you rank. It doesn’t tell you where you belong.

I’d spent fifteen years building products and somehow missed one of the most documented insights in motivation research. People don’t optimize for numbers. They optimize for a sense of self.

This reminds me of a conversation I had with a founder recently, talking about how a lot of fitness apps fail because they focus on calories burned, not on the feeling of being an ‘athlete.’ It’s the same thing.

The Research Rabbit Hole

Once I saw the problem, I couldn’t unsee it. So I did what any product person does when they sense an insight. I went deep into the research.

I started with the usual suspects. Big Five (OCEAN) is scientifically validated, but measures who you are, not how you communicate. DISC is closer, but too static. Myers-Briggs has too much pseudoscience baggage. Sixteen types is a nightmare for product design.

None of these were designed for voice. They were built for survey responses and check boxes.

We had actual recordings of people speaking under pressure, with measurable acoustic properties. So we built our own.

Four dimensions emerged:

Command. How much authority and conviction comes through. Not volume. Certainty. Vocal steadiness, declarative phrasing, pacing that says ‘I know what I’m talking about.’

Eloquence. The precision of expression. Vocabulary range, sentence structure, the ability to find exactly the right word instead of four approximate ones.

Engagement. How much you pull people in. Vocal variety, storytelling instincts, tonal warmth. The difference between reading a report and making someone lean forward.

Consistency. How stable your communication is across contexts. Some people are brilliant in a 1:1 and fall apart in front of a group. This dimension measures the gap.

We called it the Voice Performance Score, VPS. We scaled it 400 to 1000, like the SATs.

That familiar-scale choice comes straight from Nielsen’s Recognition over Recall heuristic. If your scoring system requires a user manual, you’ve already lost. The SAT scale gave people an instant mental model. No learning curve.

The VPS wasn’t the breakthrough, however. The archetypes were.

Eight Ways to Speak

What I saw at a company in education (as well as at “MyersBriggs”, “Working Genius” etc ), was this: when you give someone a category to belong to, they engage differently with your product.

At FYG we profiled students into career pathways. The moment a student could say ‘I’m a Builder’ or ‘I’m an Advocate,’ their engagement doubled. Not because the content changed. Because their relationship with the content changed.

If you know the Kano Model, this is the difference between a ‘must-be’ feature and a ‘delighter.’ Scores are must-be. You expect them in an analysis tool. Archetypes are a delighter.

Nobody asked for them. Once people had them, though, they became the reason people came back. Kano’s insight is that delighters create disproportionate satisfaction precisely because they’re unexpected.

So we mapped the four VPS dimensions into eight communication archetypes:

The Analyst. Clarity is their superpower. Blind spot: clarity without engagement can feel cold.

The Commander. Walks into a room and people listen. Not loud, but certain. Blind spot: steamrolling without realizing it.

The Diplomat. Reads the room better than anyone. Builds consensus. Blind spot: prioritizing harmony over directness.

The Maverick. Brilliant in bursts. The off-the-cuff comment everyone remembers. Blind spot: inconsistency.

The Mentor. Natural teachers who make complex things simple. Blind spot: over-explaining when the room just needs a decision.

The Practitioner. Reliable, trusted, steady. Won’t dazzle you, but will never let you down. Blind spot: disappearing in Commander-dominated rooms.

The Storyteller. Turns data into narrative, problems into quests. Blind spot: not every moment needs a story.

The Visionary. The full package when they’re on. Paints futures people run toward. Blind spot: so compelling nobody challenges them.

Choosing eight was a deliberate product decision. Four would have been too broad. People wouldn’t see themselves. Sixteen too granular. Too many edge cases where users fall between types.

This is what Don Norman calls building the right conceptual model: if the model is too simple, people distrust it. If it’s too complex, they can’t hold it in their heads. Eight sits in the cognitive sweet spot. I still wonder if there’s a ‘perfect’ number, but eight just felt right, you know?

We debated whether archetypes should be fixed or fluid. Fixed archetypes are easier to build product around. Fluid archetypes are more scientifically honest. Your style does shift based on context.

We chose a middle path. Your archetype is your dominant style based on your body of work. We surface how your dimensional scores shift across scenarios.

So you might be a Diplomat overall, but skew Commander during board presentation practice. That nuance maps to Daniel Pink’s Autonomy principle from Drive. It gives users freedom to explore their communication range rather than boxing them in. The dominant archetype gives you identity. The dimensional shifts give you agency.

The LinkedIn Moment

We shipped archetypes on November 16th. Within the first week, something happened that I did not expect.

People started sharing their archetype on LinkedIn. Not their score. Not their improvement percentage. Their archetype.

“Just found out I’m a Storyteller on ExecReps. Honestly tracks 😂”

“Apparently I’m a Commander. My team is not surprised.”

“Diplomat here. Which explains why I spend half my life translating between engineering and sales.”

The product insight that hit me then, and that I hope lands for you too, is this: people share identity, not metrics.

Nobody posts their credit score on LinkedIn. Nobody shares their Duolingo XP. They’ll share their Hogwarts house, their Enneagram number, and now, their communication archetype.

Through the lens of Nir Eyal’s Hook Model, we’d accidentally built a complete engagement loop: someone sees an archetype post on LinkedIn (external trigger). Curiosity drives them to try ExecReps (action). They discover their archetype, any of eight possibilities (variable reward, the ‘Hunt’ type). They share it publicly, loading the next trigger for their network while creating a public identity commitment (investment).

We hadn’t designed this loop. Every piece was there, though. I wonder if we could have planned it, or if some of the best product moments just emerge like this, almost by accident.

And what made it powerful rather than gimmicky: the archetypes were grounded in real behavioral data. This wasn’t a quiz telling you what you already knew. It was acoustic analysis of how you speak under pressure.

Cialdini’s Authority principle explains why it stuck: the archetype carries weight because the source is rigorous. A personality quiz calling you creative is forgettable. A voice analysis confirming it is not.

The Diplomat Problem

The title of this post is about Diplomats, and I want to get specific.

When archetype results started rolling in, something interesting emerged. Diplomats were disproportionately likely to have previously described themselves as “bad communicators” in their onboarding surveys.

Read that again. The people most skilled at reading rooms, building consensus, and managing complex interpersonal dynamics… thought they were bad at communication.

Why? Because in most professional environments, ‘good communicator’ is coded as ‘Commander.’ Be decisive, be loud, be certain.

If your natural style is diplomatic. If you listen before speaking, build bridges instead of podiums, choose precision over volume, you’ve been told your whole career to “speak up more.”

Kahneman and Tversky’s work on framing effects explains this precisely. The professional world framed ‘communication skill’ around a single archetype, and Diplomats measure the gap between their style and the dominant one. They interpret that gap as deficiency. It’s a framing problem masquerading as a skill problem.

This hit close to home. I still remember being told my Cockney accent, my natural speaking voice, disqualified me from a design job early in my career. The implicit message then was ‘the way you communicate doesn’t belong here.’ It wasn’t about the content of what I said, but the sound of it. It was about identity, about belonging.

That’s the same message every Diplomat gets in a Commander-dominated culture. Every Mentor told they’re ‘too soft.’ Every Analyst told they’re ‘too in the weeds.’

The archetypes reframed what ‘good communication’ even means. There isn’t one model. There are at least eight.

Personas As Product

This is the product lesson I keep thinking about, because I believe it’s underappreciated:

Personas aren’t just a marketing tool. They can be the product itself.

What if the persona isn’t something you build about the user, it’s something you build for them?

Spotify Wrapped understood this. ‘I’m a top 1% listener of Japanese city pop’ is more powerful than any feature Spotify has ever shipped.

When we built archetypes into ExecReps, three things changed, and they map to frameworks any product team would recognize.

Retention jumped. Self-Determination Theory explains why: an identity satisfies all three psychological needs at once, competence (‘I’m a strong Diplomat’), autonomy (‘I choose to develop my style’), relatedness (‘I belong to the Diplomat tribe’). That’s Pink’s Mastery drive, visible progress along a path you’ve claimed as your own.

The product got easier to build. Archetypes gave us a design language. ‘You’re becoming a more commanding Diplomat’ is infinitely more motivating than ‘Your Command score increased by 40 points.’ Norman’s conceptual model principle: when the mental model is rich and intuitive, every communication taps into it.

Word of mouth ignited. BJ Fogg’s B=MAP model explains the mechanics: Motivation was sky-high (identity validation), Ability was trivial (screenshot and post), and the Prompt was the archetype reveal itself. All three maxed at the moment of discovery. We’d accidentally engineered sharing behavior at the exact point where Fogg’s equation was maximally favorable.

Two weeks later we shipped v1.3, the Executive Performance Score. Technically more sophisticated. Content weighted at 60%, delivery at 40%. Population-normalized. Objectively better.

Nobody shared their EPS on LinkedIn. They shared their archetype.

What I’d Tell Myself

If I could go back to early November 2025, deep in acoustic analysis, obsessing over signal processing, I’d tell myself: the most important feature you’re about to ship isn’t the most complex one. It’s the one that helps someone say ‘Oh, that’s who I am.’

Because the biggest barrier isn’t skill. It’s self-knowledge. Most people aren’t bad communicators. They’re communicating in environments that reward a style that isn’t theirs, and they’ve internalized that mismatch as a personal failing.

You’re not a bad communicator. You might just be a Diplomat in a room full of Commanders.

Once you know that, once you see it, you stop trying to be something you’re not, and start figuring out how to be the best version of what you already are.

This idea, this reframing, is at the core of what we’re trying to build with ExecReps. It’s about helping people find their voice, not just change it. I’m still learning how to articulate this, but it feels important.