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

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

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

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

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

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

The Data Layer: Measuring Everything, Understanding Nothing

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

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

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

The Information Layer: Context Without Consequence

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

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

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

The Knowledge Layer: Where Experience Meets the Numbers

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

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

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

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

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

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

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

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

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

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

Climbing the Pyramid

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

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

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

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

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

Sources

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

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

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

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

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

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

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

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

👋 Jay

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

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

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

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

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

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

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

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

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

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

Era 2: The Great Specialisation (2000–2015)

Then SaaS changed everything.

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

Enter the Product Marketing Manager.

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

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

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

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

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

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

By 2023, the backlash had arrived in full force.

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

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

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

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

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

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

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

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

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

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

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

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

So where does that leave us?

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

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

What I Am Hearing on the Podcast

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

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

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

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

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

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

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

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

👋 Jay

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

If you 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

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

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

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’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

In 2016, the PM job felt clean. Three jobs, one framework, minimal existential dread. Ten years later, a PM writes about burnout so deep that “just take a break” feels like a joke. Somewhere between those two moments, an entire profession lost the plot on what it was supposed to be.

I spent the last week reading through a decade of Product Coalition articles about the PM role. What I found is less a career arc and more an identity crisis playing out in slow motion.

Brought to you by ExecReps, AI-powered executive coaching for product leaders

“Three Jobs, Not Enough Time” (2016)

Christina Wodtke wrote The Three Jobs of Product Management back in 2016, and it still reads like the clearest thing anyone has said about the role. Business Owner. Vision Holder. Team Coordinator. That’s it.

But Christina also flagged something most people glossed over. “A Product Manager often has influence without authority,” she wrote. “She can’t fire anyone, or even get them off her team.” Think about that for a second. We spent years calling ourselves mini-CEOs when we couldn’t even choose who sat at our own table.

She also nailed something about the daily reality: “Product Managers, like all humans, tend to do the work that has the most screaming associated with it.” If you’ve ever abandoned your roadmap to fix a billing escalation, you know exactly what she meant.

“The Title I Prefer Is Servant Leader” (2022)

John McDonald didn’t tiptoe around it. His 2022 piece Why Acting Like the “CEO” of Your Product Might Be Doing More Harm Than Good went straight at the Horowitz memo that started it all. “Many a product managers use this line as a justification for their behavior,” he wrote. And honestly? I’ve seen it happen.

His replacement? “The title I prefer is ‘servant leader’. I get it, it’s not as sexy as ‘CEO’, but I think it’s a lot more evocative and representative of the role.”

Meanwhile, something awkward was happening. PM jobs had grown 230% between 2017 and 2022. But Kasey Fu confessed in The Hidden Value a PM Brings to the Product Team that engineers were still asking the uncomfortable question: “What value do you folks even bring?”

That line still makes me wince. Not because it’s unfair, but because most PMs, if they’re honest, have struggled to answer it clearly.

“Wait, Are We Even Needed?” (2023-2026)

Then AI walked into the room. Jing Hu put it bluntly in No Such Thing As An AI Product Manager: all product managers now have to swim in the AI pool. There’s no special “AI PM” title. There’s just PM, with a whole new set of capabilities to understand.

What fascinates me about Jing’s piece is the diagnosis underneath. PMs had become “button placers, conversion makers, document writers” for so long that bold technology actually felt unfamiliar. AI didn’t threaten the PM role. It exposed how small the role had become.

Then Dan Apps published the title that stopped the scroll. Product Management Is Broken: This Is Where It Ends. After 16 years in the field, Dan wrote that he’d been “quietly haunted by the same dysfunction” across every company. His verdict: “Product Managers need to stop internalising blame for a system that’s broken by design.”

And in early 2026, Irina Bulygina made it personal. I’m Burned Out and “Just Take a Break” Is Not Helping reads less like an article and more like a late-night conversation with a friend. “I sit on both sides of the barricades,” Irina wrote, “trying to understand everyone at the same time.”

This is the part that gets me. She’s not questioning the strategy frameworks or the org chart. She’s questioning whether the emotional cost of the job is sustainable. “Fear that AI is replacing us. Fear that the product manager role is becoming obsolete. Fear that we are watching the beginning of the end.”

What I’m Hearing on the Podcast

This tension showed up on the Product Coalition podcast too. In EP98, Margaret-Ann Seger argued that the best product ideas shouldn’t come from product managers at all. That’s the servant leader thesis taken to its logical conclusion: your job isn’t to have the ideas, it’s to create the conditions where good ideas surface from anywhere.

Brian Glassman explored the other side of the coin in EP81, making the case that generative AI can actually free PMs from the button-placing and document-writing that Jing described, letting them get back to the bold thinking the role was always meant for.

So What Does This Mean for You?

Here’s what I keep coming back to. The PM role has survived every identity crisis of the past decade. Mini-CEO, servant leader, empowered teams, AI disruption, burnout. It survives because the need for someone to hold the thread between business, technology, and users never goes away. The title changes. The job description changes. The core need stays.

So try this at your next dinner party. Someone asks what you do. You can’t say “product manager.” What comes out instead? I genuinely want to know. Hit reply and tell me.

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

Brought to you by ExecReps, AI coaching that helps product leaders practice tough conversations before they satisfice easy ones

The Quiet Recommendation (2016)

Before OKRs became a mandate, they were a suggestion. Christina Wodtke, author of Radical Focus, mentioned them almost casually in her 2016 piece ‘The Three Jobs of Product Management.’ Her take:

“Vision holding is the most neglected job of a PM, yet it is the one that makes teams and product succeed. (OKRs can help!)”

That exclamation mark and parenthetical still make me smile. OKRs weren’t yet the thing every VP demanded in their quarterly planning session. Christina framed them as a useful tool alongside team norms and mission statements. A helper, not a religion.

“30 Days and You’ll Never Look Back” (2018)

Two years later, the tone changed completely. Brad Dunn’s ‘Moving to OKRs in 30 Days‘ captured peak enthusiasm perfectly. He opened with an admission that tells you everything about the era:

“I have been talking to a LOT of people over the last few months about OKRs, more than I thought I would actually. It is such a hot topic.”

Brad’s confidence was infectious. Follow his plan, and in 30 days you’d be transformed. But I love this moment of honesty buried deep in the optimism: “Trust us here. The first cycle you do will be a mess, just accept that and get the cadence and routines down.”

The seeds of disillusionment were planted right inside the hype. Most people skipped past that line. I bet they wished they hadn’t.

The Warning Shot (2019)

