10x Coding Speed Won't 10x Revenue
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.
Whenever I engage with companies I go through the whole "the Product isn't what engineering builds, it's the whole go-to-market around it; it's how you put it in the hands of customer and get paid". Everyone nods and agrees that this is essential and needs to be done.
Once through the doors, however, I find that the only "strategy" they have in place is "speed" and the only concern is "make engineering go faster". No amount of explanations about speed vs velocity (directional) seem to matter.
The rest of the work, the parts that matter so much for success, have to be done almost under the table, in back channels, outside hours. And we end up doing it, because we care (and get measure on) product success.
This connects to something I keep running into: Teams treat "we shipped it" as the finish line, when shipping is just the start of an obligation. "Product" is more than shipping: It's also business cases, marketing, buyer experience, support experience, communication, and so much more.
Thanks for pointing out that each feature has a much higher cost than just development cost!