I had two more discussions this week with folks confusing “code” with “product.” One was a solo product builder waiting for customers to arrive, the other was a CEO who had promised the Board that faster development means faster revenue. Both times, being specific mattered. So I’m extending my Code Isn’t Product and Barbell posts with a list of ingredients: what goes into a successful product besides the code?

And I’m using three different labels for three very different things:

1. Executable code does something and runs without crashing

2. Commercially deployable software is executable code that also meets the reasonable expectations of paying customers

3. Revenue-ready product is commercial-deployable software plus everything else we need to generate an ongoing revenue stream

Here’s what is on my shopping list.

Executable code

…is what one engineer (plus an army of agents) might produce and put into the release process. At a minimum, we’ll need:

• Runnable code in a repository with previous versions, change logs, and prompts/agents/AI artifacts

• Automated smoke testing so we know it runs, with some output verification against sample data

• Confirmation from a responsible human that it does its fundamental job

This is where most of the “how fast we can build it with AI” discussions focus. Creating a working app and plausible interface in a few hours. This might be enough if our goal is a prototype or low-expectation free app.

Commercially Deployable Software

…needs to meet the operational and quality expectations of paying (corporate) customers. We assume that subscriptions include:

• SRE infrastructure including scalability, uptime, failover/rollback, application monitoring, response time SLAs, capacity planning, professional DevOps

• Data security, access management, license/subscription/billing management, entitlements, user communication preferences, SaaS-style affordances

• Automated test harness and test suite with enough coverage to confirm that the overall application hasn’t regressed

• Help system, trouble ticketing, appropriate levels of technical support when paying users get stuck

• If humans use it directly, ongoing UX/usability testing and in-app behavioral analytics. If machine-to-machine, input validation and rate-limiting.

• For AI features, some way to track model decay or data drift, as inputs evolve and training data ages. AI will degrade faster than deterministic features.

These are all system-level challenges, demanding ongoing monitoring and stepwise improvements. Plus practicing our human responses to inevitable crises. We ignore them when prototyping or vibe-coding.

But seasoned engineers and technical leaders do worry: how do we reduce the chances of our app going pear-shaped on a holiday weekend? How do we respond when it does? It’s easy in the “faster, faster” conversation to postpone critical systems-level issues. And I’m not hearing CTOs say they trust autonomous agents (yet) to handle all eventualities.

Market-Ready Products

…include everything that we need to turn commercial-ready software into revenue and successful customers. Software doesn’t sell itself, so we’ll need:

• Product/market fundamentals: crystal-clear problem definition, explicit target audience/ICP, validation that the product actually solves that problem for the ICP, positioning, benefits and messaging that resonate, competitive analysis, simple-as-possible product descriptions

• Economic essentials: a thoughtful business model with pricing units and price points, discounting model, feature tiers encouraging upsell, customer value/ROI calculator, license agreement, SKUs, fulfillment process, refund mechanism

• Go-to-market basics: marketing motion and budget/staff, direct or channel sales model, early customer testimonials, training/enablement, revenue targets that match the commission plan

• Customer support strategy plus staffing, escalation paths, renewal process

• Compliance/legal: privacy policy, data retention, relevant certifications, trademark review for product names, rights to use any training corpus

These are not code, and don’t come out of the engineering process. Most require negotiation/collaboration with various functional groups. And they have to be strategically right – not just plausible – since most products fail on the market side rather than the tech side. If we haven’t prepared great market-readiness ingredients, we have just another steaming heap of brilliantly unsellable software.

Titles aren’t important, but product managers have traditionally owned this shopping list. “Product engineer” discussions focus on building code faster when one person owns everything – but disregard commercial deployment and market readiness. That’s what I expect when engineers are defining roles, since it’s what they are closest to. But it invites a stunned silence as we release new products and don’t find paying customers.

So my solo product builder needs to find a go-to-market partner. And my CEO needs to identify the next revenue bottleneck when code development is faster than selling.

Sound Byte

Shipping code isn’t the same as shipping revenue — confusing the two is an unforced error.

• Reading the room, especially the c-suite

• Why product leaders need to understand/master corporate politics, or elevate someone who will

• Building personal connections with other functional groups

• Why aspirational product models may not be helpful…

51 high-speed minutes

Product Ops Confidential

Product Opscast Episode 26: Money Stories

In this episode, Graham Reed and Antonia Landi are joined by Rich Mironov, long-time celebrated product leader and author, to discuss his new book Money Stories. We get into the concept of a Money Story and why execs will hear this a lot more than backlog tables and user value graphs. Is this something product folks have been missing all this time? Maybe…

Listen now

17 days ago · Graham Reed and Antonia Landi

She’s an optimist, sharing her own product-meets-AI journey, joyously wandering into the unknown without pushing an agenda or toolset. It was a reminder that I (we all) need to find some fun, try new things, think about our own next adventures.
A nice offset to my default realism-leaning-toward-pessimism.

Video here, transcript here, add yourself to her list here.

I had yet another call last week with an AI engineer/cofounder who has built some very interesting software but gotten zero interest from his intended buyers. For 90 minutes, we ignored his beautiful tech, and dug into the product basics…
Target audience? Crisp problem statement? Compelling economic value message?
He had some hypotheses alongside a value story his intended users would find deeply insulting. He is trying to sell prospects on his concept of what they should need. I wish this were the exception.

We recapped my Code Isn’t Product post, why 10x Coding Speed Won’t 10x Revenue, and how the bottleneck is moving from raw code to honest discovery and commercial viability.

As AI accelerates core code development and reduces the detailed technical involvement of product managers, we still need to solve these two core product problems:

• Of the infinitely many things we could build, which ones are likely to drive revenue and business outcomes? (Note that this is not an engineering question.)

• How do we make more of our products successful in the marketplace? (Also not an engineering question.)

This has me drawing the AI-first product role as a barbell.

Classic Software Product Management (1971-2024)

During my decades doing this, we’ve spent the majority of our product time getting things built. Engineering created the software, UX created the experience, tech writers wrote the manuals, test engineers built the harnesses, but someone needed to drive clarity and adoption. Sondra Orozco describes it as “figuring out what their team should build with limited time and resources, and doing whatever it takes to make their product great.”

It looked vaguely like this:

