Faster output isn’t the same as better outcomes

For decades, engineering capacity imposed a useful kind of discipline on product organizations.

There were always more ideas than developers available to build them. Roadmaps filled up. Backlogs became archaeological sites where feature requests went to wait indefinitely.

Product teams had to make choices because they couldn’t make everything.

AI coding tools have loosened that constraint.

That sounds like unequivocally good news until you consider what happens next.

Rich draws an important distinction between engineering waste and product waste. Engineering waste happens when a team builds something badly: It’s late, insecure, technically flawed or simply doesn’t work.

Product waste is more painful.

“Product waste is when we build something really, really solid that the world doesn’t want and users don’t care about, and nobody adopts and nobody pays for,” he said.

AI can help reduce some engineering waste.

It can’t eliminate product waste. Rather, without strong product management and customer discovery, it seems to be multiplying it.

That changes the fundamental question surrounding AI-powered product development. The metric that matters isn’t how much more software you can produce. It’s whether your organization can learn what customers need (and will pay for) as quickly as it can build.

10X the code doesn’t mean 10X the revenue

Here’s a useful thought experiment.

Suppose your engineering organization becomes 10 times faster tomorrow.

Congratulations.

Did your market become 10 times larger overnight?

Did your customers receive 10 times the budget? Do they suddenly have 10 times more attention to devote to learning your product? Can your sales team close deals 10 times faster?

Probably not.

Rich captured the problem neatly: “10x the coding speed doesn’t mean 10x the revenue.”

Take enterprise manufacturing software. AI might enable a wave of startups to build competing products much faster. But there aren’t suddenly more manufacturers with more money waiting to buy them.

The bottleneck simply moves.

“How fast can I convince big companies to abandon the thing they’ve been using for years and sign a new contract with us?” Rich asked. “Which is not an AI coding problem. It’s a sales and marketing problem.”

And with so many new entrants, it quickly becomes a race to the bottom in terms of pricing as competitors try anything to sign new customers. 

There’s another constraint companies don’t control: human attention.

Imagine shipping 50 new features every week. Technically impressive.

But who is going to understand them all, much less adopt them?

Software development can accelerate dramatically. Human attention cannot.

That’s why product development velocity can be such a deceptive metric. The meaningful unit isn’t features shipped.

It’s customer value created, Rich says.

When building gets cheaper, discovery should move left

There’s a counterintuitive implication here.

As building becomes faster, product teams should spend more energy understanding what to build not less.

Shift left.

Put concepts and prototypes in front of customers while they’re still cheap to change. Test assumptions before they harden into roadmap commitments. Bring customer evidence into prioritization before someone spends three months (or now, perhaps three days) building something.

Customer learning shouldn’t be confined to a research phase but incorporated throughout product development through continuous discovery.

The answer isn’t to slow engineering back down.

It’s to make learning faster.

Think of AI as widening the highway. That’s valuable. But the faster traffic moves, the more important it becomes to know whether you’re headed in the right direction.

Synthetic users tell you what you already know

Of course, if customer research is now a bottleneck, there’s an obvious AI answer for that, too.

Synthetic users or simulated users.

The appeal is understandable. Recruiting customers takes time. Scheduling interviews takes time. Real humans ramble, contradict themselves, misunderstand questions and occasionally tell you things that make absolutely no sense.

Synthetic users are wonderfully cooperative.

And that’s the problem, Rich said.

Rich worries that teams may use synthetic users to reinforce assumptions rather than challenge them.

“We’re really building our own biases into our synthetic users,” he said.

There’s also what Rich calls the difference between being correct and being plausible.

Synthetic feedback can sound excellent. It’s articulate. Grammatically clean. Thoughtful.

But plausible isn’t necessarily true.

The most valuable part of customer discovery is often precisely the opposite: the weird answer. The comment you didn’t expect. The moment that makes a researcher abandon the discussion guide and ask a follow-up question.

“The thing that’s really most valuable about discovery for me is hearing something I didn’t know,” Rich said.

Maybe a customer mentions they never run your reports on Tuesdays.

Wait.

Why Tuesdays?

A good researcher follows that thread. Pulls on it. Maybe it leads nowhere. Or maybe it exposes a workflow, constraint or unmet need nobody on the product team knew existed.

“There’s gold,” Rich said of those moments.

Research from User Interviews reflects that caution. Its State of Synthetic Users report examines where researchers see potential in synthetic users while also exploring concerns about the reliability and quality of AI-generated research participants.

