When Learning Became the Bottleneck

How we redesigned our product process once implementation stopped being the bottleneck.

We thought AI would accelerate our product process.

Instead, it invalidated large parts of it.

The biggest shift wasn't that engineers could code faster. It was that implementation stopped being the bottleneck. And once that happened, we realized most of our organization was still optimized for protecting engineering time as if it were the scarcest resource in the company.

A year ago, our pipeline looked like most product organizations I’ve worked in:

Discovery. UX research. PRD. Design review. Tech design. Sprint planning. Story points. Build. Release. And then finally if anyone remembered to instrument it, learning.

It was a system built for a world where implementation was expensive.

So every step before the build existed to reduce ambiguity before engineers started coding.

Then AI changed the economics of the build.

And like most teams, our first instinct was not to redesign the system. It was to run the existing one faster.

That’s the trap we fell into.

For several months, we used AI to accelerate everything we'd always done:

• Faster PRDs
• Faster design drafts
• Faster user-research summaries
• Faster ticket grooming
• Faster technical specs
• Faster sprint planning

We were operating the same machine at higher RPM and calling it transformation.

The result was a lot of polished preparation work that no longer accelerated learning enough to justify the coordination overhead.

The coordination overhead had started exceeding the implementation cost.

The build wasn't the bottleneck anymore. Learning was.

The optimization target changed

The most important shift we made was changing what we optimized for.

Before AI, software implementation was expensive enough that organizations invested heavily in reducing uncertainty before engineers started building.

When implementation is costly and slow, mistakes, rework, and coordination failures are expensive.

So organizations naturally evolved systems optimized around pre-build certainty.

The KPI many teams implicitly optimized for was:

Time from “in development” to “in production.”

How fast does engineering ship?

But once implementation became dramatically cheaper, many of those uncertainty-reduction mechanisms stopped making economic sense at the same scale.

It became faster to test many assumptions in working software than to debate them in planning artifacts.

That changed the optimization target.

The KPI we optimize for now is:

Time from assumption to learning.

How fast do we resolve uncertainty?

Every successful product company is, at its core, a system for resolving uncertainty.

You form hypotheses, test them, learn, and iterate.

Progress comes from tightening that loop faster than competitors do.

Before AI, implementation speed heavily constrained that loop.

Now, in many cases, it doesn't.

That shift forced us to reevaluate almost every part of our product process.

Because once implementation became cheap, every workflow upstream of it had to justify itself differently.

The question stopped being:

“Does this help engineering move safely?”

And became:

“Does this accelerate learning, or delay it?”

Once we looked at the organization through that lens, the audit became obvious.

We also started asking a different question before almost every discussion:

What's the cheapest way to reduce this uncertainty?

Before AI, implementation was usually the expensive part.

Increasingly, it became the cheapest part.

So instead of debating assumptions endlessly, we started building the smallest possible version, shipping it, observing reality, and iterating.

That doesn't mean thinking stopped mattering.

It means implementation became part of thinking.

The cost of the build collapsed

We don't have a perfect benchmark for it, but the economics of implementation changed dramatically.

Flows that previously required coordination across frontend, backend, and design now regularly ship from a single engineer in less than a day.

Features that once justified sprint-level planning now often become disposable probes.

That shift matters because organizations are shaped around constraints.

And many of our processes were designed around a constraint that weakened significantly within a year.

Some protections still mattered:

• Production stability
• Cross-cutting architecture
• Public APIs
• Security
• Data migrations and other irreversible decisions
• Regulated workflows

AI disproportionately reduced the cost of reversible decisions.

That's why experimentation exploded while architecture, migrations, security boundaries, and external contracts remained critically important.

Those stayed.

But many other practices had quietly become inertia.

Our pipeline, before and after

Almost nothing got eliminated outright.

The practices that still protected something genuinely expensive stayed. In several cases, they became even more important.

What changed was the depth, timing, and ownership of everything else.

We stopped treating process as sacred and started treating it as economic infrastructure.

What got worse

This transition wasn't purely positive.