The fuzzy front end is where we try to decide what we should build when faced with thousands of ideas and demands and suggestions and executive mandates. With severely limited resources. We wrestle with semi-quantitative insights, intuition, imponderables. We do open-ended discovery in the hopes of learning something. We try to validate problem statements (first) and then possible solutions (second) with our intended target customers. Define outcome metrics. We apply judgment, experience, common sense, war stories. Because most products fail here, before the first line of code is written, regardless of how fast engineering runs. Most products should never be built; most features should never be added.

We intend to put 20% of product effort here, but always short-change it... because every company believes that it can skip discovery just this one time on this one critical initiative. Our customers know exactly what they need. Our CEO is a visionary. Making software can’t be that hard. This one-off item won’t take much ongoing support. In spite of all evidence that most product work is wasted, our company is way above average.

The core development work (60-100%) is much more visible: SDLC, roadmaps, tickets, rituals, trade-offs, competing objectives, product narratives that don’t get read. We face the chaos... demands for ever-shorter schedules. Late-arriving requirements. Unexpected technical challenges. Sales escalations. Poached engineers. We satisfice and hope the next release will be easier.

Go-to-market readiness is everything that Sales & Marketing needs to start the money flowing: precise targeting/ICPs, messaging, pricing/packaging, ROI calculators, detailed-yet-unbounded use cases. Dazzling sales materials. Happy reference customers. Effortless onboarding. Bug-free software.

This gets 10-20% of an average product manager’s time, although it deserves much more. We may shift this to an under-appreciated product marketing or enablement group. Regardless, Sales & Marketing teams can’t succeed without these assets — they instinctively abandon products that don’t get immediate traction.

Product Management in AI-First Organizations (2027+)

Fast-forward to when we can deliver production-quality code 10x faster, measured from agreed features to full customer availability. (I don’t yet believe this, but will save that argument for another post.) That shifts the most valuable product work further to the ends — a barbell.

The Fuzzy Front End

We used to hide slow, uncertain discovery work behind an even slower development cycle. But now we’ll be building much faster than we can validate demand. The organizational pressure will be intense to skip the fuzzy steps and get right to coding.

Speed is our strategy! Users will experiment with everything we ship, and our instrumentation will tell us immediately what’s useful or valuable. Prospects will write our money stories for us. Selling will be faster and easier.

I don’t think so. Users/buyers are already overwhelmed, flooded with aspirational product pitches, trying to do their day jobs. 10x more features and tools and products will make it even harder to pick a winner.

And I don’t buy the “outsource our whole discovery process to AI” story. We need to put 40%+ of our time into evidence-based recommendations for a few big revenue bets. And convert those into money. Otherwise we’ll have the same uninspired, generic, AI-generated product plans as our competitors.

So instead, a few partial solutions for speeding up useful discovery:

Right Tools, Right Job

AI will speed up parts of discovery. Identifying users with similar support tickets, then scheduling calls with them. Daily analytics and trend identification. Scanning for competitor announcements. Suggesting money stories. Transcribing interviews and spotting themes. Reminding us to define success metrics before we ship. But we can’t automate judgment, context, or identifying the one really sparkling idea among the dreck.

I love Teresa Torres’ deep insight that humans need to do real interviews, yet AI coaches can help us be better interviewers.
And we don’t need to do discovery on everything. Let’s focus our attention on the big, risky, hard-to-reverse strategic bets. Muster the courage to discard the bottom 80% of our backlogs. And time-box decisions about smaller features, fixes, obvious improvements. See Büşra Coşkuner’s “When do you actually need Product Discovery?“

Putting 40%+ of our energy into serious discovery and market-sensing will let us get ahead of the daily anecdotal demand stream.

Core Development

Engineers do much more than build code. They understand systems, map out architectures, anticipate bottlenecks, apply hard-won learning around security and scalability and maintainability. They bring judgment, experience, talent, taste, intuition. I see that AI is dramatically accelerating the generation of code, but not convinced that we’re seeing 10x faster creation of commercially viable products. Some ways I think product folks can help more during core development:

• Keep teams focused on outcomes, customer value, market wins. Are we gold-plating that feature? Will users see the results of that optimization? Can we extract more market leverage from similar effort?

• Author whatever context files or product briefs or problem statements fit the new model. That still captures strategic intent.

• Humbly ask the bigger-than-code questions. Architecture, supportability, trade-offs. How do we know if our code still works when the underlying model changes every week? How will we track concept drift as users try new things and our corpus gets stale? What should we be worrying about?

Engineers get to decide how we build software, and choose their tools/processes/agents. Product folks try to keep our brilliant technologists focused on outcomes.

Go-To-Market Planning

If we can’t explain why someone should consider our product — in simple, user-friendly economic terms — then revenue doesn’t flow. Traditionally, product managers have passed this buck to product marketers or treated it as an afterthought. And we collectively had months (years) to draft go-to-market materials while products were built. Now that might be weeks.

Dirty secret: the best go-to-market intelligence comes directly from users and buyers, from the very same discovery calls we use for feature/function insights. Not from our own market-facing groups, not from industry analysts, not from the Board. But we often forget to ask.

Ways we could compress the GTM Planning cycle:

• Include product marketers (if they exist) in discovery calls. Ask the economic questions earlier: How would you describe the benefits? What else have you tried? How would you justify spending money on this? Who approves purchases? Sort out pricing, packaging, ROI metrics, and sales goals upfront.

• Use money stories to guesstimate future revenue for our big bets. And use those guesstimates to sidestep less valuable work.

• Identify Sales & Marketing capacity limits. If we can aggressively promote only two new products each quarter, propose the right ones.

• Ask the tough leadership question: which launches went well, and what does reasonable GTM preparation look like? Or consider the put-up-or-shut-up experiment, where some sales regions create their own messaging and packaging while others use what product/marketing supplies. Who is less unhappy?

Product Engineers?

My approach is in direct contrast to the product engineer trend. AI pushes product work to the ends and engineering work to the middle. I’ve met a few unicorns who are great at both. But this is mostly engineers doing hand-wavy product thinking on their way to shipping code. I’ve had to dig naïve CTOs out of this trap scores of times.

Exception: when AI engineers are building AI tools for other AI engineers, they are their own audience.

Sound Byte

The bar gets heavier at both ends: more judgment on what to build, more muscle on how to sell it. Engineering owns the middle.

