Read more

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

Read more

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

Read more

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

I have sat through build or buy meetings that ran entirely on architecture diagrams. Latency graphs, runtime comparisons, a schema drawn on the whiteboard, everyone fluent and engaged for forty minutes. Not one of those rooms opened by asking what the thing would cost to own in year three.

That question belongs to finance, and finance is rarely invited until the budget request arrives. By then the decision has been made in a language the budget holder does not speak.

"The hours our team spent identifying the upstream change, building a working relationship with the vendor's technical team, and reconstructing the integration spec were not in the original statement of work." Kevin Nguyen, writing in Product Coalition

The Room Where It Gets Decided

Abby Allen has spent a career running the large rebuilds most people only read about. She opens her Product Coalition piece with the one that went wrong, and she does not soften it. "At Google, I pushed the AdSense team to completely rewrite our home-grown CRM system. It was a disastrous mistake."

A CRM rewrite at Google, pushed by the person best placed to judge the engineering, and it still went wrong. That is the shape of the problem. The failure was not the code. It was who was in the room and what they were allowed to count.

Maret Kruve explains why the engineering number carries so much weight and deserves so little. "Technical estimates are often made in isolation from organisational context." An estimate answers whether a team can build the thing and roughly how long the first version takes. It says nothing about who runs it at two in the morning in 2029.

Teams I advise treat that estimate as the decision. It is one input, and the cheapest one to produce.

There is a second reason these meetings stay technical. The people who will carry the consequence are often not in them. Kevin Nguyen draws the line precisely when he describes an integration built by an offshore team against a vendor's spec. "The client product manager has political access to every system in their stack. They can call a vendor, escalate to an account manager, demand a roadmap. The offshore team building the integration has technical access only."

Authority and exposure sit in different places. Whoever chose the vendor can pick up the phone, and whoever has to make the thing work cannot.

The Costs That Never Reach the Slide

Lee Fischman writes for the executives who fund internal builds, and he starts with the cost that never appears on any invoice. "Delaying (the delivery of features while you build them) destroys value." Every month your team spends recreating something purchasable is a month your users spend without it.

His rule for funding decisions is one question, and it has teeth because of three words at the end. "Is an off-the-shelf alternative available at any price?" At any price forces the comparison to happen before somebody decides the licence looks expensive.

Kruve names the accounting failure underneath all of it. "They focus on direct costs while ignoring indirect costs and opportunity costs." Direct costs are the ones with invoices attached. Everything else gets absorbed by people who are already on payroll, which makes it look free.

Nathan Mckinley puts a shape on what owning infrastructure requires. "Cloud operations require a range of technology professionals, from cloud developers to administrators and network engineers, each of whom will add to the payroll." A decision to build is a decision to hire, and the hiring happens quietly, one backfill at a time.

Mike Ranellone describes the part of the bill that never stops arriving. "The issue of dev opportunity cost doesn't end at launch, either." He is precise about the duration. "That post-launch tail can pull at least some engineering resources away from other important projects indefinitely."

Indefinitely is the word that should end the debate. A build is not a project with an end date. It is a standing claim on capacity, renewed every sprint, for as long as the system runs.

The Bill Arrives on Both Sides

Buying is not the safe answer, and any piece that tells you otherwise is selling something.

The most quoted evidence on build risk comes from McKinsey, working with the University of Oxford. Michael Bloch, Sven Blumberg and Jürgen Laartz reported that "on average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted."

Be careful with that number. It was published in 2012, and large there means an initial price tag above fifteen million dollars. Your two-sprint integration is not that project. What the study earns is the direction of the error, which is always the same way, and never in your favour.

The same authors describe a purchase that went wrong in the opposite direction. "Another bank scored well on unit price with a software-package provider for the project phase of a trading-system implementation but encountered high costs for changes and support after the system was introduced and the bank was locked into the new technology."

A good unit price bought them a bad position. Once switching costs exceed the annual licence, the vendor sets the terms and the renewal conversation is theatre.

Kevin Nguyen shows how that lands on a delivery team. An upstream vendor changed an interface without telling anyone, and the hours spent working out why belonged to no budget line. "The project shipped three weeks behind the original deadline."

Three weeks is the visible cost. The coordination hours underneath it were paid for out of a software build budget, because that was the only budget available.

None of this makes buying the default answer. Building wins on commercial grounds more often than the sceptics allow, and the test is whether the capability is one your competitors could licence tomorrow. Own the thing your customers choose you for. Rent the plumbing that gets them to it.

The mistake is the shape of the argument rather than the answer it reaches. I have watched a team win the right to build and still lose, because they won it on capability and never priced the ownership they had just signed up for.

What I'm Hearing on the Podcast

Matthew Wensing spent two decades as a founder before becoming VP of Product and Design at Customer.io, a company that has crossed a hundred million dollars in annual recurring revenue. He was talking about AI-written code rather than vendors, and he landed on the principle the whole build or buy argument turns on.

"No different than shipping code to production that AI generated. You're responsible for the bugs. You're responsible for the maintenance. You're responsible for the quality of that work."

Ownership does not care where the code came from. It can come from your team, a model, or a vendor you fired last year, and the bugs still belong to whoever's name is on the system.

That is the real trade. Buying rents you somebody else's maintenance burden and charges you for the privilege. Building gives you the burden for free, then invoices you every month in engineering time you cannot spend on anything else.

So What Does This Mean for You?

Before the next architecture debate starts, write two numbers on the board. What the vendor costs over three years, including the integration work. What building costs over the same three years, including the people who will run it once the launch party is over.

Then ask Fischman's question out loud, with the three words on the end. If an off-the-shelf alternative exists at any price, the burden of proof sits with the build, and it is a commercial burden rather than a technical one.