Then Itamar Gilad showed up. A former Google PM (the company most associated with OKR success), Itamar wrote ‘5 Ways Your Company May Be Misusing OKRs‘ and dropped what I consider the single most important sentence in a decade of OKR discourse:

“OKRs are just containers for goals. They serve bad goals just as well as they do good goals.”

That line changed my thinking about frameworks in general. Containers don’t care what you put inside them. Itamar went further: “Bad OKRs can amplify the issues the org is troubled with rather than fix them.” Coming from inside the Google house, this wasn’t a hot take. It was a warning from someone who had watched OKRs fail at scale.

Seeking Alternatives (2023)

By 2023, the community had started publishing “what to use instead of OKRs” articles, which is the clearest signal any framework has crested its hype curve. Lee Fischman’s ‘Goal-Question-Metrics: A Holistic Alternative to OKRs‘ proposed GQMs as a more rigorous approach. His critique was specific:

“Why is asking questions so worthwhile? Look at the examples above and notice how their Key Results are basically arbitrary.”

Arbitrary. That word landed hard with anyone who had sat through a quarterly planning session watching leadership pick Key Results out of thin air. Lee didn’t reject OKRs entirely, but he exposed a real weakness: the framework skips the “why are we measuring this?” step.

The Framework Survives (2024-2026)

This is the part that fascinates me most. Noa Ganot wrote about OKRs for Product Coalition twice, two years apart, and watching her thinking deepen is its own story.

In 2024, her piece ‘OKR Planning: Break the Chains‘ treated OKR problems as therapy problems: “OKRs are meant to bring your dreams into reality. If you don’t eliminate these limiting beliefs, you are left with a lot of reality that shapes and limits your dreams.”

By January 2026, her perspective in ‘When OKRs Don’t Work, the Problem Is Elsewhere‘ had sharpened into something more profound. OKRs fail because “they surface gaps teams have learned to live with: unclear priorities, postponed decisions, and ownership that isn’t as solid as it looks.”

And then the line that closes the loop on a decade of debate: “The framework forces the question, but it can’t force the answer.”

Noa didn’t flip-flop between those two articles. She deepened. That’s rarer than you’d think in product writing.

What I’m Hearing on the Podcast

Andrea Saez joined me recently to talk about product strategy alignment, and her thinking connects directly to the OKR misuse thread. She’s been vocal about the difference between vanity metrics and meaningful customer KPIs, which is exactly where most OKR implementations go sideways. Teams pick Key Results that look impressive in a slide deck rather than ones that reflect actual customer outcomes.

Alex Blinov made a related point about how the PM role is shifting from “mini CEO” to strategic architect. When your job definition changes, the goals you set and how you measure them have to change too. Most OKR frameworks haven’t caught up with that shift.

So What Does This Mean for You?

OKRs survived the hype cycle. Not because they’re perfect, but because the problem they force you to confront (do we actually know what we’re trying to achieve?) never goes away. The framework is just a mirror. If you don’t like what you see, the answer isn’t a better framework.

Are you still using OKRs? Have you modified them beyond recognition, or abandoned them entirely? I’d love to hear what actually works on your team. Hit reply and tell me.

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’ve been reading through our archive of Product-Led Growth articles this week, and something funny kept happening. The earlier the piece, the more certain the author sounded. By 2023, everyone was hedging. That arc tells a story worth tracing.

Brought to you by ExecReps, AI coaching that helps product leaders practice tough conversations before they satisfice easy ones

When the Product Sold Itself (2021)

In 2021, Michelle Yick wrote a piece for us called ‘How to Spot a Product-Led Company‘ that captured the PLG dream perfectly:

“If sales, marketing, and customer support disappeared, the core product would still attract and retain users (albeit at a slower growth rate).”

Think about that claim for a second. If your entire go-to-market team vanished, you’d still grow. That was the promise. And for a handful of companies, it seemed true. Michelle pointed to Zoom as proof: “Remember when you tried Zoom and immediately told your friends, coworkers, and overseas relatives with terrible wifi to switch over?”

Around the same time, Sandhya Hegde published ‘The 3 Modes of Product-led Growth,’ tracing PLG’s roots back further than most people realize. She argued that “1983 was the true birth year of product-led growth,” pointing to AOL free trials and the GNU open-source movement. By 2006, companies like Box and Skype had the playbook: “giving away free plans and trials to entice their end users to adopt software that could grow virally within companies.”

Every startup wanted to be the next Slack. PLG wasn’t just a go-to-market strategy. It was an identity.

Everybody Tried to Be Slack (2022)

Surrbhi Soni’s ‘Slack: A Product Led Growth Strategy Case‘ reads like peak evangelism. Slack, Dropbox, and Zoom had “removed the myth that without product manuals, traditional lead generation, sales demos, and POC setup, a product cannot grow.”

But buried in the same article was a counterpoint nobody wanted to hear:

“Microsoft launched Team in 2016 and took over many customers of Slack, and currently has almost twice as many daily active users as Slack.”

Microsoft Teams didn’t win on product experience. It won by being free with Office 365. Enterprise CTOs picked the bundle, not the better tool. That should have been a warning sign for the whole PLG movement. But in 2022, the hype was still running hot.

Meanwhile, Noa Ganot was already seeing the backlash build. In ‘Three Wrong Reasons to Give Up on Product-led Growth,’ she pushed back against lazy dismissals. Her observation was sharp: “Product-led company and product-led growth are two different things. While you can’t do PLG without being a product-led company, the other way around is not necessarily true.”

That distinction matters more than most people realize. A lot of companies thought they were doing PLG when they were really just not hiring salespeople.

The Confession Booth (2023)

This is where it gets honest. Guy Barner, a founder who actually built a PLG company, wrote ‘To PLG, or not to PLG?‘ and dropped this line:

“Even though we went with PLG, I still don’t think it’s the best choice for most startups.”

That’s a PLG founder saying PLG probably isn’t for you. He went further: “Trust me, there are zero sales-led startups with good onboarding.” Sounds like a point for PLG until you read the rest. Guy explained that PLG requires you to nail everything at once: lead generation, website conversion, onboarding, product quality, and a freemium model that converts. With sales-led, you need a good product and good salespeople. That’s it.

Then Noa Ganot came back with ‘Product-Led Growth Is a Misleading Name‘ and shared a stat that stopped me cold:

“Research shows that up until $10M ARR, it’s much easier to succeed without PLG than with it. After $10M ARR the opposite is true, and PLG wins big time.”

So PLG works best for companies that already have serious traction. But most of the advice and tooling is aimed at early-stage startups. That gap explains a lot of the wreckage.