2. I’ll be offering my full-day workshop on Money Stories one more time this year, Sept 16^th as part of ProductLab in Berlin. The Product at Heart version sold out early, and seats for this session are limited. https://productlab.app/

3. There’s an open slot on my CPO coaching schedule. Best fit are CPOs or Heads of Product wrestling with exec-level influence, organizational and political challenges, or mapping technical work to revenue-speak. Company-paid rather than out-of-pocket. rich@mironov.com

Hope to see you in person. _ R

I’ve had two recent conversations with CEOs who are confusing potential code acceleration with revenue acceleration. Here’s why that tanks the success rate of new products and forces us to refocus on go-to-market strategy.

Product success has rarely been about raw engineering speed. It’s always been primarily about the market: identifying real buyers with real pain, finding product-market fit, getting large-enough audiences to notice-then-try-then-buy-then-use-then-love our very cool stuff. That’s why profitable companies – and those scaling up from a few wins – shift spending from Engineering to Sales & Marketing as they grow.

Let’s look ahead to the math, and the next bottlenecks if production code becomes very cheap and plentiful.

1. 10x more products doesn’t mean 10x bigger markets or budgets. Or 10x more revenue.

Most new products fail, let’s say 60% [i]. 6 out of 10 fail, with 4 reaching break-even.

Supercharging our development process, we may now be able to build 100 new products where we used to build 10. But businesses aren’t increasing their software budgets by 10x to accommodate us, and consumers won’t be spending 10x more on apps or online services. The worldwide economy grew about 3% last year.

So unless we can steal a massive share of our current market or discover a Mars-sized greenfield opportunity, we’ll have the same 4 new products win in our marketplace. 10x more product drops the overall success ratio from 4-in-10 to 4-in-100, for a 96% failure rate.

“But we’ll take share from competitors.” Maybe. There will be some AI laggards lost in the flood. But most competitors will be using the same AI tools, hiring the same “how-to-agentic” consultants, reading the same superficially optimistic C-level AI case studies, and confusing token consumption with employee engagement. They each plan to steal your share of the market. Zero sum. Table stakes. Hope and bravado aren’t strategies.

“But the Jevons Paradox means the overall market will grow.” I agree. But at lower prices, with more commoditization and rapid erosion of pure technical advantage, which makes breakout products rarer. It might boost success rates from 4-in-100 to 5-in-100 or 6-in-100, but the broad math still holds.

Huge exception: fundamental AI platforms. If you have a few $B for head-to-head with Anthropic and OpenAI, now’s the time. Their market values are currently larger than the known universe, although they will quickly be commoditized – see tents and shovels, disk operating systems, client-server architectures, website builders, mobile app builders, and web animation standards.

2. Code Isn’t Product

In every generation, we relearn that there’s a lot of non-engineering work to turn code into revenue. We eventually have to market and sell our stuff to specific humans with existing problems and money. So core product deliverables include a narrowly defined ICP/target audience (”who exactly has this problem and will pay to solve it?”), detailed problem descriptions (”what exactly is broken, and what words do they use to describe it?”), solution context (”what does it need to do, how does it fit?”), and pricing economics (”how much is this worth to buyers, how do they measure success?”). Positioning, messaging, sales channels, objection handling, and a dozen other things that aren’t code.

Most products fail for market reasons: we didn’t find an audience with enough pain, or we didn’t build the right go-to-market process to bring in the money. “The code was late” is almost always a throw-engineering-under-the-tram excuse. (Even in the AI age, code won’t sell itself. And an emerging set of AI shopping intermediaries will still be flooded with millions of undifferentiated offerings.)

The current hyper-focus on development productivity will lead to a lot of organizational finger-pointing… why Brilliant Software Concept X missed its $1M/week target even though we published to GitHub and announced it on Product Hunt.

3. Customer Limits on Attention and Absorption

In the pre-AI world, enterprise customers already had trouble keeping up with our updates, new features, required patches, security notices, deprecated functions, and API improvements. We didn’t really expect them to read (understand) our weekly release notes or try out more than a few new features each quarter. Their attention was already very limited. Getting an enterprise to implement and adopt a new improvement often took years... lots of installed base merchandizing, then technical reviews, then impact and compliance and security assessments, then a slot on their infrastructure roadmap, then customer-side coding and testing and UAT…

Now we turn on the fire hoses. 10x more changes and improvements, each of which might destabilize something in their environment that your AI coding assistant doesn’t know about. B2B customers will push back, demanding quality SLAs and penalties and 10x more rigorous testing. Getting mass consumer audiences to accept weekly app updates will also be tough. Success is about adoption, not availability.

It took two decades for half of US households to get a personal computer. 4 years for smartphones to take 40% market share away from feature phones. So far, only a tiny fraction of even tech-forward users has tried GenAI coding. We always overestimate the speed of market adoption – the world isn’t as fascinated by our new widgets as we are.

4. The Pressure Moves to Marketing and Sales

Limited go-to-market bandwidth means that we’re still only able to promote and sell 2 or 3 big things this quarter, with 97 sitting on the shelf. The pressure to AI-enable GTM will be intense. It may be a while, though, before LLM-generated marketing campaigns and synthetic Business Development Reps and legal-bot contract reviews catch up to the new pace of coding. Spinning software products into gold is still hard work.

5. Easy Products Become Features

As we accelerate development, simple things will be demoted from stand-alone products to features. We used to have whole products to build database schemas, and coordinate meeting times among coworkers, and find a lost backpack, and translate foreign phrases. Now they are features of larger products.

Faced with feeble market response to our 100 new products, we’ll follow that same path — reclassifying most as value-added features to existing products. Differentiators become checkbox items as competitors feed our marketing materials into their own product agents.

Followed by intense downward pricing pressure. The plummeting cost of duplicating visible features will crank up the value treadmill. We will run even faster to keep our paying customers at their current price points. New entrants will give away (for free!) what we sell, just to steal our users. Enterprises will shrink their internal build estimates and demand deeper discounts. Part-time product engineers will create apps that claim to do everything we do. We will have to find non-code ways to defend our price lists.

6. Product Support Is Forever

High-velocity building can’t sidestep the installed base law of gravity: once a customer pays us money for a product, we’re obligated to support it forever – or until the very last paying customer cancels their subscription. Faster delivery creates a support overhang: someone must have ongoing responsibility for keeping that product understood, working, healthy, and fit for purpose. Smaller teams and solo creators encourage us to move on to the next thing as soon as v1.0 ships, pretending that this won’t end badly.