The teams that win this argument stop arguing about capability. Of course your engineers can build it. That was never the question, and treating it as the question is how a decision about money ends up being made by whoever drew the best diagram.

So take the last thing your team chose to build. What has it cost to keep alive since launch, and who is still paying for it?

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

👋 Jay

Product Coalition is a reader-supported publication. Paid subscribers get every issue on the day it lands.

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

The quickest way to start a fight in a product organisation is to put a date on a slide. I have drawn the same roadmap three ways in one week. Once for the team, once for the board, once for a customer who wanted a month.

The work never changed. The document did, and each version started a different argument. The board wanted certainty, the customer wanted a month, and the team wanted to be left alone until Thursday.

One artefact, three incompatible jobs.

I wrote about this in March and I got it wrong. That piece had the roadmap molting through three lives: the Gantt chart, then outcomes, then principles. Tidy, and the archive does not support it.

What the archive shows is that the earliest writers had already abandoned the thing the later ones claimed to kill.

"While true Product adherents know that a Roadmap isn't the ideal way to communicate the value of product development, in the real world it's one of the best communication tools we've got, and often the only one senior stakeholders are interested in." Emma Gordon, writing in Product Coalition

The Fixed Roadmap Was Already Unfashionable in 2016

Product Coalition is twelve years old, which means the archive can tell me what people believed at the time rather than what they remember believing. I went looking for the era of the dated delivery plan. It is not there.

Hannah Chaplin wrote about roadmaps in the publication in October 2016. "Never assume that your product roadmap is a fixed document. If you try to set things in stone, you can't react to new information that has become available." She was writing about a growing software business, treating the roadmap as a communication problem rather than a control mechanism.

That is the modern position, published before most of the frameworks that claim to have found it. Chaplin planned broad themes a quarter or two ahead and left the detail to the near term.

Swapna M published two months later on building a simple roadmap. "Note that timelines are not involved here and should not be. These priorities might change and various factors might affect the themes at the last minute." She allowed rough timing only where the risks were already understood, and avoided concrete deadlines in a startup on the grounds that the variables arrive without warning.

Two authors, three months apart, both refusing to commit to dates. Whatever the profession spent the following decade killing, it was not this.

What I take from that is less flattering than a story about progress. The good practice was written down early, read widely, and then ignored by the people who had to survive a quarterly business review. Chaplin and Swapna were describing what they wanted. The dated chart on the wall was what their stakeholders would accept.

The Fight Was About a Definition

By 2018 the backlash had a name and a great many conference slides. What it attacked was narrower than the slogans suggested.

Kyle Evans put it plainly in November 2018. "A roadmap is not a project plan. Far too often a roadmap gets confused for a project plan. A roadmap isn't meant to be the detailed execution of specific projects." He had just defined the roadmap as a strategic document for vision, value and alignment.

Read that as a defence. Evans wanted the artefact kept and the contract removed from it.

The harder problem arrived with Nacho Bassino in February 2020. "I do like the idea that things further away are more uncertain and under 'normal' circumstances that should be true. But developing products is erratic, and new insights or market conditions can drastically change your plans."

His answer was to label each item with its stage, so that problem discovery, solution discovery and delivery sit visibly on the page. Distance stops standing in for doubt. An item three months out can be well understood, and an item starting Monday can be a guess.

In twenty years no stakeholder has ever told me they read the far end of a roadmap as a guess. They read it as a quieter promise, and the disagreement surfaces two quarters later as a broken commitment.

Josh Ben-David went after the same problem from the other side three months on, borrowing from cartography. "Too many details can make communication difficult. But how much abstraction is necessary, and can there be too much? Too little information is also a problem." A map earns its usefulness by leaving things out. The skill is choosing which things, for which reader, and that judgement has never been handed over to a template.

Now the Question Is Which One, and Whether

The recent archive stopped arguing about the word. Ant Murphy laid out seven formats in March 2022 and let the reader pick. "By removing specific dates from your roadmap you can avoid many of the pitfalls in the timeline roadmap whilst still providing clarity on product direction."

Murphy is fair about why the timeline version refuses to die. People want to know when something will be finished, and a timeline looks like an answer to that.

John Utz went further in July 2023 and asked whether some companies need one at all. "When you are early on, your goal is to learn not to document. Your goal is to be nimble. To allow space to pivot." He is talking about concept, seed and Series A stage companies, and he replaces the roadmap with a North Star, OKRs and a release brief rather than with nothing.

Gavrilo Bozovic added the inverse in August 2024, which he calls the anti-roadmap. "Not having a ready answer to the question of what you will not be building means that, conceptually, you want to do everything."

That question has settled more roadmap disputes for me than any format debate. Ask a leadership team which competitor feature they are choosing to skip, then watch the room decide whether it has a strategy.

Ten years of argument produced something narrower than a revolution. The roadmap kept the job of alignment and lost its claim to be a schedule.

Notice what survives across all three eras. Every one of these writers wants the same four things from the document, which are direction, trade-offs, a shared picture and a conversation. The disagreements are about how much certainty to imply while doing it. That is a question about your stakeholders, and no amount of reformatting answers it for you.

What I'm Hearing on the Podcast

Dave West is the CEO and Product Owner of Scrum.org, and he has been researching what AI is doing to product organisations. I asked him whether it helps product people hold the strategic and the tactical at once.

"I'm seeing very, very, very sophisticated presentations coming out of product professionals now, but not necessarily better decisions being made by those product professionals."

Then he described where the week goes.

"Oh my God, we've got to plan the next release, the next roadmap. We've got to present it to the board or to the execs or to the stakeholders, et cetera."

A roadmap built to be presented drifts back towards dates every time, because dates are what the audience turned up for. No choice of format survives an artefact whose real purpose is a monthly performance.