A useful rule of thumb: Use AI to accelerate research. Be careful about using AI to replace the people you’re researching.

Those are very different things.

AI product management still needs human judgment

The enthusiasm around AI product management has also produced a new organizational ideal: the full-stack builder or “product engineer.”

The pitch goes something like this.

AI lets engineers design. Designers can create working prototypes. Product managers can generate code. Why maintain all those specialized roles when one talented person armed with enough AI agents can do everything?

Rich doesn’t buy it.

He doesn’t dispute that exceptional people can span disciplines. His objection is assuming those people are common or that the skills themselves become unnecessary because job descriptions change.

Engineering requires technical judgment.

Product management requires market and economic judgment.

UX research requires curiosity, empathy and methodological skill.

Design requires craft and taste.

AI can amplify those skills. It doesn’t automatically give them to you.

As Rich put it, “I’m not ready to outsource fun yet, in the same way I’m not ready to outsource usability.”

That may be one of the more important lessons for generative AI and product development.

Something can look plausible without being good.

It can work without being useful.

It can ship without being wanted.

The product manager becomes a barbell

So where does this leave product teams?

Rich offers a useful model: the barbell-shaped product manager.

Historically, he argues, product managers spent much of their time in the middle of the product development lifecycle: working with engineering, writing requirements, prioritizing features and helping scarce development resources get software out the door.

AI squeezes that middle.

The opportunity is to push more human effort toward the two ends of the barbell.

On one side: discovery.

What problem are we solving? For whom? Does it matter? What have customers tried before? What evidence do we have that they’ll adopt or pay for our solution?

On the other: go to market.

How will we position it? How will we package and price it? Why will somebody switch? How does it generate revenue?

Those are the things that “turn code into money,” as Rich described it.

And that phrase gets to another important part of his argument.

Product teams love talking about their processes. Backlogs. Frameworks. Roadmaps. Prioritization models.

Executives usually have another question.

What is this worth?

Rich explores that disconnect in his new book Money Stories, arguing that product teams need to translate customer problems and product decisions into the economic language the rest of the business understands.

That doesn’t mean abandoning customer-centered thinking for spreadsheets.

Quite the opposite.

It means connecting the chain: customer problem → product decision → customer value → business outcome.

UserTesting’s product management resources similarly emphasize bringing customer feedback into decisions about what to build, improve and prioritize.

Build less. Learn faster.

There’s an irony at the center of all this.

AI gives product organizations the ability to build more than ever before.

But the smartest ones may respond by becoming more selective about what they build.

Use AI coding tools. Prototype faster. Fix obvious bugs faster. Automate repetitive work. Let technology give product teams new superpowers.

But don’t confuse the ability to create something with evidence that it deserves to exist.

Rich’s advice: Talk to customers early. Test prototypes before polishing them. Look for the awkward answer you weren’t expecting. Connect product decisions to adoption, retention and revenue not simply output.

Most importantly, preserve the human judgment necessary to ask the irritating question that sits upstream of all that glorious AI-powered productivity:

Should we build this at all?

Because once the cost of building collapses, judgment becomes the scarce resource.

And speed only creates value when it’s pointed in the right direction.

“No matter how fast I build a product, if the world doesn’t want it and doesn’t pay for it and doesn’t need it, then we wasted all that resource and that energy and that time and that love,” Rich said. 

Additional resources

• Webinar: The AI-native product loop: build, test, learn—without slowing down. This on-demand webinar offers a practical look at integrating real customer feedback into AI-speed product development so teams can validate continuously rather than allowing building speed to outpace learning.
• Guide: Human insight for the AI-driven product development process. Particularly relevant to Rich’s argument that engineering is becoming less of a bottleneck. The guide explores how discovery, evaluation, and customer feedback need to evolve as AI makes software development faster and cheaper.
• Podcast: Stop staying in your lane: How AI is reshaping product teams. An Insights Unlocked conversation about AI blurring the boundaries between product, design, engineering, and research while making judgment, taste, accountability, and customer understanding more important. It pairs especially well with Rich’s critique of the “product engineer” model.
• Blog post: AI-powered product research: Why the fastest builders need to become the fastest learners. Builds directly on one of the strongest ideas from the interview: as AI makes building dramatically cheaper and faster, learning what customers actually need becomes the new bottleneck.

Frequently asked questions (FAQs)