For decades, I’ve been championing that 35%-45% of total R&D budgets be spent on care and feeding. AI-enabled products are non-deterministic, prone to context drift, and may amplify hallucinations from other AI systems… so my numbers are probably too low.

OK, But We’re Still Going to Speed Up Coding!

Absolutely! Let’s give our brilliant engineers the best tools, and create more wonderful things. But this reinforces the product management shift from engineering focus to rigorous problem definition and go-to-market strategy. Not “can we build it?” but “should we build it, for whom, at what price, through which channel?“

Sound Byte

Let’s not build our way into a 96% failure rate and call it progress.

[i] There is a lot of noise around this. Clayton Christensen denied the “95% of new products fail” statistic attributed to him. PDMA found a 42% failure rate; ResearchGate clocked 76% failing in year one; Castellion & Markham collected peer-reviewed studies and got a 30–49% range. For our purposes, 60% is close enough.

Two great conferences [Productized and Product at Heart] these last two weeks… filled with thoughtful talks and shared experiences and book signings and surprises. (A saxophone quintet playing Bowie.)

Of course, AI dominated the talks and workshops, blending the excitement of new adventures with deep-seated concern for our craft/roles/teams. But so many of the side conversations were completely different – all about community, generosity, helping each other through the turmoil, paying it forward or paying it back. During the Product at Heart speaker dinner, Arne Kittler and Pippa Topp were asking us about how we had each first connected with the event – and to each other. There was a chorus of “I knew X who worked with Y who suggested…” and “I’d been reading Z’s writing for so long…” and “your Product Tank talk really inspired…” Those human connections and we-only-just-met-in-person-after-so-long-on-Zoom moments are what motivate me to show up.

So I borrowed a bit from my 2024 Productized talk as a more empathetic closer to my full-day Money Stories workshop. (We can’t be mercenary all of the time.) This was my prompt:

“Write down the name of someone who helped you at a critical time, provided some crucial advice, made a pivotal introduction, engineered a promotion, reached out when you needed it… and that you haven’t talked with in the last year. Then, right now, send them a short message of appreciation. 
And when you're back home, look for someone that you can help pull up the ladder behind you.”

I bet there’s someone that you’re overdue thanking. Now is the perfect moment.

-Rich

44 of us contributed, more are engaging with it. Give it a look. (I’m pleased to have been using ‘makers’ as an inclusive category since 2020.)

____________________

And I’ll be in London for a Money Stories book signing plus brief talk plus social time on Thursday 9 July, hosted by CPO Circles and friends. Free printed copies of the book with a suggested donation to RSPCA.

Last, I’m excited to at Product at Heart this coming week. Please find me a say hello.

Organizations that fund the building of software as one-time projects (“once we ship v1.0 of Product X, we move everyone onto Thing Y”) will inevitably be frustrated, fail to deliver outcomes, overspend, and eventually discard the work. Only to fund a replacement project later with similar results.
I’ve seen this play out hundreds of times.

For context, lots of physical goods are “done” and complete when built and sold. A hammer is done when it leaves the factory, and it’s mine when I buy it at my hardware store. I don’t expect upgrades or support or new features. Likewise clothes and pastries and soccer balls. When a publisher prints a physical book and sells it to me, it’s mine as-is. Tractors used to be “done” when they rolled off the assembly line before GPS and autonomous operations changed the picture.

But applying this to software is fundamentally incorrect, a core misunderstanding of how tech works and is supported. With inevitably bad results. Here are six reasons why you need to keep your maker team (development, product, design, test) intact after v1.0.

1. We always trim requirements to ship the first version. Every team is under pressure to get something out, to start earning its keep, to meet market windows. Along the way, we inevitably postpone some less-frequent use cases. Deprioritize a few lower-value features. Accept less-than-perfect scalability. Skimp on live user testing. Miss some failover scenarios. Leave out a marginal report or prompt or configuration item. Every time. Take a look at your hopes-and-dreams list (or PRD or requirements list or “start with the press release“ one-pager) for things that didn’t make the cut. There’s always a shopping list for v1.1 and v1.2 and v2.0.

2. We don’t know what’s missing until real paying users interact with our live product. Brilliant new use cases from early customers, unexpected inputs, telemetry that highlights poor workflow assumptions, data we thought would be easily available, unanticipated issues with languages or currencies or time zones or cultures, parts of our app that aren’t very useful, bank routing numbers in formats we don’t recognize… Putting the real stuff in the hands of live customers is inevitably humbling and exciting. No product survives first contact with paying customers.
   AI makes this even harder. Jeff Gothelf points out that real customers will use our AI features in ways we can’t anticipate.

3. Every system has bugs, and needs fixes. Even when it technically “works as intended.” Clarifications of our internal business rules. Obscure use cases that didn’t show up in the specs. Performance bottlenecks as we boost usage. Zero-day exploits. Special pricing or metering for our largest customer. I expect a system with no sustaining engineering to die within a couple of quarters.

4. The underlying infrastructure is always evolving. We may have built on AWS (or Salesforce or GCP or Azure or ServiceNow), which has its own stream of API updates and sunsetting services and non-optional changes. New browsers, passkeys, evolving payment-gateway requirements, MCP support for AI agents, emerging EU regulations, and new graphics standards... Inevitably, we’ll need to make ongoing, continuous updates to our own code to keep it running on our chosen platforms and interoperating with the rest of the world. Call it tech debt or software entropy, but we can’t ignore it or wait until next year.

5. There are always new dreams and new opportunities. Every buyer and user and support specialist and industry analyst and board member has suggestions for ways to improve the product. Every sales team and channel partner sees an adjacent market that needs just a few tweaks. Every technical team has ways to boost performance, smooth onboarding, cover more JTBDs, architect for the future. The pressure is irresistible.

6. The people best equipped to handle ongoing changes and improvements are the people who built it. Who know the inner workings intimately. Who wrestled with the specific design and architecture choices. Who committed the code and know about the dependencies. Who put their hearts and sweat into it. The POV that “we can just bring in contractors or borrow from other teams when urgent things need to be fixed” is misguided. Inevitably, the learning curve for new folks is much steeper than for those who’ve built it. Folks swiped from other projects do quickest-n-dirtiest work to get back to their real jobs.
   And moving our original team onto other stuff means that they quickly lose context… six months later, they mostly have to re-learn their own stuff. I don’t buy that “this can’t be so hard, AI can probably do most of it, we can re-form the team when we need them.”