Dave's warning is that AI has raised the volume rather than the quality. Better slides, produced faster, defending the same decisions.

So What Does This Mean for You?

Stop asking whether roadmaps are dead. Ask what yours is for, who reads it, and which promise they believe they are being handed.

Then split the two jobs it is quietly doing. Direction and trade-off belong on the roadmap. Delivery commitment belongs somewhere else, with a date, an owner and a change process attached to it.

The archive's lesson is unglamorous. Nothing killed the roadmap and nothing needed to. The fix keeps arriving in the same shape, which is to stop asking one document to promise dates, prescribe solutions and satisfy every audience at once.

So look at the roadmap on your wall this week. Which of those jobs is it failing at, and who would object if you took that job away from it?

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

👋 Jay

Product Coalition is a reader-supported publication. Paid subscribers get every issue on the day it lands.

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

I have been the gate far more often than I have been the one waiting behind it. Work sat in my queue while a team carried on without an answer, and I could not have told you what that cost. None of it ever appeared on a budget line. The money was real all the same.

"I do not think most of us have a meeting problem. I think we have a decision problem." Kaanti Shetty, writing in Product Coalition

The Queue Nobody Draws

Every product organisation runs a second backlog underneath the visible one. It holds decisions rather than features. It has no board, no owner and no refinement session, so it never gets estimated.

Jack Moore set out the mechanism in Product Coalition six years ago, writing about what being scrappy demands of a company. "Companies that are scrappy do what they can to reduce this cycle time, minimizing unnecessary hierarchical approval processes by creating self-organizing teams." The chain he describes is short. Layers add steps, steps add elapsed time, and elapsed time is what you are buying.

The part I would argue with is the word unnecessary. It suggests somebody put the gate there by mistake, and that removing it is an administrative job. Gates are rarely accidents.

Daniel Bentes wrote the harder version of this in the same publication in March. "Approval gates are not only about risk management. They are authority." That sentence explains why the tidy-up projects fail. Nobody surrenders a signature because a consultant drew a swimlane diagram showing it was redundant.

Bentes is worth reading on the wider point too, because he separates the work of defining intent from the work of moving work between people. "Specification means defining intent, success criteria, quality standards, and judgment boundaries." That first kind of work earns its time. Coordination is everything else, and coordination is where the weeks go.

So the honest question is not how to delete the gates. It is which gate, on which decision, is currently costing more than the risk it was built to catch.

Put a Rate on the Waiting

A delay only costs money when something of value is sitting behind it, waiting. That sounds obvious until you try to name the thing.

J.A. Becker made the case for measuring it in Product Coalition in 2020, writing about weighted shortest job first. He argues that "the cost of delay is critical in determining which feature will make or save the company the most money and which one will take the least amount of time to build." Cost of delay against job duration. It is a ratio, and ratios are harder to argue with than opinions.

Where teams lose the thread is treating cost of delay as a property of the organisation. It belongs to the decision. A pricing change held for six weeks has a rate attached to it. A refactor held for six weeks may have none.

Work it out from whatever is waiting. Contribution margin per week on revenue that cannot start. The penalty exposure per month on a compliance fix. The engineering capacity sitting idle at a known weekly cost. Multiply the rate by the weeks that elapsed, and the meeting invite now has a price beside it.

The arithmetic is deliberately crude, and crude is the point. Say a pricing change would add four thousand pounds of monthly contribution once it ships. That is roughly nine hundred pounds a week of value sitting still while the decision waits. Six weeks in committee cost five and a half thousand pounds, before anyone has argued about whether the change was right.

Nobody needs a model for that. They need the number written down somewhere the people holding the decision can see it.

Senior leaders do believe there is a number there. West Monroe surveyed 214 C-suite executives and 1,000 managers at US companies with at least $250 million in annual revenue, and reported that "across industries, 73% of leaders report losing 1-5% of annual revenue due to slow decisions and delayed execution."

Read that as what it is. Executives self-reporting a feeling in a commissioned survey, fielded in November 2025, at companies far larger than most of the ones I work with. It tells you the belief is widespread and expensive. It proves nothing about your own organisation, and I would not put it in a board pack as though it did.

Your own number is the only one worth defending, and it is available. Take the last significant decision that sat waiting, name what was behind it, and price one week of that wait.

The Bill Arrives From Both Directions

Speed is not free either, and any argument that ignores that is selling something.

Research covered by Harvard Business School's Working Knowledge puts a shape on the downside. Danielle Kost, writing on a study of 13 years of US Food and Drug Administration data in medical devices, reports that "a recall can delay a company's incremental innovations by six months." The failure consumes the same development capacity you were trying to protect. You end up buying the delay anyway, at a worse price and on someone else's schedule.

The same piece carries the other half of the trade. "However, if a medtech firm can bring a new product to the market even one month earlier following a rival's recall, it could bring in an additional $10 million in revenue." One month. Ten million dollars. In that setting, with those competitors, at that moment.

I want to be careful about what this evidence does and does not say. It does not show that a rushed decision caused any of those recalls. It shows that product failure is expensive in exactly the currency the slow organisation thought it was conserving, and that responding faster than a wounded competitor is worth real money.

Which points at the same test from the other side. Match the gate to what the mistake would cost, and to whether you could undo it.

What I'm Hearing on the Podcast

Jurgen Dauk has spent nearly thirty years inside enterprise technology, at Oracle, OpenText and Planview among others, carrying full profit and loss responsibility across regions. He has watched this problem from the seat where the signature actually lives.

His first test is the one I now use myself. He starts by asking whether a decision can be reversed, and reserves the heavier process for the decisions that cannot. Then he takes the part most organisations get backwards.