Get 5% off a group subscription

The Hybrid Reality (2024)

By 2024, the conversation had matured. Mart Objartel wrote about the challenges of choosing between product-led and sales-led strategies in ‘Navigating Challenges in Product-Led vs. Sales-Led Strategies for B2B SaaS,’ and he dropped the either/or framing entirely. His warning was practical: companies shift between strategies all the time, “sometimes subtly, akin to the proverbial frog boiling.” The real danger isn’t picking wrong. It’s changing direction without telling your product team.

Mart also highlighted something that rarely gets discussed. In sales-driven organizations, “aspiring product managers often feel constrained in effectively managing their products.” The PLG dream wasn’t just about growth metrics. For a lot of PMs, it was about autonomy. That’s partly why the backlash stung.

What I’m Hearing on the Podcast

Dan Balcauski joined me on the podcast to talk about SaaS pricing and packaging, and his perspective connects to PLG’s blind spot. Freemium tiers, trial-to-paid conversion, the whole pricing ladder that PLG depends on: those are the execution details where most companies fall apart. Dan’s insight about understanding customer value through qualitative research (not just usage data) explains why so many self-serve funnels leak. The product might sell itself. But if your pricing doesn’t match how customers experience value, the self-serve model collapses anyway.

(Listen to EP83 with Dan Balcauski)

So What Does This Mean for You?

PLG isn’t dead. But ‘PLG alone’ was always a mirage. The companies that tried to be Slack learned that being Slack requires being Slack: massive network effects, a product category that spreads virally, and enough runway to survive years of free users before revenue catches up. Most products don’t have those conditions.

What actually works for most teams is a hybrid. A product good enough that users want to try it, paired with humans who help close the deal. Not glamorous. Very effective.

I’m curious: did your company try PLG and pivot away? Or are you still running a self-serve motion? Reply and tell me how it’s going. I genuinely want to know.

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

Every couple of years, someone in our community writes a piece declaring the product roadmap dead. Then a few months later, someone else writes about how to build a better one. I've watched this cycle play out across 3,500+ articles over eleven years at Product Coalition, and I've started to think the roadmap isn't dying at all. It's molting.

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

The Gantt Chart Graveyard (2016)

In December 2016, one of our contributors, Swapna M, wrote a piece called ‘Product roadmap 2017‘ that perfectly captured where most teams were at the time. She laid out a top-down framework: Vision to Key Objectives to KPIs to Milestones. Pretty standard stuff. But then she dropped this line:

“I refuse to recognize Gantt charts as feasible tools to roadmapping though!”

That exclamation mark still makes me smile. She was frustrated. A lot of PMs were.

The tools we inherited from project management felt wrong for product work, but nobody had a clean alternative yet. Her solution was Trello boards and a strict no-deadlines policy. She wrote that she ‘personally does not put concrete deadlines since new variables get introduced randomly everyday in a startup environment.’

Looking back, this was the era of rebelling against the format without questioning the content. We stopped using Gantt charts. We kept building feature lists. Just on prettier boards.

The Outcome Turn (2019)

By 2019, the conversation had shifted. Elena Sviridenko published ‘Outcome-driven product roadmap‘ on Product Coalition in March of that year, and you could feel the frustration had evolved into something more focused. She started with this observation:

“Many organizations struggle with roadmaps, finding them difficult to maintain and hardly ever coming true.”

That resonated with thousands of readers. But the real gut punch came later in the piece:

“Prioritizing without knowing the context of the problem and the desired outcome is like shooting in the dark.”

Elena introduced the Now/Next/Future framework to our audience. Not features slotted into quarters, but problems organized by urgency. It sounds obvious now. In 2019, it felt radical. I remember the comments section on that article being split between PMs who found it liberating and PMs whose stakeholders would never accept a roadmap without dates.

The outcome-driven movement gave PMs a vocabulary to push back. ‘We’re solving for this outcome’ is a different conversation than ‘we’re shipping this feature in Q3.’ Better conversation, honestly. But it also created a new problem: roadmaps that were so abstract they didn’t actually communicate anything to engineering teams or executives.

Principles Over Process (2023-2024)

This is the part that fascinates me. John Utz published two pieces with us. ‘What is a product roadmap?‘ in May 2023 and ‘Rethinking product roadmaps‘ in November 2024. I think they represent where roadmap thinking has landed. In the earlier piece, he tells a story about pitching features to a stakeholder who stopped him cold:

“You are just sharing features; that’s your release plan.”

Ouch. John went on to frame the roadmap as fundamentally a communication tool, citing Bruce McCarthy’s definition: “A product roadmap is a tool for communication and alignment. It tells the story of where you are, where you are going, and how you will get there. It is not a project plan or a commitment. It is a strategic document.”

Then in late 2024, John came back with a first-principles framework. Eight principles for building roadmaps, rooted in the Elon Musk approach of questioning every assumption. He wrote:

“It’s the difference between following a recipe and understanding the chemistry of cooking.”

I think this captures the maturation perfectly. In 2016, we were arguing about the tool (Gantt chart vs. Trello). In 2019, we were arguing about the content (features vs. outcomes). By 2024, we’re arguing about the thinking underneath. The recipe doesn’t matter if you understand what each ingredient does.

John also admitted something most roadmap evangelists won’t: “We were behind our competition, pumping out features with low value, slow to release, and pandering to our stakeholders, not our customers.” That kind of honesty only shows up when someone has been through the full cycle.

What I’m Hearing on the Podcast

On a recent episode of the Product Coalition podcast, Valentina Coin told me something that reframed how I think about all of this. We were talking about change management and she said: “You have a human being that is grieving the way things were, very comfortable, very familiar. Maybe they took a little bit longer to get done. Maybe it was a little bit inconvenient, but it was familiar.”

She was talking about digital transformation broadly. But I couldn’t stop applying it to roadmaps. Every time we reinvent the roadmap format, teams have to grieve the old one.

The PM who mastered the Gantt chart had to let it go. The PM who perfected the feature-based quarterly roadmap had to learn outcomes thinking. Now we’re asking people to operate on principles. That’s harder. And people resist harder things, at least at first.

(Listen to EP100 with Valentina Coin)

So What Does This Mean for You?

The roadmap didn’t die. It grew up. And here’s what I’d actually take away from watching a decade of this evolution: stop optimizing the artifact and start getting better at the conversation around it. Your roadmap format matters less than whether your team and stakeholders walk away from a roadmap review aligned on what matters and why.