The need for ongoing investment is a feature, not a bug or a mistake. Software is a depreciating intellectual asset, not a hammer.

Show Me the Money

Why does this matter? Companies that build software need to recognize and budget for this. Financial models need to match ongoing revenue streams (licenses or transaction fees) against ongoing costs (people and tokens).

Because we have to support every line of our code forever until the very last customer deletes it, we can’t pretend that one-off features built for some specific deal will be offset by one-time revenue splits. Those customers will inevitably open P1 support tickets years later, when their own system upgrades break something we’ve long since forgotten about giving them. Our CEO’s phone will light up with a furious demand to repair some data connector that a field engineer improvised in 2017, and we’ll agree to fix it.

Market-facing teams like to imagine that we can put 90% of R&D into shiny new things. New products, cool features, AI wonderfulness, killer apps, more sparkle and sizzle. But once we have products in market and revenue from real customers, that’s impossible. Sorry. We’re selling software, not hammers. It will always need more care and feeding than we’d like.

My default investment model has about 50% of R&D energy toward externally visible new features / opportunities / improvements that we hope will boost revenue. And 35-40% for keeping us in the software business. Your mileage will vary, but I’d consider shorting companies putting less than 30% into care and feeding.

Decades of observation suggest that overweighting new features (70%+) is a short-term shift… unsustainable after a few quarters. Then we inevitably flip to 60%+ firefighting, urgent fixes, pulling the red cord, paying down last year’s under-investment. Daily system health status meetings. All hands on deck. Public apologies to customers. Board-level reviews of ticket arrival rates. Deep tech discussions with folks uninterested in having deep tech discussions.

So one-time project-based budgets for commercial or production software ignore how the world works, and inevitably lead to financial and technical crises. It’s software-budgeting malpractice.

But We’re Outsourcing the Work!

Great, terrific, glad that you have the resources. You’ll pay twice as much to outsiders who don’t know your systems, context, architecture, or testing philosophy. Who don’t have a long-term commitment to your company’s viability.

And… everything about the above list is still true. Maybe truer. Requirements are always trimmed to fit the contract; no one can completely spec a system in advance; all software has bugs; our technical environment will keep evolving; and we’ll have a wagonload of new dreams and desires for v2.0 long before v1.0 is delivered.

So you should budget for your outsourced development partner to keep their (your) outside team on this project… at half or more of the initial contract run rate for another five years. The financials look very different when we add some reality. (“Wait! How can going outside to build X be twice as expensive over the long run as building it ourselves?”)

Yes, But We’re Only Going to Use This Once, Internally, For a Few Months

OK, there are some internal tools that might have a very short, finite lifetime. But mostly not. It’s like promising to skip dessert tomorrow night if we can have extra dessert tonight. These tools always outlive their stated purpose, and without an owner they eventually blow up.

Sound Byte

Software always needs ongoing improvements, fixes, and the people who know how make those. Inescapably. Unavoidably. Inevitably.

Dropped my wallet tonight walking the dog, and panicked panicked panicked panicked!

Retracing my steps when my mobile lit up: two kids found it, handed it to adults at the nearby event venue, who Googled me to find a local number, and waited patiently to return it. Intact. Smiles all around, cash thank-you refused, 50 kg weight lifted. Adoro viver aqui com pessoas tão generosas.

A year ago I wrote about how AI would shift the bottlenecks in product development from the middle of the cycle — writing code — to the end, where we help customers understand what we built, try it, and turn it into value (money). And to the front, where we figure out what’s worth building.

Time for a check-in.

What I’m seeing is something more acute than a bottleneck shift. It’s a market-driven confusion between creating code and creating products. That distinction is about to get more obvious.

The 100x Problem

AI is making it possible to ship 100 times as many new products (or features) as before. The engineering throughput is becoming real. Boards are impressed. CEOs are under pressure to do much more with less R&D. AI is the stated justification for slashing engineering/product/design teams. (Meta, Amazon, Intel, Microsoft, Alphabet…)

Here’s what isn’t scaling: customer attention.

Your prospects don’t have 100 times the bandwidth to evaluate new offerings. They’re receiving more pitches, not fewer. (Cf: AI slop.) Their buying processes haven’t accelerated. Budgets aren’t going up.

Channeling April Dunford, this is a positioning problem. The dozen words you use to describe a new product matter more than ever. In a world with 100x more offerings, it’s what will determine whether anyone even hears about yours.

And positioning that works is built from the language your actual users actually use to describe their perceived problems — not the language your engineers use to explain the solution. Which means actually talking with customers and prospects, rather than synthetic users. A lot. Maybe even before production code is shipped.

We are dramatically increasing the urgency of doing good discovery. But that’s not in the zeitgeist right now, so expect a summer of DOA products.

The Forward-Deployed Engineer Tell

No surprise that forward-deployed engineers are trending. Expert, dedicated technical resources placed on-site at enterprise customers, helping them figure out how to plan and deploy and extract value from AI-enhanced products. I understand the appeal. It sounds proactive and customer-centric.

For me, this is evidence of shipping tools or kits or frameworks or platforms, rather than finished products that solve well-defined problems.

If your customers need a full-time engineer sitting next to them to understand what your product is supposed to do, how it fits their environment, and how they measure success from it… these are product problems, not deployment problems. (Or you’re eager to adopt a professional services model.) The discovery and decision work that should have happened before launch is now happening after the contract is signed, on the customer’s dime or yours.

Forward-deployed engineers are expensive, hard to hire, and don’t scale. They are a workaround for patchy product thinking. When I see a company moving urgently this way, I see bits winning out over solutions.

The Next Bench Syndrome, Revisited

There’s another model getting heavy promotion right now: solo product-engineers building end to end without committees or reviews or management overhead. They trust their own judgment, shipping 50x faster. This model works in a narrow set of circumstances.

At HP, this dynamic was called the next bench syndrome [1]. Engineers built tools for the person sitting at the next bench — someone whose problems, language, workflows, and buying behavior they understood intimately. When your user is essentially you, you can trust your own taste. The feedback loop is tight, the intuitions are well-calibrated, the product decisions are reliable.