"So for me, it's not so much about the seniority really, and you can consult people, but the decision ideally has to be made by somebody who really understands the topic."

Seniority is a proxy for judgement, and it is a weak one on a specific technical call. The person closest to the work usually holds the information that matters, and often the least authority to act on it.

Jurgen is firm that this only works with the guardrails written down. Clear rules, documented, with people trained on who must be consulted before a decision is taken. Distributed authority without that scaffolding just moves the anxiety somewhere quieter.

So What Does This Mean for You?

Pick one decision currently waiting. Name what sits behind it, price a week of that wait, and put the figure in the calendar invite for the meeting where it will be decided.

Then check the gate against the mistake. If the decision can be undone cheaply, one informed person should make it today. If it cannot be undone, the process is earning its keep, and the delay is a premium you are choosing to pay rather than a failure.

An approval chain nobody has costed feels like diligence. Put a weekly figure beside it and the same chain becomes a trade, and trades get argued about properly rather than defended on instinct.

So take the decision your team has been circling for the longest. What is it costing you a week, and who needs to be in the room?

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

👋 Jay

Product Coalition is a reader-supported publication. Paid subscribers get every issue on the day it lands.

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

I have sat through more north star metric workshops than I can now count, and most of them end on the same slide. One number, one arrow, a promise that if it climbs the business is safe. Product Coalition's own archive tells a slower, more honest story than that slide ever did.

I traced this metric once before, in April, and called its story a fall from gospel to cautionary tale. That reading was too generous. The number was never measuring the business, and the archive shows that from the start.

"Not everything that matters can be measured. Not everything that we can measure matters." Sebastian Straube, writing in Product Coalition

The Problem Came First

Product Coalition's early writing barely used the phrase north star. It talked about problems, and about the KPIs that should follow once a team understood one properly.

LX Cast set out the order plainly. "When you know the problem, you can set clear KPIs or key results that reflect the success of the customer." Diagnosis first, then the number that proves the diagnosis was right. Reverse that order and the metric stops meaning anything.

Every team I built with in that period ran the same test before a single tracking tool got installed. Could you name the customer's problem in one plain sentence? If nobody in the room could answer, the KPI conversation did not start, because there was nothing yet for a number to measure against.

I had made a version of the same argument two years before that, in a piece for the same publication. "A fundamental mistake is to think that a business can be propped up on single innovative product." A single product artefact was never the whole business, and a single metric was always going to inherit that same limit.

That was the mid-2010s. Nobody was arguing about one metric versus many yet, because the field had not agreed to compress the problem down to one number in the first place.

One Action, One Arrow

By 2020 the compression had happened, and it had a name. Carlos Gonzalez de Villaumbrosia gave it the clean test that every workshop still runs today: "to work out your north star metric, think about the one thing that a user can do with your product to help fix their problem."

Every product leader I have watched hear that test for the first time reaches for it instantly, because it ends an argument that has been running for months. Teams debating nine candidate metrics rarely ship anything, since everyone in the room can defend their own favourite. A single north star settles the debate through sheer design, no evidence required.

That design choice solved a real, expensive problem. Roadmap reviews stopped circling the same disagreement every quarter once one number was allowed to speak for the whole team. Prioritisation got faster, and product health became something you could read off a chart in a single glance.

A number chosen to end an argument is a different thing from a number proven to track the business. Nobody in 2020 pushed back on that distinction, because the metric still felt new enough to seem self-justifying. Growth teams adopted it fast precisely because it asked so little of them in return.

That single number then quietly took on a second job it was never built for. It stopped being a tie breaker for prioritisation and started standing in for the health of the whole product. Those are different jobs, and mixing them together is exactly where the 2022 correction had to begin.

Behaviour Is Not a Business Goal

Two years into the decade the correction arrived, and it came from inside the same publication that had championed the idea. Elena Seregina named the flaw directly. "Some approaches suggest building the hierarchy of metrics from the most important one, also known as NSM. But it is not easy to define a proper NSM." Her next point is the one that matters most. A north star is a product metric, so it tracks what a customer does rather than what the business needs.

No team I have advised in the last five years has answered, without a long pause, whether their north star tracked revenue, retention or margin at all. It usually tracked none of the three directly. It tracked an action a customer took, and everyone assumed the business result would follow along behind it.

Seregina's guardrail belongs on every dashboard next to the north star, never underneath it. "Top-level metrics should not drop, even if the lower-level ones keep skyrocketing." A product metric only earns its keep while the business result above it holds steady. The moment that top line slips, the rising number underneath it stops being good news.

This is the whole correction, stated as plainly as the original claim ever was. The customer problem remained the real test of a useful measure the entire time. What changed was the confidence that a rising user action, sitting on its own, proves anything about the business built around it. A product team can be right about the behaviour and still be wrong about the business.

None of this makes the north star metric a bad idea. It makes it a partial one, useful exactly as far as the customer problem it was built to track, and no further than that.

What I'm Hearing on the Podcast

Weiwei Hu describes spending a large part of her career sitting between data, product and executive decisions. She walked me through watching this exact gap open up inside a live A/B test.

"Clicks will actually increase, but our retention didn't improve."

She finishes the thought a beat later, once the team has checked what happened downstream. "It may be we're just increasing the shallow engagement rather than a meaningful activation for our users and customers."

The rising number in her example was click-through rate rather than a formal north star. The failure sitting underneath it is identical regardless of which metric wears the name. A product number climbed, the team wanted to celebrate, and the business result above it, retention, stayed exactly where it started.

Her point was never that the test had lied. Watched alone, almost any single number will find a way to look like progress, which is precisely why it cannot be watched alone.

So What Does This Mean for You?

