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

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

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

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

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

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

Fair point.

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

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

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

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

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

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

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

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

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

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

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

The 95% problem is a money problem

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

She did not know. Not roughly. Not ballpark.

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

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

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

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

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

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

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

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

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

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

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

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

There was a quarter where a product team I was advising felt good about their retention numbers. Churn was down. The trend line was moving in the right direction. Morale was high.

Then someone ran the revenue churn numbers.

Turns out they’d kept almost everyone, but lost a disproportionate share of the customers who mattered most. The ones on higher tiers. The ones who upgraded. The ones who stayed a long time. Those were the ones quietly walking out.

Customer count said one thing. Revenue said another. They’d been celebrating the wrong number for six months.

Most conversations about churn start and end with rate. What is it? Is it going up or down? How does it compare to benchmarks?

But Carlos Gonzalez de Villaumbrosia, writing for Product Coalition, points to a distinction that doesn’t get nearly enough airtime: customer churn and revenue churn tell completely different stories. He puts it like this:

‘it’s better to lose six $5 customers than it is to lose one $100 customer. (Not that this is the rule for all businesses — it depends on the model!)’

The parenthetical matters more than the main point. It depends on the model. And the bit I keep turning over is whether most PMs have properly interrogated which situation they’re in.

The other thing that rarely comes up: good churn.

Carlos gives the example of a dating app. Someone leaves because they found love. That registers as churn in your dashboard. It isn’t. It’s the product working exactly as intended.

I wonder how many teams are running retention initiatives they shouldn’t be running. There’s a version of this where you add friction to cancellation, drip in discount emails, make leaving feel awkward — and you keep the customer long after your product stopped being the right fit for them.

Lee Fischman wrote a piece on achieving 90% retention in B2B and the line that stuck with me was almost a provocation: ‘the first reason our retention was so high was simply because customers needed our stuff. When they didn’t, they cancelled.’

The goal isn’t to eliminate churn. It’s to make sure the customers who should stay, do. That’s a different problem.

What that requires is harder than any retention playbook.

Asher Atlas wrote the best case study I’ve read on what happens when retention breaks not because of product quality, but because of trust. A licensing shift meant a huge chunk of their music catalog disappeared overnight. Users weren’t annoyed. They felt cheated.

The team’s instinct was to fix search. The insight they landed on: ‘What if this isn’t a search problem? What if this is a discovery problem?’

That reframe is doing a lot of work. The churn signal pointed at one thing. The root cause was something else. A team that only read their retention dashboard would have shipped the wrong fix.

There’s no clean framework here. The thing I keep coming back to is that churn is a symptom, not a diagnosis. And teams that treat it as a metric to optimise — rather than a signal to interrogate — tend to optimise it in the wrong direction.

The question worth asking isn’t just: why are people leaving? It’s: which people are leaving, what were they worth, and should anything have been done differently?

Some of those answers are uncomfortable. Some of them are ‘no.’

- Jay

I counted once. In a single quarter, a team I was advising ran fourteen experiments on their onboarding flow. Fourteen. Button copy, tooltip placement, that little progress bar at the top.

You know how many experiments they ran on the pricing page in the same quarter? Zero. And this was a team that prided itself on being data-driven about everything.

I keep noticing this pattern and I am not sure I fully understand it yet. The pricing page is somehow sacred ground. Nobody runs real experiments on it.

Ivo Valchev wrote a case study on Product Coalition about what makes a pricing page work, and the opening line killed me: ‘”Oh wow! What a great pricing page.” Said nobody ever.’ I laughed and then felt a bit sick because it is so true. Ivo dug into the data and found visitors give you maybe 3 seconds before bouncing. Most pricing pages? Thrown together by someone in finance who built a comparison table and never came back to it.

What really gets me is how casually the actual numbers get chosen. Olha Mykhoparkina wrote about this and her phrasing stuck with me: companies just starting out ‘take their price figures out of thin air.’ Your whole revenue model, sitting on a number someone guessed over lunch.

I have a theory about why this keeps happening. Pricing feels risky in a way that button colors do not. Change the price and someone in sales will complain. A customer might leave. Your boss might ask uncomfortable questions about why you are tinkering with something that was working fine.

So PMs treat the pricing page like it is load-bearing. Structural. Do not touch it.

Except it is not structural. It is just a page nobody owns. Krishnan Hariharan spotted this gap back in 2018: ‘No one really thinks about the poor product manager who has to put together a pricing structure and is held accountable for its success.’ That was eight years ago and I genuinely wonder, has anything changed?

Something is starting to shift though. Eric De Castro published a piece recently that rewired how I think about pricing pages entirely. His argument: if your pricing page looks like a ‘hardware store receipt, charging by the seat, by the gigabyte, or by the API call,’ you have already lost the game.

In an AI world, features get cloned fast. A scrappy competitor can replicate your core product over a weekend, Eric says. So the real question is not what you charge per seat. It is what experience justifies your price. He calls it the Michelin-star model and honestly I have not been able to stop thinking about it since I read it.

Dan Balcauski made a related point on my podcast. He called pricing a ‘neglected business function.’ I think Dan is right. It is probably the most powerful commercial lever PMs have. And most of them have never actually pulled it.