Reducing process friction doesn't automatically create clarity. In several cases, we shipped faster but learned less because experiments were poorly instrumented, assumptions were vague, or teams optimized for output instead of insight.

We also discovered that some coordination problems become harder when implementation gets cheaper.

When building is expensive, people naturally slow down and align before acting.

When building becomes nearly free, organizations can accidentally generate noise at enormous speed.

Weak judgment scales surprisingly well with AI.

We saw cases where:

• teams shipped experiments without clear kill criteria
• instrumentation lagged behind releases
• low-quality ideas survived longer because they were cheap to build
• junior engineers struggled more without explicit structure
• product discussions became noisier because “we can just build it” replaced prioritization discipline

The removal of friction doesn't eliminate the need for thinking.

In many ways, it increases it.

Why the old role boundaries stopped making sense

Most product organizations were designed around a world where implementation was slow, expensive, and difficult to reverse.

That naturally created specialized roles and sequential handoffs.

PMs defined.

Designers designed.

Engineers implemented.

Analysts measured.

That model made sense when implementation itself was the dominant constraint.

Specialization reduced risk. Handoffs reduced expensive mistakes. Planning reduced costly rework.

But once implementation became dramatically cheaper, the economics of those boundaries started changing too.

Coordination became relatively more expensive.

Iteration speed became strategically important.

And implementation itself became part of the learning loop.

That didn't eliminate roles.

But it changed what made each role valuable.

The shift wasn't from specialists to generalists.

It was from artifact production to uncertainty reduction.

PMs spend less time producing detailed specifications and more time defining assumptions, success metrics, and kill criteria.

Designers spend less time polishing static mockups and more time observing behavior inside working products.

Engineers operate less like implementation endpoints and more like owners of learning loops. They push back on unclear assumptions, think about instrumentation, and care about rollout strategy, observability, and reversibility.

Agents increasingly handle large parts of implementation and testing work, while PMs and analysts contribute directly to product behavior through prompts, workflows, skills, instrumentation, and lightweight code changes.

The boundary between defining the product and shaping the product became much thinner.

The result is a system with fewer rigid handoffs and more shared ownership around learning.

But it also demands more judgment.

When implementation becomes cheap, weak thinking scales faster too.

What we noticed about experience

There’s a popular narrative that AI flattens the playing field , that junior and senior engineers are converging because the tools now do much of the implementation work.

That’s not what we’ve seen.

If anything, the opposite happened.

When implementation stops being the constraint, judgment becomes the scarce resource.

Knowing:

• which experiments are misleading
• which practices are still protecting something important
• which assumptions are worth validating at all
• which shortcuts will become expensive later
• when speed creates leverage and when it creates chaos

…became dramatically more valuable.

Those aren’t things you can fully delegate to a model.

They come from pattern recognition built through experience.

Experience didn’t become less valuable.

It became more leveraged.

Less effort goes into producing implementation artifacts.

More effort goes into:

• prioritization
• framing
• system design
• sequencing
• defining learning loops
• identifying irreversible decisions
• recognizing weak signals early

AI amplified execution.

But execution was never the hardest part of product development.

Judgment was.

AI removed much of the execution friction that used to mask weak judgment.

Now organizations experience the quality of their thinking much more directly.

The question we now ask constantly

If I had to compress everything we changed into a single question, it’s this:

Was this process designed to protect something that's still expensive, or something that used to be expensive?

That question turned out to be surprisingly useful.

Because most organizations inherit processes long after the constraints that created them disappear.

And for a long time, software organizations were built around a very real constraint:

Implementation was expensive.

So we optimized for:

• alignment before action
• certainty before implementation
• specialization before iteration
• planning before learning

That made sense.

But AI changed the economics underneath the system faster than most organizations changed the system itself.

Implementation became dramatically cheaper.

Learning did not.

And once that happened, many of the coordination structures we inherited stopped being accelerators and started becoming drag.

Not because process stopped mattering.

But because the bottleneck moved.

The bottleneck moved. Most organizations haven’t moved with it yet.