Keep your north star metric. Write the one sentence above it that names the specific business outcome it is meant to serve. Check the two against each other every month, not only when the product number happens to look good.

Avi Siegel put the deeper warning in a single sentence that has stayed with me since I first read it. "The problem is, raw data doesn't exactly exude 'information'."

A number moving in the right direction is a fact on its own. Whether it means what you hope has to be argued for separately, every single time you look at it. A number never argues its own case.

So take the one metric your team currently treats as settled. Which top-line business result has moved because of it, and when did you last check?

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

👋 Jay

Product Coalition is a reader-supported publication. Paid subscribers get every issue on the day it lands.

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

Every product I have ever managed has bled customers. The product was usually fine. The team was looking in the wrong direction.

The dashboards showed acquisition. The team celebrated sign-up spikes and ran victory laps on numbers that mean very little if nobody stays past day three. That pattern has repeated for twenty years, across companies, continents and product categories.

The leak is always between sign-up and the first real use.

"Acquisition is when you get a user on board. Activation is when you get them to use your product in a meaningful way." Ant Murphy, writing in Product Coalition

Sign-ups Are Not Wins

Ant Murphy draws the line I have drawn in a hundred boardrooms, and most teams I advise collapse the two sides of it into one number. A sign-up gets counted as a win, when all it records is a maybe.

Ant asks something I have put to product teams for years: "just think how many things have you signed up for and never used?" For most honest people the answer runs into dozens.

He describes a FinTech client tracking daily active users as their north star. His challenge lands hard. "how often do you look at your bank account? Do you check your app every day? I don't."

That mistake turns up everywhere once you know its shape. Teams measure success against a behaviour their customers never perform, then wonder why the retention curve flattens. It is a comfortable delusion, and comfortable delusions survive a long time.

Then comes the fix, and in twenty years no team has proposed it to me unprompted. "Don't just track acquisition, activation and retention. Track the nuanced states between each of them."

The user who signed up and never finished onboarding. The user who activated once and vanished. The user who stayed active a fortnight and then went quiet.

Each transition is a different problem with a different fix. Lumping them together under churn is lazy, and it buries the one thing you could have acted on.

So instrument them separately. Signed up and never activated. Activated once and never returned. Returned for a fortnight and then stopped. Then the quiet decline that shows up as falling frequency rather than a cancellation.

Those are four different conversations, and they rarely belong to the same owner.

The Ratio That Decides Everything

Nick Chasinov states the arithmetic without decoration: "the money, time, staffing, and other resources used to acquire a new customer must be lower than that customer's lifetime value for the business to be successful. If your CAC is higher than your LTV, it's only a matter of time before the business closes its doors."

I have sat in leadership meetings where CAC was treated as something finance worried about. It belongs on the product team's wall.

Nick cites the benchmark most of us carry around: "It's best to aim for a 3-to-1 ratio. For instance, if it costs a company $1,000 to acquire a customer, it would want its lifetime value to be at least $3,000."

Treat that as a rough heuristic rather than a law. Andreessen Horowitz describes 3x as a benchmark investors reach for, and it shifts with margin, payback period, and how you calculate lifetime value in the first place.

What the ratio buys you is margin for error. Sitting near one-to-one means a single bad quarter puts you underwater, or one spike in support costs does it instead.

A word of caution here, because this genre is stuffed with numbers that fall apart when you check them. The line you have seen everywhere, that a five percent lift in retention grows revenue by 25 to 95 percent, is a misquote. Reichheld and Sasser said profits, and they said it in the Harvard Business Review in 1990.

The direction of travel still holds. Treat it as a direction rather than a forecast for your business in 2026, and stop repeating the version with revenue in it.

Making Retention Legible to Finance

Scott Middleton takes on the part that quietly kills most retention work. He admits that "Calculating the return on investment (ROI) of improvements to retention can seem like a daunting or complex task."

It can, and that complexity is exactly why retention loses budget fights to flashier acquisition campaigns.

Scott's answer is to keep the formula boring. "Without a clear and uncomplicated formula, your calculation would get caught up in sensitivity analysis and endless debates about the inputs."

His method runs in two steps. Monthly churn cost is your churn rate multiplied by your customer count, multiplied by CLV. Annual cost is that monthly figure multiplied by twelve.

Put real numbers against it. Ten thousand customers, three percent monthly churn and a CLV of £900 means you lose 300 customers a month. That is £270,000 of value leaving every month, and £3.24m across the year.

Now take a piece of retention work that moves churn from three percent to two and a half. Half a point sounds like nothing in a roadmap review. It is £540,000 a year, which is a senior hire and most of a squad.

I use that framing whenever I build the case for retention work. Translate a retention improvement into money kept and the conversation changes shape. A five percent reduction in churn stops being a nice-to-have and starts appearing on the P&L.

Product leaders who cannot make that translation lose the prioritisation argument to the growth team every time.

History has receipts. Fab reached a billion dollar valuation and raised somewhere between $310m and $336m across multiple rounds before its 2015 fire sale. Homejoy raised around $40m in total and closed on 31 July 2015, roughly nineteen months after that funding was announced.

Both grew quickly. Neither built a product people came back to. Growth without retention is a bonfire, impressive to look at and gone by morning.

What I'm Hearing on the Podcast

Andrea Bronzini spent eight years inside experimentation at CXL and Speero, then walked away because he had decided the industry was optimising for the wrong thing. He showed me a simulation of one experiment run over and over.

"The real conversion rate is 3%, but what you measure at day 28 is 3.5." Run it again and a different path appears, then another, until you are looking at a wide cloud of possible answers.

Then he named the mistake. "One mistake I see teams making is that they look at the conversion rate they have measured, and they take that for granted. But the uncertainty is more important than the point conversion rate."