The general case is a problem, though. Engineers often aren’t adept at extracting what veterinarians need, or teachers, or firefighters, or government employees managing complex procurement processes. Users have different problems, different language, different success metrics, and very different buying behaviors. Building for them requires going out into the world to find out — systematically — what’s true.

The product-engineer model isn’t a universal pattern. Extrapolating it to the general market is how we get waves of technically impressive, commercially disappointing products.

What Comes Next

I expect the next two to four quarters to be even more painful for product people. Boards will keep pushing for speed. Engineering throughput will keep climbing. Upcoming AI IPOs will be astronomical. The pressure to treat shipping as succeeding will intensify, because the metrics look great in the short run. We’ll be Cassandras: punished for predicting problems.

Most of these products won’t stick — not because the code is bad, but because the discovery was skipped; the positioning was wrong; the pricing and economics were slapdash; the deployment barriers were underestimated; and the users weren’t who the builders imagined. These aren’t new failure modes. They’re the same ones we’ve seen across every technology transition. AI gets us there much faster.

When that reckoning comes, two things will become valuable again: strategic product thinking at the front of the cycle, and brilliant product marketing at the back. Not as overhead, but as work that determines whether code turns into revenue.

We’ve learned this lesson before. Tuition is about to go up.

Sound Byte

AI is giving us 100x the code. Nobody is giving us 100x the customers or 100x the revenue.

[1] Bill Hewlett coined this term. From John Minck’s internal history of HP: “The Hewlett-defined ‘next-bench syndrome’ was another key to our creativity. Not only did every design engineer use HP test equipment every day, but they also lived next to other groups who were doing similar but adjacent measurements. The informal culture in the labs afforded a lot of cross-fertilization at the traditional coffee breaks twice a day.”
The same mechanism that drove innovation in instruments became a liability when HP entered consumer markets — calculators for non-engineers, personal computers, printers.

BTW I’m honored to have been at HP in the early 80’s. A visionary company with world-class products, great leadership, thoughtful long-term employee practices, and dedicated to serving the broader community as well as shareholders. Bill and Dave pioneered everything that made Silicon Valley humane and inspiring.

My in-person events this summer, hope to see you at one of these:

• June 4, Product Camp Dublin, free! I’ll also be teaching in TUDublin’s post-grad product management certificate program – poke me for info about joining the next cohort.

• June 17-18, Productized Lisbon. Brilliant speakers, workshops, my hometown event! We’ll share three Money Stories that you need to have.

• June 25-26, Product at Heart, Hamburg. Dazzling talent, precisely curated. I’ll be workshopping and signing (giving away) books.

• Sept 15-17, ProductLab, Berlin. Join my all-day Product Value workshop as part of this AI-focused event.

And in planning, an informal talk plus book signing in London, July 9.

We’ve been focused on how AI is accelerating the creation (building) of software, substituting expensive development tools for more expensive human experts. The next looming economic challenge is at runtime – where our customers rack up huge token costs for us as they take advantage of our latest AI features. As activation scales up, we will owe our AI vendors hefty operational fees. This raises some classic product/engineering challenges.
(Shardul Mehta provided a really good prompt here.)

Recent non-AI examples are MoviePass, which lost more money as its customers went to see more movies. And Spotify, which pays most of its revenue to artists – even at scale.

Example: We’re a company with portfolio management software for professional investors. Traditionally, we’ve focused on administration and record-keeping: tracking trades and price histories, profit/loss calculations, tax impact estimation. Our R&D team is now using AI tools to build our (traditional, deterministic) products faster and maybe cheaper. We pay Anthropic and Amazon and Google and Microsoft for that.

But we also want to add some AI-driven analytic features to let our users make smarter investment choices. Such as “do detailed historical return comparison on these different portfolio models and ETF bundles.” Now we’ll incur runtime costs each time they do analysis within our product. Very smart (or very inexperienced!) users could easily spend millions of our tokens. Which we also buy from our AI model vendors.
This will chop our traditional SaaS margins, and we don’t want to go bankrupt giving away expensive tokens to fixed-price subscribers. So it’s worth some operating-cost thoughts.

An Old Lesson

During the early 90’s database wars, I was at Sybase – which had an elegant technical solution to an emerging systems problem. Queries could be very slow, expensive, and poorly written – sometimes running for hours and not deliver the desired results. While consuming lots of system resources. Sybase pioneered “stored procedures” which let our customers “compile” frequently used queries for more speed and efficiency. For instance, stored procedures enabled programmatic stock market trades – letting algorithms make buy/sell choices much faster and more precisely than humans at screens. SQL databases were trendy and exciting, but dramatically faster queries saved massive system resources. (And created new opportunities.)

Pulling that observation forward… we should see classic engineering and product approaches reappear as ways to manage AI runtime costs.

Context-Specific Leverage

If we’re focused on specific customers solving a narrow set of hard problems, we can provide AI content that reduces the need for generalized learning. Our portfolio software company should pre-computing decades of ROI data on the top 5000 securities (to save tokens on doing it again); create skills or scripts for portfolio design and correlation computations; and pre-load the most important academic papers about risk-adjusted return. What else would make our context smarter and cheaper to operate?

Optimizing Happy Paths

If well-bounded, our new features should lead users to a few high-volume activities that add lots of value. That could include “calculate five-year correlation and covariance between these two investment types.” Clarity here lets our brilliant engineers address the slowest steps of our most frequent asks.

“Claude: representing a software architect, look at the last 50k requests and make suggestion for ways we could reduce the token cost of calculating correlations among asset classes. Include ideas around caching, initial data values, precomputed results, parallel computation, logarithmic estimation, and Monte Carlo simulations… explicitly consider accuracy versus token cost trade-offs. Cite instances where these strategies have improved performance in previous generations of commercial application software.”

Throttling Usage

Naive users may run into predictable (and expensive) problems. Some legitimate corner cases may be a bad fit for our app – or be very expensive to run. And some activities may be inappropriate, so we’ll ban them our Terms & Conditions.

It’s easy for new users to spin up unbounded-and-useless research requests. “Do a correlation analysis of all publicly trade stocks and commodities worldwide against the top 100 US federally provided economic indicators. Group by industry and geography and ownership structure and profitability and years since founding.” That query will run forever. So we’ll add a throttle that pauses requests at 90k tokens and notifies the user.