I’d love to hear from you. What does your current roadmap actually look like? Reply to this email and tell me, genuinely curious whether you’re still in the outcome camp or if you’ve moved on to something else entirely.

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

“Just put your crash helmet on, and get on with it.” - That’s been my philosophy since 2007 when I pivoted from design to product. Now, with AI reshaping everything, it’s time to put that helmet on again.

Jay here.

After interviewing dozens of product leaders on our podcast (17,000+ downloads and counting), reading insights from our 1M+ annual readers across 225 countries, and engaging with our 11,000+ Substack followers, one thing is crystal clear:

The AI skills gap is creating two classes of product managers: Those who’ll thrive in 2026, and those who’ll be left behind.

Why I Built This Tool (And Why You Need It)

Look, I’ve been through major tech transitions before. Web to mobile. Desktop to cloud. Waterfall to agile. Each time, the PMs who adapted early won.

This time is different. The speed is unprecedented.

The Reality Check:

• 98% of PMs use AI but only 39% have proper training [Business Wire, Nov 2024]

• 66% admit using shadow AI - unapproved tools that could breach compliance [Business Wire, Nov 2024]

• EU Digital Product Passport hits in 2026 - are you ready? [Salsify, 2025]

• 82% of organizations will use AI agents by 2026 [Analysts Corner, 2025]

When I founded Product Coalition in 2014, the mission was simple: Make mastery of product management globally accessible.

Today, that means helping you master AI before it masters you.

Introducing: The 2026 PM AI-Readiness Scorecard

We’ve taken everything we’ve learned from:

• 3,500+ articles published on Product Coalition

• Interviews with leaders like Tamar Yehoshua (ex-CPO Slack) and Rich Mironov

• Our recent podcast with Chris Butler from GitHub on AI in Product Ops

• Research from McKinsey, Gartner, and MIT

• Feedback from our global community spanning 225 countries

And distilled it into one comprehensive tool that gives you exactly what you need.

What Makes This Different

Most AI assessments are generic. Built by consultants who’ve never shipped a product.

This one’s different. It’s built by a PM (me), tested by PMs (our community), for PMs (you).

From my experience leading product teams across the world over 25 years, I know what actually matters:

• Actionable insights, not theory

• Role-specific guidance (B2B SaaS PM needs different skills than B2C PM)

• Visual dashboards (because we’re visual thinkers)

• Progress tracking (what gets measured gets done)

• Regulatory readiness (2026 compliance is non-negotiable)

🚀 The Game-Changing Dashboard (Why PMs Love This)

Remember when I taught Lean Product Management at General Assembly? First thing I’d say: “If you can’t see it at a glance, you can’t manage it.”

That’s why we built a dashboard that would make any data-loving PM smile:

📊 Executive Summary Section

What it shows: Your overall AI readiness score (huge, can’t miss it), readiness level (🚀 AI-Ready to ⚠️ Needs Attention), and personal profile.

Why it matters: One screenshot to share with your manager. Shows commitment to growth and current capability in seconds.

💯 Key Metrics Cards

What it shows: Four critical KPIs - Skills Gap Average, Target Achievement %, Critical Gaps Count, Industry Comparison (+/- score).

Why it matters: Instantly see where you stand. No digging through data. These are the numbers that determine your AI readiness and market value.

📈 Skills by Category Breakdown

What it shows: Performance across 5 categories (AI Fundamentals, Product Skills, Technical Skills, Data & Analytics, Governance) with status indicators.

Why it matters: Identifies exactly which areas need attention. Stop wasting time on strengths when gaps are killing your effectiveness.

💪 Strengths vs Improvement Areas

What it shows: Your top 3 strengths and top 3 gaps, side by side.

Why it matters: Balance is key. Leverage strengths while systematically addressing weaknesses. This view prevents blind spots.

📊 Category Comparison Chart

What it shows: Visual progress bars comparing You vs Target vs Industry for each category.

Why it matters: See gaps visually. The ■□ symbols show progress at a glance. Perfect for visual learners and progress tracking.

🎯 AI Journey Timeline

What it shows: 4 milestone levels with dates: Foundation (30 days) → Developing (60 days) → Advanced (90 days) → AI-Ready (120 days).

Why it matters: Transforms vague goals into concrete milestones. You know exactly what to achieve by when.

⚡ Quick Stats Panel

What it shows: Total skills assessed, skills at target, days to 2026 deadline (countdown!), recommended study hours/week.

Why it matters: Critical context at a glance. That deadline countdown? It’s a daily reminder that time’s running out.

🎯 AI Readiness Meter

What it shows: Visual meter using 🟢⚪ circles showing your % AI-ready.

Why it matters: Gamification works. This simple visual motivates daily improvement. Share it on LinkedIn to show progress.

🚀 Next 3 Actions (Red Alert Box)

What it shows: Three prioritized actions based on your assessment, including your biggest gap and DPP compliance status.

Why it matters: Eliminates analysis paralysis. You know exactly what to do next. No more wondering where to start.

📈 Progress Tracker

What it shows: Historical tracking of assessments with dates, scores, and notes.

Why it matters: Prove your growth. Document your journey. Show consistent improvement to stakeholders.

Plus Four More Power-Packed Tabs

🎯 AI Skills Assessment

20 competencies with role-specific targets, industry benchmarks, visual gap analysis, and automatic priority ranking.

🔍 Quick DPP Check

8-point compliance checker with Yes/No dropdowns, instant scoring, priority levels, and action recommendations.

🎓 Learning Path

90-day roadmap broken into monthly milestones, linked to your actual gaps, with progress checkboxes.

📘 Welcome Page

Professional cover with my background, Product Coalition’s story, and how to use the tool effectively.

The Interactive Elements That Make It Addictive

We’ve learned from our 20,000+ newsletter subscribers what keeps PMs engaged:

• Dropdown menus everywhere - No typing required

• Role selector - Choose your PM type, everything recalculates

• Conditional formatting - Colors change based on your scores

• Data bars - Visual progress in every score cell

• Auto-calculations - Everything updates in real-time

• Emojis throughout - Because spreadsheets don’t have to be boring

Here’s What Happens Next

You have two choices.

Option 1: Keep doing what you’re doing. Use ChatGPT casually. Hope for the best. Watch as AI-fluent PMs get the promotions, the raises, the opportunities.

Option 2: Take 20 minutes today. Complete the assessment. Get clarity on exactly where you stand and what to do about it.

From my experience transforming teams blobally, I can tell you: The ones who act early always win.

Why This Is Free (And Always Will Be)