That line has stayed with me since we recorded it. The number on your dashboard is a sample that happens to be today's, and CLTV is harder to fool because it needs time to accumulate. Somebody has to keep paying, month after month, before it moves at all.

CLTV has its own failure modes, and a generous enough time horizon flatters almost any cohort. It is still the last number I would give up.

So What Does This Mean for You?

Two decades in product have taught me that CLTV is the most honest metric available. It ignores your press coverage, your sign-up chart, and how elegant the onboarding looks in a demo. It measures whether the thing you built matters enough for someone to keep paying for it.

The practical move this week is small. Pull your retention curve, find the point where users stop coming back, and price that drop-off using Scott's two-step calculation. You will have a number finance recognises, which is what turns a retention argument into a funded one.

Then the harder question, and it is the one I want to put to you. Which of the metrics your team reported last month would survive being checked as carefully as your CLTV?

Reply and tell me. I read every one.

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

👋 Jay

Product Coalition is a reader-supported publication. Paid subscribers get every issue on the day it lands.

In this episode, Jay Stansell interviews Jürgen Dauk about the common pitfalls that slow down product teams as organizations grow, and practical strategies to accelerate decision-making without losing clarity. They explore cultural differences, organizational structures, and mindset shifts necessary for faster, more effective product development.

Key topics

• Decision bottlenecks in product organizations

• Organizational culture and its impact on speed

• Practical strategies for redesigning decision-making

• Cultural differences between Europe and the US

• The role of trust and empowerment in decision speed

Chapters

• 00:00 Introduction to the episode and guest

• 02:14 Main themes: decision bottlenecks, friction, and speed

• 07:42 Jürgen’s personal journey and passion for organizational speed

• 08:44 Understanding organizational change and cultural mindset

• 12:49 The importance of trust and decision autonomy

• 13:55 Root causes of organizational slowdown: command and control

• 15:12 The impact of market change and outdated systems

• 16:23 Shifting mindset: from hierarchy to cross-functional teams

• 18:23 Overcoming theater and superficial alignment

• 20:00 Strategies for socializing decision-making changes

• 22:17 Cultural differences in decision-making and communication

• 26:53 Assessing the stakes and reversibility of decisions

• 28:59 Guidelines and rules for distributed decision-making

• 31:25 Implementing decision guardrails in large organizations

• 34:22 Building psychological safety and trust at the grassroots level

• 36:12 Small steps for grassroots change and peer alignment

• 37:27 Measuring decision speed and effectiveness

• 39:11 Employee experience and empowerment metrics

• 41:06 Socializing change through informal conversations

• 42:42 Opportunities in the current technological landscape

• 44:30 Advice for newcomers and early career professionals

• 46:51 The future of work and embracing change

In this episode, Matt Wensing, VP of Products and Design at Customer.io, shares insights from his two-decade journey from founder to product leader. We explore decision-making, maintaining product standards, integrating AI, and scaling organizational taste.

Key topics

• Transition from founder to organizational leader

• Decision-making and product velocity

• Maintaining product standards and taste

• Integrating AI into product teams

• Scaling organizational culture and mentorship

Chapters

• 00:00 Introduction to Matt Wensing and his journey

• 00:10 Matt’s background and transition from founder to VP

• 01:23 Unlearning founder instincts and decision-making

• 04:23 Lessons on burnout and resilience

• 06:44 Product velocity governed by decision-making

• 10:35 Joining Customer.io at scale

• 14:11 Suppressing founder habits in a remote organization

• 17:53 Prioritization and understanding organizational funnels

• 24:40 Calibrating product standards and taste

• 29:41 Managing decision-making across a large organization

• 33:58 The importance of intangible leadership and mentorship

• 35:42 Implementing AI to scale product teams

• 39:33 Using AI responsibly in product management

• 42:30 The importance of quality checks and modeling

• 46:15 Final thoughts on distribution and startup success

In this episode, Jay Stansell interviews Dave West from Scrum.org about the evolving role of AI in product management. They explore how AI acts as a teammate, its limitations, and its impact

Key topics

• AI as a teammate in product management

• Limitations of AI in understanding context and judgment

• Impact of AI on team organization and decision-making

• The evolution of Scrum in an AI-driven world

• Practical use cases of AI in product management

Chapters

• 00:00 Introduction to AI in Product Management

• 01:48 The Evolution of AI and Its Impact

• 07:33 AI’s Role in Balancing Strategy and Tactics

• 14:51 The Limitations of AI in Empathy and Context

• 20:06 Practical Use Cases of AI in Product Management

• 28:13 The Future of AI in Product Ownership

In this episode, Jay Stansell interviews Saurabh Sharma, Chief Product Officer of You.com with extensive experience at Google, exploring how enterprise AI products are transforming product management, user engagement, and agent management. Discover insights on building primitives, managing evolving roadmaps, and the future of AI-driven workflows.

Key topics

• Impact of user-built workflows on product teams

• Building and managing primitives in AI platforms

• Measuring success with primitives vs features

• Evolving product roadmaps based on user signals

• Agent management and enterprise AI adoption

Chapters

• 00:00 Introduction to Product Coalition Podcast

• 00:10 Meet Saurabh Sharma: A Journey Through Product Management

• 02:39 Understanding You.com: AI Web Search Infrastructure

• 05:02 Shifting from Consumer to Infrastructure Product Management

• 08:20 Defining Primitives in Product Management

• 11:23 Recognizing When Features Outgrow Their Relevance

• 12:47 The Importance of Using Your Own Product

• 15:45 Agent Management in the Age of AI

• 19:14 Research Discipline in Product Management

• 21:03 Evolving Product Management Skills in the AI Era

• 23:25 User Experience in API Products