We don’t intend this platform to execute real-time trades, especially since we’re not registered with the SEC or licensed to do that. So let’s explicitly exclude requests to trade. Likewise, let’s block inquiries for non-public information that would get everyone into regulatory trouble.

Like mobile carriers, we can set a very high price on huge overages. If we expect reasonable users to consume 2M tokens/month, an exorbitant price >100M tokens/month would punish the few massive abusers (or drive them away) without upsetting our best customers.

Launch an agent to identify abuse thresholds, estimate elasticity, and model pricing strategies.

Anticipating Problems (and Features)

Some of our users are more creative than we are. With better tools, we can now use that to our advantage. What should we be productizing next quarter?

“Claude, group this month’s AI requests from our 25 most active clients into themes. Summarize each theme including likely reasons for those requests, identify those that are trending positive, and estimate average token cost per request. Suggest which would be good additions to our offering.”

Sound Byte

For the first time in a generation, the cost of running software will start to dominate the cost of building software. Let’s act strategically instead of being surprised.

I don’t always get it right. I complain about glossy war stories and universal product operating models, but some of my own suggestions are too easy or out of context. Here’s one that I am retiring from future talks, posts, and podcasts…

For about a decade, I’ve been dropping a “magic bullet” anecdote into some of my talks — reserving a tiny bit of R&D capacity for the VP Sales to use on that one special opportunity. A way to take the edge off constantly turning down one-off deal-driven requests and less important single-customer suggestions. “If it’s really that important and really that small, then the CRO can make the hard choice and use this quarter’s magic bullet on it.” Part of my overall theme of managing scarcity. See 41:58 in this Business of Software talk.

But it doesn’t address the underlying reasons why revenue-side organizations are universally frustrated with product/engineering teams. And it often doesn’t work in practice.

Here’s what recently came in from an anonymized product leader:

We’ve tried your “magic bullet” concept, but ran into a tension that felt worth writing up. Last year, we tried it with our customer-facing teams.

The sales organization is supposed to get one magic bullet each quarter, worth two weeks of one engineer’s time. The idea was simple: when they pull the trigger, it’s something that really matters and we make it happen.

On paper, it worked: requests were well-scoped; engineering delivered what they committed to; everyone acted in good faith. In reality, it didn’t land. The first magic bullet hit a serious bug late in development, and we missed the window. So while the work happened, the deal was lost. Another time, the request was just too big.

Today, we had an awkward-but-honest conversation: “Is there any point in magic bullets if we don’t get the thing we asked for?” They’re frustrated. Honestly, so am I. And the hardest part is that they’re not wrong. There is real customer need behind these asks.

Engineering didn’t fail. Product didn’t skip steps. The process did. What I’m learning: constraints like “two weeks” feel empowering, until reality reminds you that delivery isn’t fully predictable.

Mea culpa. I really appreciated the unvarnished feedback.

What Real Product/Engineering Teams Face

I had simplified this story over time, glossing over some harsh R&D realities:

• In aggregate, incoming demand is usually 20x to 50x capacity. Not 20% to 50%. And I don’t see AI resolving this soon, since it’s about much more than coding — it’s about the whole organization’s ability to understand and build and educate and communicate and sell. (See Bottlenecks.) We will never be able to deliver everything that any customer asks for. And shouldn’t. This is a core frustration for sales teams, since they face customers every day with new requirements and demands.

• Creating a separate, special queue for a few “magic bullets” does not create any new capacity. It steals from core development, which is always already overcommitted and Jenga-stacked with money story work that ties to important revenue.

• Sizing development effort is art, not science, and there is tremendous pressure to be optimistic. (“Come on, it can’t really be that hard!” says every exec when a deal is hanging fire. “We don’t need to gold-plate this, and it’s only for one customer, and they promise to support it themselves…”) Building production-worthy products is inherently unpredictable.

“Magic bullets” can become just another way for Engineering and Product to ignore the laws of physics, try to please, over-commit. Even though we know that doing X for this customer absolutely means not doing Y elsewhere.

The Right Context

In one organization where magic bullets worked well, I had built a deeply trusting relationship with the VP Sales — including lunch offsite together every week. We talked through emerging issues without assigning blame, and looked for shared wins. We separated personality clashes from operational snafus. We never threw each other under the bus in larger meetings. And I got early heads-ups on that quarter’s likely magic bullet — so my team had time to think, rough-size, and decline big/risky requests. (Notice this is first a people problem, not a process problem.)

And it fit into the larger planning cycle: we — Sales, Marketing, Product, Engineering — put our heads together to agree on a strong roadmap each quarter. So when something new popped up, it wasn’t something we had already deprioritized. C-level trust and context and self-control were the real magic bullets.

Sound Byte

Be skeptical of magic bullets, easy advice, and war stories. Including mine.

• Why product folks need to speaking the language of money with GTM execs and partners

• A simple story framework: two numbers you know and, one you guessestimate for a not-accurate but useful discussion

• Money stories as a strategic tool to reduce interrupts and better align outcomes with output

• Bringing a bucket of humility, since consensus is more important than being the smartest person in the room

45 minutes

One of my CPO coachees has a product team that recently made some major pricing and packaging changes – after a lot of research, experiments, and modeling. The first month has gone very well, and he is working on a board update. We looked at some draft slides, including this chart:

Predicted Actual
Avg Subscription Price +1.6% +1.7%
Annual vs. Monthly new subscribers +4% +4.2%
Free-to-paid conversion -2.4% -2.7%

That sparked a Money Stories conversation:

• Me: “You’re showing that your team did good estimations, but I don’t think that’s what the Board cares about. And they may fixate on the lower conversion rate, which is much less important than the other two numbers. What do they need to hear from you?”

• CPO: “How this translates into top-line revenue?”

• Me: “Yup. You know your ASP, but the Board probably doesn’t. Do they know how much it’s worth to boost that by 1.7%? Do they remember from last meeting why shifting from monthly to annual subscriptions is so valuable? Or that it’s a big win even with lower conversion rates?”

• CPO: “Right. We need to finish our sentences. Tell the money stories that get us from product OKRs to outcomes.”

Notice how adding one column tells the Board what they want to know:

Predicted Actual 2026 Impact
Avg Subscription Price +1.6% +1.7% +3M €
Annual vs. Monthly new subscribers +4% +4.2% +5M €
Free-to-paid conversion -2.4% -2.7% -0.6M €