Product Coalition has always been about community first. No ads. No sponsors. Just pure value.

This scorecard is my way of giving back to the community that’s given me so much. From the talented people who’ve become friends, to the insights you’ve shared on Medium, to the 1M+ readers who trust us monthly.

We succeed when you succeed. It’s that simple.

GRAB YOUR COPY BELOW

A Personal Note from Jay

I’ve been through enough transitions to know: The scariest moment is right before you start.

When I moved from Sydney to Lisbon, when I left corporate to start Product Coalition, when I shifted from design to product – each time, the hardest part was taking that first step.

This scorecard is your first step. It’s not about being perfect. It’s about knowing where you are so you can get where you’re going.

As I always say: “Just put your crash helmet on, and get on with it.”

Let’s get on with it together.

Cheers,
Jay Stansell
Founder, Product Coalition
Connect on LinkedIn | ProductCoalition.com

GRAB YOUR COPY BELOW

Get Your AI-Readiness Scorecard Now →

1

The professionals who win in this next era won’t just do great work — they’ll be known for it. - Jay Stansell

We are living through the fastest change to career dynamics in decades.

AI tools can automate tasks.

Job descriptions are being rewritten.

Recruiters are changing how they find talent.

Visibility is currency.

And while skills still matter — perception and profile are becoming equally important.

It’s Time to Reposition Yourself for This New Reality.

This is especially true if you work in:

• Product Management

• Engineering

• Data or Data Science

• UX or Design Leadership

• Executive, Strategy, or Operations

• Technology Leadership (CTO, CFO, CPO)

You might be brilliant — but if nobody can find that brilliance, it might as well not exist.

This is why Product Coalition created Promote Me — a membership for ambitious professionals who understand that their next role, next raise, or next opportunity will come because of their public profile — not in spite of it.

Subscribe now

Why Does a Podcast Matter Now?

Podcasts are the most underutilized career asset available today.

They are searchable, evergreen, and emotive.

A podcast episode about you:

• Captures your story and expertise in your voice.

• Positions you as a thought leader in your field.

• Lives forever online.

• Shows hiring managers, recruiters, and your network that you are an active, strategic professional.

And at Product Coalition, we don’t just record it — we amplify it.

We Promote You To:

• 10,000+ LinkedIn product followers

• 10,000+ Substack readers

• 20,000+ community subscribers across platforms

• Global search engines forever.

This is professional reputation-building at scale.

Why a Newsletter Too?

Because words travel further than resumes.

A well-written newsletter about your expertise:

• Positions you in your category.

• Connects your name to topics people are searching for.

• Acts as your professional calling card.

This isn’t optional anymore — it’s smart career insurance.

Subscribe now

What’s the Real ROI?

Having a podcast and newsletter about you is not just content.

It’s:

• Job security (internal leaders notice).

• Job mobility (external recruiters discover you).

• Future-proofing (AI won’t automate your story).

• Community building (your network grows with you).

Subscribe now

And Here’s the Best Part — It Lasts Forever.

Social posts disappear in 24 hours.

A podcast and newsletter distributed by Product Coalition are discoverable for life.

Google your name in 3 years — this content will still be working for you.

Ready to Future-Proof Your Career?

We only have limited spaces for Promote Me members this year.

If you’re serious about repositioning yourself for the next era of work — now is the moment to act.

Let’s make your next podcast, newsletter, and event all about what matters most — you.

Subscribe now

Here’s what I’m covering this week:

1. 🤔 EVENTS: Product Strategy; Leveraging My Disability

2. 📝 COMMUNITY ARTICLE: Software Engineers Are Not Fungible

3. 🗒️ KNOWLEDGE: Product Hiring with AI in 2025 (without HR)

4. 🎧 PODCAST: Breaking Blockchain Barriers

5. 👉 OPEN TO WORK

LIVE EVENTS

🤔 Want your own live event to elevate your professional profile to 15k LinkedIn followers? Subscribe as a Premium Member! More details here.

What Is Product Strategy Exactly? And Why It Matters

Leveraging My (Dis)ability

COMMUNITY ARTICLE

📝 Want to write for Product Coalition on Medium? Subscribe on Substack and receive the info!

Software Engineers Are Not Fungible

Different engineers. Different skills. Different value.

🗒️ KNOWLEDGE: Product Hiring with AI in 2025 (without HR)

Last week, while sorting through applications for our new senior product role, I remembered how we used to hire back in 2015. Mountains of CVs, gut feelings, and hoping for the best. Fast forward to today, and there I was, using AI to spot patterns I'd have missed entirely.

McKinsey's latest research backs up what I've been seeing: organizations using AI in talent management are 83% more likely to have made successful hires. But here's what caught my attention - it's not just about finding people anymore. It's about understanding them.

Let me share what I've learned about using AI in talent management, including some specific prompts that have changed how I approach hiring.

Oh, and I’ve written this approach for those without HR teams (or those that want to keep HR team usage to a minimum), mainly because for most of my career in startups this has been how I’ve discovered the top 1% of talent.

Creating Job Posts That Are Talent Magnets

First up, let's talk about writing job descriptions. Textio's analysis shows that AI-optimized job posts get 25% more qualified applicants. I've been experimenting with AI to create posts that don't just list requirements but tell a story about the role. My hack; put the 90-day onboarding plan in the advert - the top talent LOVES this! It shows planning, foresight, transparency and organisation.

Here's the prompt I use:

"Act as a hiring manager for a product-led organisation. Write a concise, engaging, and inclusive job description for a Senior Product Manager role focused on AI and data analytics. Ensure it highlights collaboration, growth opportunities, and company culture."

Smarter Resume Assessment

LinkedIn data shows that hiring managers spend an average of 7.4 seconds per resume. In a pile of 300 applications, that's a recipe for missing great talent. Here's how I use AI to dig deeper:

Refined ChatGPT Prompt:
"You are a recruitment assistant. Compare these resumes (provide/paste details) against the following criteria (list your needs). Create a ranking of the candidates with a summary of their strengths and weaknesses."

Mining Your Talent Database

Remember that great candidate from six months ago who wasn't quite right for that role? They might be perfect for your current opening. Gartner reports that companies with strong internal talent mobility retain employees for twice as long.

Here's my prompt for revisiting past applications:

"Act as a talent scout. Given this database of past applications (paste details), identify candidates who meet the following job criteria (list specific qualifications). Highlight relevant experience and provide recommendations."

Culture Fit: The Make or Break Factor

According to Deloitte's research, poor cultural fit can cost an organization between 50-60% of the person's annual salary. I've found AI particularly helpful in crafting questions that reveal cultural alignment:

"You are an HR expert. Create five interview questions designed to evaluate a candidate's cultural fit for a fast-paced, collaborative product management team. Focus on teamwork, adaptability, and long-term alignment."

Testing That Actually Tests

Gone are the days of generic coding tests. Harvard Business Review found that companies using AI-designed assessments see a 40% better prediction rate for job performance. Here's my go-to prompt:

"You are a product management trainer. Create a 30-minute case study task for a Product Manager candidate to solve. The task should test prioritisation, problem-solving, and communication skills. Provide clear instructions and evaluation criteria."

Getting Salary Right

Read more

Subscribe now

Here’s what I’m covering this week

1. 🤔 EVENT: A.I. LIVE EVENT DAY - 3 SPECIAL EVENTS FRIDAY

2. 🗒️ STUDY WITH JAY: Digital Twins

3. 🎧 PODCAST: EP67 Breaking Blockchain Barriers

4. 📝 COMMUNITY ARTICLE: The Puppet Master Without Strings: How I Learned to Influence

5. 👉 OPEN TO WORK

A.I. LIVE EVENT DAY - 3 SPECIAL EVENTS

🤔 Want your own live event to elevate your professional profile to 15k LinkedIn followers? Subscribe as a Premium Member! More details here.

STUDY WITH JAY: Product Shadow Powers

🗒️ Each week I share what I’m studying, with the world. This week I’m studying digital twins and the opportunity for SaaS.

Last month, I was having a virtual coffee with Sara, the CTO of a rapidly growing SaaS platform. "You know what saved us last month?" she asked, stirring her flat white. "Our digital twin spotted a potential system collapse before any alarms went off. Saved us from what would have been a nightmare."

Now, if you're thinking digital twins are just for factories and fancy manufacturing plants, you're in for a treat. The software world has taken this concept and turned it into something rather brilliant for SaaS platforms. Mind you, getting it right isn't exactly a walk in the park, but the payoff is worth every bit of effort.

Let me share what I've learned from chatting with some SaaS product people who have or are setting up digital twins, and why this matters more than ever for your business.

The Real Deal About SaaS Digital Twins

Think of a digital twin as your platform's stunt double. While your actual system handles the day-to-day operations, its twin runs scenarios, spots potential issues, and gives you insights you never knew you needed. Matterport's been doing incredible things with this technology, creating digital replicas that do more than just look pretty – they provide actionable insights that make proper business sense.

AWS IoT TwinMaker has made this technology more accessible than ever. One of my contacts, a logistics software provider, used it to model their entire distribution stack. Within three months, they'd found inefficiencies that were costing them thousands. Pretty clever stuff.

A Proper History Lesson (But the Interesting Kind)

Read more

Subscribe now

Here’s what I’m covering this week

1. 🗒️ STUDY WITH JAY: When Thoughts Become the New SaaS Market

2. 🎧 TWO PODCASTS: Services Management and 2025 Intro to Video

3. 🤔 EVENT: AI FRIDAY EVENTS DAY - 3 Dedicated AI+Product Sessions

STUDY WITH JAY: Who needs keyboards when you’ve got brainwaves?

🗒️ Each week I share what I’m studying, with the world. This week I’m studying The Brain Computer Interface Platform Revolution, and paid members can DM me to access my notebook here.

The BCI SaaS Gold Rush has begun

I’ll be honest, this has been one of the hardest newsletter topics to research and write. 

Bringing a product mindset to brain computer interfaces seemed like an exciting product opportunity landscape, but when you start pushing hard on finding verifiable sources, it becomes very challenging.

However, I hope you’ll enjoy the opportunities I’ve uncovered below, which in summary is best positioned as this… AI/ML and BCI will come together to give us revolutionary new ways to interact with our computers, and all of that opportunity begins now, in the software space.

Once we get healthy, approved and validated hardware, an entire new market of SaaS will open up.

BCI is Brain-Computing Interface - yep hooking your noggin up to a computer. While everyone's obsessed with the AI and BCI hardware race, I've spotted something very interesting in the software layer.

After spending three weeks deep in developer documentation and chatting with engineering teams, I've seen a pattern that most market watchers are missing. Sure, Grand View Research's latest market analysis gives us the big numbers - $1.9 billion market value, headed to $5.1 billion by 2030. But the real story lies in where this growth is coming from.

Also, Palantir possibly getting friendly with Blackrock Neurotech signals big tech's serious interest in BCI software platforms. Their focus on developing cloud infrastructure for neural data processing validates the growing SaaS opportunity.

But what could this mean? Well let me take you to 2035 and then let’s come back to the current state.

Emma in 2035

At 7:00 AM, Emma awakens as her smart home system gently adjusts the lighting and temperature, responding to her brain’s natural waking patterns detected by her non-invasive Brain-Computer Interface (BCI) headband. This device monitors her sleep cycles, ensuring she wakes at an optimal time, feeling refreshed.

During her commute, Emma reviews emails and schedules meetings using her BCI-enabled augmented reality glasses. By focusing on icons, she can compose messages and set appointments, streamlining her workflow without physical devices.

At the office, Emma collaborates with colleagues through a BCI-integrated platform that allows for seamless idea sharing and brainstorming. This technology enhances team productivity by enabling direct thought communication, reducing misunderstandings and increasing efficiency.

Midday, Emma’s BCI alerts her to elevated stress levels. She initiates a guided meditation session through her neural interface, which helps regulate her breathing and heart rate, promoting relaxation. This proactive approach to mental health is facilitated by continuous monitoring of neural signals.

In the evening, Emma engages in a virtual reality game controlled entirely by her thoughts. The immersive experience adapts in real-time to her emotional responses, providing a personalized entertainment experience that was unimaginable a decade earlier.

Before bed, Emma decides to learn a new language. Her BCI connects to an educational platform that stimulates specific brain regions associated with language acquisition, accelerating her learning process and making it more intuitive.

So, what’s making Emma’s day a possibility?

Read more

Subscribe now

Here’s what I’m covering this week

1. 🗒️ STUDY WITH JAY: Biomimicry in Design: Nature-Inspired Innovation

2. 🎧 AUDIO STUDY SUMMARY: 21 minutes

3. 🎧 PODCAST: EP64 The Psychology of Business Agility

4. 🤔 EVENT: 2 new live events this week

5. 📝 COMMUNITY ARTICLE: Stockholm Syndrome with Work: When Your Job Takes You Hostage

6. 👉 OPEN TO WORK

STUDY WITH JAY: Biomimicry in Design