• 25:33 Challenges in Moving from Prototype to Production

• 27:31 A Memorable Product Management War Story

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

Subscribe to Product Coalition — Join thousands of product professionals getting smarter about product strategy every week. Subscribe here

I worked in construction with my dad from the time I was a teenager right through to 21. Before a single wall went up, we would spend hours checking pipework, reading blueprints, tracing electrical cabling in the ground and in the ceiling. I remember thinking it was tedious. My dad would say: "The cost of fixing it later is always ten times the cost of getting it right now."

He was talking about buildings. But he could have been talking about product.

These are the writers who keep Product Coalition sharp. Practitioners running real products, sharing the compliance lessons most teams learn the expensive way. Every article in this issue comes from someone who has felt the weight of a regulatory surprise or a hidden cost that never made it onto the roadmap.

In product development, we tend to move fast and break things until the legal department walks into the room. Then the mood shifts. I have started paying closer attention to how often the real cost of a feature has nothing to do with engineering hours, and everything to do with the fine print nobody read until it was too late. My dad's rule from the building site still applies: the cost of fixing it later is always worse.

The Regulatory Hammer Is Already Swinging

I read Baker Nanduru's piece, The EU AI Legislation Sets the Bar for Safety and Compliance, and it hit me like a cold shower. Baker writes that "any EU citizen can file a complaint against an AI System provider" and that "AI creators will be fined a max of 7% of the worldwide total company turnover or $43 million, whichever is higher, for severe compliance breaches." That number is staggering.

I keep thinking about how many founders build features with total disregard for these borders. Baker points out that "most foundational model providers like OpenAI, Stability.ai, Google, and Meta failed to comply with the new EU AI Act." The top two reasons? Copyright issues with training data and lack of risk disclosure. It makes me wonder if we have reached a point where compliance is no longer a checkbox exercise but a primary product feature. As Baker puts it, "those who neglected safety by default despite having global ambitions must adapt quickly, despite the associated costs and time investments." The bill always comes due.

What I Am Hearing on the Podcast

I had Julie Harris on the podcast to talk about designing AI products for high-stakes problems. She said something that stuck with me:

"If you think about auditability, whether it's in financial services where there's regulation and there's supervisors and there's auditors, or whether it's in something like defence where, if something goes wrong, there could be public inquiries, you need to be able to go back to the moment in time that you made a decision and say why you made that decision."

That is the compliance cost nobody budgets for. Not the fine. The audit trail. The infrastructure to prove, retroactively, that every decision had a reason.

And then Rowland Graus put it differently when we talked about blockchain product management:

"It's not that, oh, I want to do this thing that's illegal. It's, I want to do this thing. I think it should be legal. I don't know that it's legal. And nobody else does either. The lawyers don't know. Politicians don't know. You get different guidance from different federal agencies. And so it's like this gray area that is just very draining and difficult."

That gray area is where most product teams actually live. The cost is not just financial. It is cognitive. It is strategic. Every decision gets slower because nobody can tell you whether you are on the right side of the line.

The Cost You Never Budgeted For

This brings me to the way we track what we build. Martin Michalik wrote Know The Development Costs: Why Product Managers Need to Go Beyond Sprint Estimates and Story Points, and he hits a nerve: "Accounting and tracking development costs aren't usually the virtues they're known for. After all, what are all the costs compared to the satisfaction of their users?"

I find myself nodding because I have been that product person who just wants to ship the cool thing. Martin is right that "PMs are often unaware of total projected costs, or, for the worse, they ignore them. ROI discussions never take place, and the product direction and strategy are never challenged."

He shares a quote from Ryan Singer that reframes everything: "An appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design." I want to apply this to compliance. If you have an appetite for a new feature, you must have an appetite for the legal and regulatory guardrails required to keep that feature alive. If you do not include those costs in your initial design, you are setting your team up for a future of firefighting.

Martin asks, "Do you know how much it cost to build your last feature? Would you build it again if you knew the total cost in advance?" Heavy question.

When the Model Gets It Wrong

Sriram Parthasarathy explains in Analyzing and Communicating Business Risks When Deploying a Predictive Model that accuracy is not the only metric that matters. He writes, "Say we do 80% accuracy. This means model got 20% wrong. What is the cost or the impact of the incorrect predictions on the business? Is this manageable or is it severe?" I think about how often we celebrate a 90% accuracy rate while ignoring the catastrophic cost of the 10% failure.

Sriram uses healthcare as his example, where the cost of a mistake involves more than money: "The cost for incorrectly tagging a patient as compliant even though they are non-compliant is very high. This has a significant business risk because you are providing sensitive data to the customer who is not compliant." The financial impact is not limited to the product itself.

Nathan McKinley adds in Total Cost of Ownership (TCO): What Organizations Need To Know that we have to broaden our scope. "Understanding the price offered by cloud providers or the cost of managing workloads is insufficient to estimate the actual cloud cost." And buried in that total cost? "Any violation of regulations can lead to legal costs."

It is a full cycle. You build a model to save money. You fail to account for the compliance cost of that model. The model makes a mistake, or it runs afoul of a regulator, and your total cost of ownership triples overnight.

Rachel Wolan told me on the podcast how Webflow handles this:

"We do not train on our customer data. That, full stop. We have security, privacy, legal teams that review all of our products at the point when you have a spec. We have built out custom GPTs for product managers to run their products through for each of those just so you can get early flags."

That is what operationalised compliance looks like. Not a review gate at the end. A system that flags issues before you have committed resources.

Move Compliance to the Starting Line

I wonder if we are entering an era where the most valuable product managers are not the ones who can ship the fastest, but the ones who can map out the entire financial and legal risk profile of a feature before the first line of code is written. It is not as exciting as a launch party. It does not look great on a résumé to say you stopped a feature from being built because the compliance costs outweighed the potential revenue.