Our CPO now has a chance to talk about how this contributes to the company’s growth, and explain the impact of each line. “We raised monthly prices, which increased the top line ASP by roughly 3M €, but hiking those monthly prices also shifted customers toward annual sign-ups… which boosts LTV and reduces churn substantially. You’ve been asking for that. The free-to-paid conversion drop was expected – because of the higher per-month pricing – but that’s much smaller than the positive impacts. So we’re delivering a substantial part of the 2026 target.”

This shifts the discussion from complex non-financial OKRs and delivery dates to revenue. Which is what the Board is really interested in. And it builds trust: if the product team was able to drive pricing and packaging changes that improved results, then their other work gains credibility.

Sound Byte

It’s unreasonable to expect execs and board members to remember product complexities or easily connect OKRs to revenue outcomes. We need to connect the dots for them… do the math… finish our money sentences.

(lifted from a CPO coaching call this week)

We’re not there yet, but may be close to the moment where startups or existing competitors can agent-scrape their way through your production application and clone all of the accessible parts. Create a reasonable likeness of your hard work in not much time. That will gut development speed as a fundamental advantage. How will we support long-term value and long-term revenue in a flood of lookalikes?

In traditional strategic language, what moats can we construct other than time-to-market to defend our products and deliver ongoing value? What business models and real-world advantages can we cultivate? We need to find non-code advantages. Here are a few categories.

Scale and Market Dominance

A lot of tech markets are winner-take-all: scale is its own advantage. Being the biggest is its own defense.

• Social networks. We’ve seen a lot of social apps launched since Twitter X went to the dark side. Most haven’t flourished, because the tech is much less important than the audience. Why join a platform with few of the people you want to interact with?

• Bookstores and general ecommerce. Vendors need to be where their buyers are; consumer shopping habits are sticky. Even if Amazon is consuming the world.

So if you’re in a race for market dominance, tech (especially PLG) that helps outgrow competitors and upstarts may be your best play. Otherwise you may need to find some small, tight-knit community that has strong reasons to reject the dominant player.

Algorithms, Datasets, Transactional Info

If you have gigabytes of non-public data or difficult-to-duplicate information, you may have a long-lived strategic asset. What do you know, and what insights can you generate, that tomorrow morning’s open LLMs won’t reveal?

• The literature is clear that forecasting stock movements from public data is a losing game, but huge spending in high-frequency algorithmic trading suggest that super-fast NYSE network connections and massive compute power and a few physicists can be combined to get ahead of individual human investors.

• Until recently, the CDC was the nexus for worldwide intelligence about infectious diseases and still-emerging pandemics. They knew things – and had very sophisticated models – which didn’t exist anywhere else.

• As long as ADP continues to process a lot of US payrolls, their employment surveys will have unique advantages.

Decades ago, I was at a clearinghouse for worldwide dial-up access. (Yup, that long ago!) We had multiple providers in each city, and routed dialup requests to the local number that had the best connect success and data speeds. That meant we knew, city by city, whether AT&T or MCI or Sprint (or BT or Telstra or Vodafone) had the best service in each place. Using that hard-won information, we built a service that was demonstrably better than any of our suppliers – since we optimized location by location, which was always better than any single supplier network. And (icing on the cake), we sold network quality data back to our suppliers. Our transactional quality dataset became a strategic weapon.

Trust and Community

We’d like to believe that our product or service provides heartfelt value to our users – outside of any core economics. But it’s really tough to grow a fan base that sees we care and share and always take their side – in the face of relentless revenue pressure. (Slippery slope of carefully curated advertising.) But there may be a moat for you if you’re willing to turn down seductive-but-sneaky monetization moves that users might not immediately notice.

Craft sites that really feature crafters and emphasize advice over kits? Dojo/gym management apps that truly serve trainers? Home improvement sites with honest reviews? Trust, enthusiasm and community are increasingly fragile in the age of instant price comparisons.

Familiarity (A Leaky Moat)

Traditionally, users learned how to use a particular application (Excel or Salesforce), and didn’t want to learn any alternatives. Competing products had to be “Salesforce-like” or have an Excel mode to coax away long-time users. (Who moved my cheese?) I think we’ll see this fall away. Smart product teams should be able to spin up ‘work just like that other product’ agents which mimic a variety of interaction models. One moat drained.

BTW, I’m not a lawyer, but IMO copyrights and trademarks and “don’t steal my code” legal remedies are too slow and too uncertain. We have to win in the market.

SOUND BYTE

Product strategy has always been much more than “ship it fast.” The moats aren’t (just) in our code: they are in what we know, who trusts us, and business models that are genuinely hard to clone.

I’m very excited about an in-person talk and book-signing here in Lisbon: Sixt is hosting an event on Weds, March 11, 630pm (18:30 WET) at their Lisbon Hub… ART’s Building, Av. Dom João II 49, 1990-019 Lisboa. Register here, look forward to catching up in person.

We will have books to give away, social and Q&A time, and a great opportunity to reconnect with Lisbon product/tech folks.

If you’re somewhere else, I’m joining a series of virtual talks and meetups:

Feb 25 (today!), 730am Eastern Time @ Product Coffee

Jason Brett and Product Coffee (Atlanta) are hosting me for a Money Stories and Q&A/AMA early East Coast time. Register here.

March 4, 4pm Central Time @ Product Tank Chicago

Pritam Das and PT Chicago will host an afternoon session on “Money Stories and Earning Our Keep.” Register here.

March 5, 11am Pacific Time @OC Product (Orange County)

Greg White and OC Product (formerly Orange County Product Managers) has this late morning Money Stories discussion – early evening here in Portugal. Register here and maybe win a book.

March 11, 630pm AEDT, Product Circle Chat Sydney

Irene Liakos will host from Sydney, and we will give away some books to folks in ANZ-friendly time zones. Register here. (My clock will read 7:30am GMT.)

Or let me know if your group would like to host a (remote) conversation or Money Stories talk.

Eryk Salvaggio's ChatGPT Breakup Mixtape (2026) is the smartest, funniest, most insightful piece on LLMs I've read in a very long time.

Actual AI breakup convs set to AI slop-pop. I laughed, I cried. Where can I buy tickets for the Eros tour?

https://www.cyberneticforests.com/news/chatgpt-breakup-mixtape-2026