What do Amazon, Netflix and squirrels have in common?

🗒️ Each week I share what I’m studying, with the world. This week I’m studying Biomimicry in Design, and paid members can request access to my notebook here.

"Mate, Your Product Strategy Might Need Some Gecko Feet"

Right then, there I was in my office last Tuesday, proper distracted by this cheeky gecko on my window. As you do. While we product folks were all wrapped up in our fancy methodologies and sprint planning, this little master of gravity got me thinking - nature's been running the world's most successful R&D lab, and here's the brilliant bit: she's happy to share her code base with us.

Crikey, talk about a humbling moment.

The Billion-Year Head Start

We product folks pride ourselves on our agile methodologies and innovative solutions. Yet here's something to consider with your morning coffee: nature's been perfecting these practices for 3.8 billion years. That's one impressive sprint backlog!

Take that gecko on my window. It uses millions of tiny hairs creating something called van der Waals forces - physics so elegant that scientists still marvel at its simplicity and effectiveness. [^1]

Mother Nature: The Ultimate Product Mentor

Let me share this week's discoveries, about resilient systems in nature. For any product leaders thinking "Jay's gone full David Attenborough," stick with me - this will transform how you think about product strategy.

The Fire-Tested Framework

Organisms thriving in fire-prone environments serve as brilliant strategists, employing three approaches that would make any product architect envious:

1. Full-spectrum security: They develop general resilience, creating robust architectures that handle both today's challenges and tomorrow's unknowns. Entropic Materials applies this principle in their self-degrading plastics, mimicking protective chaperone proteins. [^2]

2. Built-in redundancy: Nature champions multiple backup systems. Consider how plants develop complex root networks. When did you last review your system's redundancy plans?

3. Sacrificial systems: Think of it as strategic feature deprecation - letting go of one component to protect the core product's integrity.

Nature's Resource Management Masterclass

Right then, before we dive into more tech examples, let's talk about how nature handles its resources. And trust me, this is where it gets properly interesting.

The Squirrel Economy

Ever watched a squirrel during autumn? These little fellows make your typical ERP system look primitive. They'll gather thousands of nuts, distribute them across hundreds of locations, and somehow remember where about 90% of them are buried. It's like watching a master class in inventory management and distributed systems.

Here's what product leaders can pinch from our bushy-tailed mates:

1. Distributed Resource Management

   • Store resources close to where they'll be needed

   • Create multiple backup locations

   • Build in redundancy for critical resources
     Real-world example: Amazon's distribution center strategy mirrors this approach, placing inventory strategically near demand centers.

2. Seasonal Planning
   Just as squirrels know when to start gathering for winter, successful products anticipate and prepare for changing conditions. Take Netflix's content strategy - they're constantly gathering and distributing new content, adjusting their library based on predicted viewing patterns.

The Bamboo Bootstrap

Here's another brilliant bit of natural wisdom. Bamboo might look like it's growing slowly for ages, but it's actually building an extensive root system. Then - boom! It can grow up to 91cm in a single day (much like the last 25 story points on last day of the sprint?).

Sound familiar? It's the same pattern successful products use:

• Build robust infrastructure first

• Create strong foundations

• Scale rapidly when conditions are right

Nature's Just-in-Time Manufacturing

Consider how a spider builds its web:

• Uses exactly the right amount of silk

• Creates structures that are both strong and efficient

• Repairs and recycles materials constantly

This isn't just clever - it's genius level resource optimization.

The M4 Robot: Nature's Engineering Masterpiece

Let me introduce you to the M4 robot - or as the technical folks call it, the "multimodal mobility morphobot." (Good luck saying that three times fast!)

Nature's Swiss Army Knife

The M4 excels at flying, rolling, crawling, and tumbling - and that's just the beginning. Its real genius lies in how it chooses between these abilities.

Consider a sea lion: graceful swimmer in water, adaptable waddler on land. Or watch meerkats: swift runners on all fours one moment, alert sentinels standing tall the next.

The M4 embodies this adaptability. Each of its four limbs transforms for different situations:

• Wheels for efficient ground travel

• Legs for rough terrain navigation

• Thrusters for aerial maneuvers

Engineering Brilliance

The M4 replicates both animal forms and intelligence. Its sensors and onboard computers enable:

• Terrain analysis (like a mountain goat evaluating its next leap)