But I suspect that is the only way to build a sustainable business in the current environment. We have spent a decade treating compliance as a hurdle to be cleared at the end of the race. It is time to move it to the starting line.

If you knew that a feature would require an extra twenty percent of your budget just to satisfy new regulations, would you still push it to production today?

Baker Nanduru opened the EU AI Act's fine print so you did not have to. Martin Michalik challenged every PM who has ever skipped the cost conversation. Sriram Parthasarathy showed what happens when a model's 20% failure rate meets a real patient. Nathan McKinley forced us to add the legal line to the cloud budget. And on the podcast, Julie Harris, Rowland Graus, and Rachel Wolan brought the compliance conversation out of the legal department and onto the product roadmap. This is what 12 years of practitioner publishing looks like.

Sources:

• Baker Nanduru, "The EU AI Legislation Sets the Bar for Safety and Compliance," Product Coalition

• Martin Michalik, "Know The Development Costs: Why Product Managers Need to Go Beyond Sprint Estimates and Story Points," Product Coalition

• Sriram Parthasarathy, "Analyzing and Communicating Business Risks When Deploying a Predictive Model," Product Coalition

• Nathan McKinley, "Total Cost of Ownership (TCO): What Organizations Need To Know," Product Coalition

• Julie Harris, EP77: Designing AI Products for High Stakes Problems, Product Coalition Podcast

• Rowland Graus, EP67: Breaking Blockchain Barriers, Product Coalition Podcast

• Rachel Wolan, EP96: Designing for AI Disruption, Product Coalition Podcast

👋 Jay

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

Tools Mentioned

Noise Explorer
Explore the effect of stochastic noise on your experiments and fine-tune your decision policy. https://confidentstory.com/noise/

Noise Check
Evaluate the results of split tests or compare KPIs to rule out noise wobbling. https://confidentstory.com/noisecheck/

GTMsplit
Run split tests in Google Tag Manager (100% free). https://confidentstory.com/gtmsplit/

Key topics

• Limitations of traditional A/B testing frameworks

• Impact of stochastic noise on experiment outcomes

• The importance of uncertainty in decision-making

• Tools for simulating experiment outcomes and understanding noise

• Reevaluating the use of statistical significance in experiments

• Decision policies and experiment duration considerations

• The role of noise in KPIs and long-term metrics

Chapters

• 00:00 Introduction to Andrea Bronzini and the episode’s focus

• 01:13 The industry’s stagnation in experimentation practices

• 03:15 Fundamentals of healthy experimentation and decision policies

• 08:44 Understanding stochastic noise and its visual representation

• 12:53 The importance of uncertainty over point estimates

• 19:34 Simulating experiment outcomes to inform decision-making

• 23:43 The impact of noise on KPIs and long-term metrics

• 27:21 Reevaluating decision thresholds and significance levels

• 32:33 Practical steps for product teams to improve decision quality

• 36:27 Tools for noise detection and better experiment analysis

• 38:12 Closing remarks and where to learn more about Andrea’s tools

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

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

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

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

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

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

The Data Layer: Measuring Everything, Understanding Nothing

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

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

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

The Information Layer: Context Without Consequence

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

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

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

The Knowledge Layer: Where Experience Meets the Numbers

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

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

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

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

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

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

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

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

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

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

Climbing the Pyramid

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

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

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

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

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

Sources

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

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

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

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

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

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

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

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

👋 Jay

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

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

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

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

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

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

The Five Hidden Costs Nobody Budgets For

1. The Customer Acquisition Reset

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

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

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

2. The Team Morale Drain

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

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

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

3. The Trust Erosion With Existing Customers

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

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

4. The Opportunity Cost Nobody Calculates

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

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

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

5. The Technical Debt Reset

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

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

What I Am Hearing on the Podcast

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

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

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

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

The Pivot Decision Framework

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

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

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

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

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

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

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

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

Sources

Startup Failure Rate Statistics — flair

Startup Genome Project — Startup Genome

The Hidden Cost of the Pivot — CFO Pro Analytics

State of Product 2026 — Atlassian

To Pivot or to Not — Mind the Product

All About Pivoting — Y Combinator

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

👋 Jay

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

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

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

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

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

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

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

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

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

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

Era 2: The Great Specialisation (2000–2015)

Then SaaS changed everything.

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

Enter the Product Marketing Manager.

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

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

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

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

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

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

By 2023, the backlash had arrived in full force.

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

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

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

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

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

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

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

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

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

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

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

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

So where does that leave us?

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

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

What I Am Hearing on the Podcast

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

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

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

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

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

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

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

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

👋 Jay

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What I Am Hearing on the Podcast

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

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

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

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

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

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

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

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

👋 Jay

Sources:

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

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

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

• Noa Ganot, Product Strategy in the AI Era

• John Utz, The Power of Product Lifecycle Management

• EP83, Dan Balcauski

• EP93, Nicole Segerer

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

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

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

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

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

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

The Freemium Trap and the Upgrade Nudge

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

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

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

Beyond the Subscription Box

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

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

The API Economy's Quiet Revolution

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

The Price Experiment Nobody Wants to Run

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

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

When Customers Don't Actually Want Cheaper

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

Marketplace Models: Aligning Incentives

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

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

What I Am Hearing on the Podcast

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

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

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

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

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

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

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

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

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

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

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

Sources

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

👋 Jay

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Era 3: Continuous Discovery (2015-2022)

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

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

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

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

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

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

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

Era 4: The Dashboard Trap (2020-Present)

Here is where things get uncomfortable.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What I Am Hearing on the Podcast

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

👋 Jay

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

Sources

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