I want to ask you something specific because it has been bugging me. When was the last time your team ran a real experiment on your pricing page? I mean a proper one, with a hypothesis and a control group and someone tracking whether it worked. Not a redesign meeting. A real experiment.

If the honest answer is ‘never,’ I am not judging. Most teams have not. I just think it is wild that we will test fourteen variations of a progress bar but not the single number that determines whether the business makes money.

Hit reply and tell me what happened the last time someone at your company suggested changing the price. I bet there is a story there.

Sources: Ivo Valchev - “How to Build a Killer Pricing Page” (Apr 2020), Olha Mykhoparkina - “Value Based Pricing for SaaS Startup” (Dec 2018), Krishnan Hariharan - “Pricing and Packaging Your Software” (Jun 2018), Eric De Castro - “The Economics of the Vibe” (Feb 2026), Dan Balcauski - Product Coalition Podcast EP83. All published on Product Coalition.

I want to tell you about a feature that nearly died.

Low engagement. Barely any daily active users touching it. By every dashboard metric a PM would check, it was dead weight. The kind of thing you flag in a quarterly review and say ‘let’s sunset this.’

Maret Kruve wrote about this on Product Coalition. The feature had poor usage numbers. Considering engagement alone, it should have been killed.

But here is what the dashboard did not show: that same feature made potential customers go ‘wow’ during sales demo calls. It was contributing to closed deals more than any other feature on the platform.

Read that again. The feature with the worst engagement metric was the strongest revenue driver.

This is the gap I keep coming back to. We measure what is easy to measure. DAUs, MAUs, feature adoption rates, NPS. These are product metrics. They tell you whether something gets used.

They do not tell you whether something makes money.

Tanay Agrawal learned this the hard way growing a product from zero to 100 customers. His team kept adding features and bundling them into pricing tiers. The plans got so complicated that customers stopped buying. Every feature had a carrying cost in maintenance and support, and nobody had visibility into which features actually drove revenue.

Tanay’s conclusion was blunt: everyone in the team should be able to look at and dissect subscription data at will. Not just the finance team. Not just the CEO. Everyone.

How many product teams can actually do that today?

Sebastian Mueller catalogued the damage when this goes wrong. The worst pricing mistake is not charging too much. It is underpricing so significantly that your unit margins are negative. You lose money by selling and scaling. Every new customer costs you.

Think about what that means. Your growth metric goes up. Your revenue goes up. And you are going broke.

This is why I think the most dangerous phrase in product is ‘users love it.’ Users loving something and that something being profitable are two completely different conversations. And most PMs only know how to have one of them.

Jon Matheson wrote a follow-up piece that landed on the same point from a different angle. His argument: stop asking ‘do users like this?’ Start asking ‘does this pay for itself?’

Not eventually. Not once you hit scale. Right now, at current volume, with current margins.

If you cannot answer that question about the last feature you shipped, you are not alone. But it is worth sitting with the discomfort for a minute.

I have a question for you. Have you ever killed a feature based on usage data, then discovered it was quietly driving revenue somewhere you were not looking? Or kept a feature alive that looked great on dashboards but was actually bleeding money?

Hit reply. I want to hear what happened.

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

A product manager I know got let go after three years. Good with engineering. Great with UX. Solid on agile.

The feedback? ‘We need our product managers to have a commercial side to what they bring to the table.’

That quote is from Jon Matheson’s piece on Product Coalition, and it landed hard when I first read it. Jon was doing everything right by the traditional PM playbook. Launches, team management, user research. But his boss told him straight: ‘We need a product manager who understands monetization and how product decisions impact revenue, COGS, and expenses.’

He lost his job because nobody taught him the money side.

Here is the uncomfortable part. Most PM training skips this entirely. We get certified in discovery, delivery, strategy, stakeholder management. Almost nobody teaches you how to read a P&L or defend your roadmap in terms your CFO actually cares about.

Sebastian Mueller wrote about the four biggest pricing mistakes on Product Coalition back in 2020, and his observation still stings: ‘Pricing is incredibly important, yet very hard to nail down properly.’ Sebastian found that teams routinely underprice so badly their unit margins go negative. They literally lose money by scaling.

Think about that for a second. The better your go-to-market works, the faster you go broke.

What changed for Jon? He went back and learned the commercial side the hard way. In a follow-up piece, he describes walking into a GTM strategy meeting where the CFO wanted to see revenue projections, costs, margins, and ROI laid out in detail. Not user stories. Not sprint velocity. Financial evidence.

Jon writes that the moment he started presenting product decisions as investments with expected returns rather than features with estimated timelines, everything shifted. The CFO stopped being an obstacle and started being an ally.

Nicole Segerer made a related point on my podcast that stuck with me: ‘Evidence-based decision making is not just about user data. The most overlooked evidence in product teams is financial evidence.’

Most product teams can tell you their NPS to the decimal. Ask about gross margin per feature line and you get silence.

That gap is where the next generation of product leaders will separate themselves. Not by building better features. By understanding which features actually make money.

What is the one financial question about your own product that you genuinely cannot answer today? Reply and tell me. I read every one.