• Energy-efficient movement selection (matching animals' natural conservation instincts)

• Seamless mode transitions (as smooth as a bird switching from walking to flight)

Watch it in action: On flat ground, it rolls efficiently. Encountering an obstacle? It takes flight, then returns to rolling once clear. Facing a steep slope? It combines movement types for optimal performance.

Your Product Strategy Connection

Let's connect this to your product development:

1. Adaptive Design
   The M4's morphing abilities mirror how your products should adapt to user needs. Consider how your interfaces could flex for different contexts, or how your architecture might scale under varying demands.

2. Energy Efficiency
   The M4's movement optimization offers lessons in resource management. Time to audit your product's resource usage?

3. Intelligent Transitions
   Study the M4's seamless mode switching. How smooth are your product's state transitions and user journey handoffs?

Here's something to make you smile - and think. I've translated Mother Nature's human development project into proper product management speak. The results? Eye-opening...

MOTHER NATURE'S PRODUCT ROADMAP

Human Evolution Enhancement Project v2024

Status: Thriving (3.8 billion years of continuous deployment)

Product Owner: Mother Nature
Scrum Master: Natural Selection
Key Stakeholder: Humanity (actively participating)

Read more

Subscribe now

Here’s what I’m covering this week

1. 🗒️ STUDY WITH JAY: Product Management in the Quantum Age

2. 🎧 PODCAST: Challenging the Status Quo in CRO

3. 🤔 LIVE EVENTS NEXT WEEK

4. 📝 COMMUNITY ARTICLE: Have You Learned Nothing From Your Retros?

5. 👉 OPEN TO WORK

STUDY WITH JAY: Quantum Computing's PM Challenge

🗒️ Each week I share what I’m studying, with the world. This week I’m studying Quantum Computing, and paid subscribers can request access to my shared notebook here.

Here’s what I’m going to cover…

• The truth about quantum product development

• Why most product playbooks fail in quantum environments

• Real stories from PMs tackling quantum projects

• Plus a framework for managing quantum teams that actually works

The Morning My Product Brain Broke

5:43 AM. Saturday. I'm at home, scrolling through research papers because sleep is apparently optional. My awesome geisha coffee hasn't kicked in yet when I stumble across a quantum computing paper that makes me spill my geisha all over my laptop.

(At least it was a quantum spillage - the coffee existed in both a spilled and unspilled state until I observed it. Physics humor, anyone? No? Really? Moving on...)

The paper revealed something fascinating: companies are already shipping quantum products. 

• Not proof of concepts! 

• Not lab experiments! 

• Real, proper, revenue-generating quantum solutions!

It's All Gone a Bit Weird, Hasn't It?

Remember when quantum computing was just that thing physicists talked about at conferences? Recent research shows quantum technology has snuck out of the lab while we weren't looking (or too busy looking at AI).

Here's what's actually happening, whilst we’re all focusing on AI ethics…

In Financial Services

Picture this: A trading floor in Manhattan. Screens everywhere. Traders doing their trader things. But in the background, quantum algorithms crunch through portfolio optimizations that would make classical computers cry.

In Drug Discovery

Studies in molecular modeling show quantum computers simulating chemical reactions in hours that would take classical computers centuries. That new cancer drug? It might come from a quantum computer.

In Supply Chain

Remember that chip shortage that made it impossible to buy a PS5? New quantum optimization techniques could help prevent the next one.

The Product Manager's Quantum Crisis

Last week, my mate Sarah (a seasoned PM at a fintech) messaged me at midnight. "Jay," she said (the no “Hi” gave it away as a serious message), "my CEO just announced we're building a quantum division. I've got six months to deliver something. Help."

Blimey. Where do you even start?

Why Your PM Toolkit Just Exploded

According to groundbreaking research in quantum software development, traditional product management tools fall apart in quantum environments. Here's why:

1. The Observer Effect (No, Really)

In classical software, you can monitor your system without affecting it. But in quantum? Recent studies show that observing your quantum system literally changes its behavior.

Imagine trying to run A/B tests when the act of measuring your results affects the outcome. It's like Schrödinger's Product Analytics - your metrics exist in multiple states until you look at them.

You with me? No? I’m barely with me too, so, here’s another example…

Imagine you have a row of toy soldiers (these are ions in the experiment) lined up in a very chilly place (a cryogenic quantum register). Each soldier is supposed to follow only their own orders, but sometimes they hear the instructions meant for their neighbour and get confused (this is called crosstalk). This confusion isn’t helpful for the team, so scientists are trying to stop it.

To give each soldier their orders, scientists use tiny laser beams—like laser pointers focused precisely on each soldier. But sometimes, these lasers spread out a little and accidentally give neighbouring soldiers mixed signals. To fix this, the scientists came up with a clever trick: they shine an extra light beam at each soldier’s neighbour, which cancels out the confusing signals. It’s a bit like playing a sound that cancels out background noise, letting each soldier only hear the orders meant for them.

The scientists tested this by seeing how well each soldier could follow orders after using this trick. They found that with the right setup, they could almost completely get rid of the “mixed signal” problem, and each soldier behaved almost perfectly! This means the soldiers can now work together better, and the scientists are even trying other tricks to make sure their commands don’t get jumbled in the future.

2. The Two-World Problem

Here's something wild from IBM's quantum research team: every quantum product actually needs two parallel development tracks:

• The quantum implementation

• A classical simulation of the quantum implementation

It's like building a rocket while simultaneously maintaining a perfect video game version of that rocket. Both are essential. Both need different teams. Both need different tools.

3. Error Rates: Your New Best Friend

Remember how we obsess over five nines of reliability? New research shows quantum systems follow different rules entirely. Some quantum algorithms actually perform better with certain types of errors. Mad, right?

The Quantum PM's Survival Guide

After consoling Sarah, I've put together what I'm calling the Quantum PM's Survival Guide. Based on empirical studies and, frankly, a lot of trial and error:

1. Embrace the Hybrid Approach

Research published in Nature shows the most successful quantum products aren't pure quantum plays. They're hybrid solutions that cleverly combine classical and quantum approaches.

For example, when JP Morgan Chase's quantum team optimizes portfolios, they use:

• Classical computers for data preparation and constraint definition

• Quantum algorithms for exploring the massive space of possible portfolio combinations

• Classical systems again for finalizing and presenting results

Each mode for its proper purpose. No one teleports to their kitchen for a snack.

Read more

Subscribe now

Here’s what I’m covering this week

1. 🗒️ STUDY WITH JAY: Matter and IoT (and learnings for SaaS)

2. 🎧 PODCAST: Challenging the status quo in CRO

STUDY WITH JAY: Is Matter the Glue or the Mess of IoT?

“My window sensors still aren't on speaking terms!” - Me

🗒️ Each week I share what I’m studying, with the world. This week I’m studying Matter and IoT. Paid subscribers can DM me for access to my notebook here.

Hey there! 👋

I've been neck-deep in smart home devices lately, and let me tell you - it's both exciting and frustrating. Last week, I spent hours trying to get my smart lights to talk to my thermostat (spoiler: they still aren't on speaking terms). This got me thinking about the bigger picture of IoT and where we're headed.

So, this week’s newsletter is packed with information about the smart home and IoT landscapes which continue to expand making interoperable solutions becoming critical.

And I won’t lie, this took me down memory lane. You see back in 2015, I was contracting for Telstra (AT&T for Australia), and I was dedicated to their smart home product offering. It was the honeymoon period of IoT, and as a product manager with a software background, it exposed me to an incredible world of hardware, firmware and industrial design principles that have stuck with. 

One of my most memorable moments was, during a contextual inquiry, seeing how a household's tech decisions are made. The husband, who’d just spent $300 on a bookshelf based camera that he was so excited to unbox, was so excited. He unboxed like he’d birthed it. He placed it on the shelf like a proud father. Within 0.002 seconds of it landing and disturbing the dust, a massive “NOPE! NOT HAVING IT!” belted from across the room.

You see wifey had just spent $10k redecorating the lounge, and the industrial design of this futuristic curvy black plastic tech with it’s dangling black twisted plastic coated cord, just didn’t match the Hampton’s inspired decor. That day I was strongly reminded that industrial design research and testing needs to be with all the persona’s whose lives it will intrude!

Anyway, this week I’ll explore Matter—the emerging standard for device interoperability—and how smart product management can make or break your IoT strategy. 

I’ll also touch on:

• Security

• Intermittent device challenges

• Lessons for SaaS

• Unresolved issues that product leaders need to keep in mind

If you’re a CPO, CFO, or CTO, this could offer some valuable insights into where IoT is heading and how your teams can stay ahead of the curve. Even if you’re not in the IoT game, I’ll be connecting learning from IoT over to SaaS for you.

Read more