The Product Velocity Paradox: When Your Engineers Outrun Your Product Team

A year ago they rejected every product request. Yesterday morning they called me because their engineers are waiting for tasks. Here's why this is happening everywhere — and what to do about it.

Yesterday morning a friend called me. He runs a small startup — physical devices deployed worldwide, a webapp, and a team of four engineers. All four work with Claude Code.

"Sahar, we have a problem I never thought we'd have."

A year ago, his engineering team was drowning. Every request from product got the same response: "No bandwidth. Maybe next quarter. Prioritize and come back to us." The backlog was infinite. Product ideas piled up faster than the team could build them.

Then all four engineers started working with Claude Code. And something flipped.

"You know what the problem is now? They're waiting for tasks. They finished the backlog. They started building internal tools for other teams because they have nothing to do."

I asked him to repeat that. Engineers. Waiting. For tasks.

"Yeah. We build faster than we know what to build."

I needed a moment to process. Because this is a complete inversion of everything I've known in 9 years in the industry. The bottleneck was always engineering. Always. Product ran ahead with ideas, and engineering struggled to keep up. Now? Engineering runs ahead, and product can't think fast enough to keep up.

My friend's startup isn't an anomaly. It's a signal.

Harness surveyed 900 engineers and technical managers in 2025. The findings are striking:

• 63% say they ship code faster with AI
• Teams merge 98% more pull requests
• But PR review time increased by 91%
• Company-level delivery metrics remain flat

Read that again. Engineers are shipping dramatically faster — and the companies aren't delivering more. The report's headline says it all: "Productivity Gains Undone by Downstream Bottlenecks."

The bottleneck has already moved. We just haven't named it yet.

I started digging. When in history has a new machine flipped the bottleneck from production to thinking?

It didn't take long to find.

On the morning of November 29, 1814, John Walter II, owner of The Times of London, walked into his printing house and made an announcement that silenced every worker in the building:

"Today's paper has already been printed. By steam."

Friedrich Koenig had secretly installed a steam-powered printing press. It printed 1,100 sheets per hour instead of 240 by hand. A 5x jump. Overnight.

And then something unexpected happened. The Times could now print a newspaper faster than anyone could figure out what to write in it.

The bottleneck moved from the printing press to the newsroom.

This single constraint shift created entirely new organizational structures. The professional reporter. The news beat system. Wire services like Reuters and the Associated Press. These weren't invented because someone had a vision for modern journalism — they were invented because a machine was running faster than the humans feeding it content.

The printing press didn't need to get faster. The newsroom needed to get smarter.

I'm calling this the Product Velocity Paradox (PVP).

PVP happens when engineering velocity increases dramatically, but product output doesn't increase at the same rate. Not because the engineers aren't good. Not because the tools don't work. Because the bottleneck has migrated — from "we can't build fast enough" to "we can't think fast enough about what to build."

Eliyahu Goldratt described this exact mechanism in The Goal (1984). His Theory of Constraints makes a simple but profound observation: when you improve one constraint in a system, the constraint doesn't disappear. It migrates. In the novel, the protagonist improves a bottleneck machine on the factory floor. Throughput skyrockets. And then the constraint moves to... the market. They can now produce more than sales can absorb. Same factory, same people, completely different problem.

Applied to software development in 2026:

The Harness data confirms Goldratt's prediction perfectly. The constraint has migrated from engineering throughput to product clarity. Companies that don't recognize this will keep trying to optimize the wrong thing — faster CI/CD, more sprints, better developer tooling — while the real bottleneck sits untouched in the product org.

Here's the part where this gets personal — and a bit meta.

Over the past few weeks I've been building CandleKeep — a library that gives AI agents access to real books. The concept: your agents have training data (vague memories of books they read years ago) but they don't have the actual books open on their desk. CandleKeep fixes that by giving agents a library card — browse, check table of contents, read specific pages. Like a human researcher would.

I built fast. I shipped. And then I watched as users signed up... and never reached the "aha" moment. They registered, looked around, and left. I knew something was broken, but I didn't know where.

So I did something I think every developer-founder should be doing in 2026: I opened Claude Code, connected it to PostHog (my analytics tool), and said: "Analyze my funnel."

Claude went through the event data and identified the problem immediately. There were 5 steps between a user signing up and getting real value:

1. Register an account
2. Install the CLI
3. Create a library
4. Upload a book
5. Connect to an agent

Each step loses people. In product-led growth, every unnecessary step between signup and value is a conversion killer. Five steps isn't a funnel — it's an obstacle course.

But then Claude did something that genuinely surprised me.

Claude Code has access to my CandleKeep library. In that library, I have product books — Lean Analytics by Alistair Croll, Escaping the Build Trap by Melissa Perri, Hooked by Nir Eyal, Running Lean by Ash Maurya, and more.

Claude didn't just analyze the PostHog data. It went to the library, read chapters on activation metrics and time-to-value from these books, and came back with a synthesis:

"The data shows a 5-step barrier to value. Product-led growth literature consistently shows that reducing time-to-value is the highest-leverage intervention. Build a one-liner that skips the entire funnel and delivers immediate value. No signup required. One line in the terminal."

Wait.

My agent used my product to read books about how to improve my product. And then proposed the feature.

I built it that evening.

curl -sSL www.getcandlekeep.com/try | sh

One line. It scans your project directory, detects your tech stack (React, PostgreSQL, Python, etc.), suggests relevant use cases — frontend best practices, database optimization, security auditing, agent architecture — and launches Claude Code with tailored books from the CandleKeep public library. No signup. No installation wizard. Immediate value.

The signup comes after you've already received value. Not before.

Five steps became one.

My friend called because his engineers build faster than his product team can think. I experienced the same thing — I built CandleKeep fast, but my product thinking couldn't keep pace with my engineering output. The solution wasn't to build more features. The solution was to stop, understand the user, and fix the funnel.

That's PVP in action. The paradox is that velocity itself creates an illusion of progress. You ship code every day. You merge PRs. You watch velocity metrics climb. But the users? They're still not getting value.

The fix isn't more engineering. The fix is better product thinking at the speed of engineering.

And here's what I think the real unlock is: the same AI tools that accelerated engineering can accelerate product thinking too. Claude Code isn't just a code writer — it's an analyst that can read your PostHog data, a strategist that can read your product books, and a builder that can ship the solution. All in one session. The bottleneck only stays stuck if you let it.

If any of this sounds familiar — if your engineers are outrunning your product team, or your backlog is mysteriously empty, or you're shipping features that users don't adopt — here's what I'd suggest:

1. Name it. Recognizing PVP is the first step. It's not a hiring problem. It's not a motivation problem. It's a constraint migration.

2. Connect your agents to your analytics. If you're using PostHog, Amplitude, Mixpanel — connect Claude Code. Let it analyze your funnels, your retention curves, your activation metrics. Product insight at engineering speed.

3. Feed your agents domain knowledge. Don't just use AI for code. Use it for product thinking. Load your product books, your customer research, your competitive analysis. CandleKeep was built exactly for this — give your agents access to the books that shaped your product intuition.

4. Measure time-to-value, not velocity. Stop celebrating merged PRs. Start measuring how fast a new user gets to "aha." That's the metric that actually matters.

5. Try it yourself. If you want to see what agent-augmented product thinking feels like, try CandleKeep in one line:

curl -sSL www.getcandlekeep.com/try | sh

In 1814, The Times of London didn't need a faster printing press. They needed better reporters. They needed new organizational structures — the news beat, the wire service, the professional correspondent — to feed a machine that had outrun human thought.

In 2026, we don't need faster CI/CD or another sprint planning tool. We need product thinking that moves at the speed of AI-powered engineering. And maybe — just maybe — the same tools that accelerated the building can accelerate the thinking too.

The constraint has migrated. The question is whether your organization will migrate with it.

• Goldratt, E. (1984). The Goal: A Process of Ongoing Improvement — The foundational text on Theory of Constraints
• Harness: The State of AI in Software Engineering (2025) — The data on the AI Velocity Paradox
• The History of The Times Steam Press (1814) — How a printing press changed journalism
• Logilica: The Shifting Bottleneck Conundrum — How AI is reshaping the SDLC
• Croll, A. & Yoskovitz, B. Lean Analytics — On activation metrics and one metric that matters
• Perri, M. Escaping the Build Trap — On building product-led organizations (Chapter on Product-Led Organization starts at p.159)
• CandleKeep — Give your AI agents a library they can actually read