AI in product development is blurring the functional lines

For decades, the product development lifecycle came with relatively well-understood boundaries. Designers designed. Engineers built. Researchers studied customers. Product managers coordinated the pieces and made decisions about what should move forward.

AI is making those boundaries considerably more porous.

An engineer can now build a functional prototype rather than waiting for a designer to create a visual representation. A designer can use AI prototyping tools to produce something that behaves much more like a finished product. The artifact that once signaled expertise—the mockup, the prototype, the code—is becoming accessible to almost everyone.

Ranjitha sees people “converging on what those artifacts are that everyone kind of feels like they can participate in designing and building.”

That democratization could be one of AI’s most important contributions to product development. It gives people a common language. Instead of explaining an idea across functional boundaries, teams can increasingly show one another what they mean.

But accessibility should not be confused with mastery.

Jason argued that what continues to distinguish disciplines is “the depth of craft.” An engineer producing a design still needs to understand the customer and the principles behind good design. A designer producing code has to consider scalability, supportability and accountability if that code is ever going to ship.

Creating the artifact is getting easier. Knowing whether the artifact is any good remains difficult.

When everyone can build, craft becomes the differentiator

This is the paradox at the center of the AI product development lifecycle.

AI lowers the floor. It does not necessarily raise the ceiling.

Jason described using AI to generate prototypes and code that have improved his design work. But he also acknowledged that when someone without deep design expertise creates something with these tools, he can often tell. The result may look impressive while still lacking the decisions and details an experienced practitioner would recognize.

The same tension exists in engineering.

Ranjitha noted that code generation is improving rapidly. But software engineering was never merely the act of typing code. It also involves architecture: understanding how components interact, anticipating complexity and designing systems that will survive beyond the demo.

In that sense, AI may not diminish engineering craft. It may push engineers toward its highest-value parts.

“It is making even engineering more of a design practice,” Ranjitha said, because humans can spend more time thinking about how to architect complex systems instead of performing some of the mechanics of coding.

AI can hand more people a paintbrush. It cannot give them an experienced painter’s eye.

Faster product development creates a new bottleneck

For years, product organizations obsessed over execution because execution was expensive.

Engineering capacity was finite. Rework was costly. Building the wrong feature could consume months of effort.

Now imagine that cost falling dramatically.

Nathan posed the logical next question: If execution becomes cheap, does deciding what not to build become the most valuable job?

Ranjitha’s answer points toward the next constraint facing AI product teams: “Decision making is kind of the bottleneck.”

That matters because AI can increase the supply of ideas without increasing customers’ capacity to absorb them.

A company may suddenly be able to produce five experiments where it once could afford one. But customers do not have five times as much attention. They have not acquired five times the patience for new workflows, interfaces and features.

As Jason observed, what hasn’t changed is “consumers’ ability to adopt new technology, new solutions.”

That changes the economics of product development. When building becomes abundant, choosing becomes scarce.

AI prototyping should accelerate learning, not just output

The temptation will be predictable: If we can build more, build more.

That may be precisely the wrong lesson.

Ranjitha offered a more compelling model for product experimentation. Instead of using AI to take every idea to completion, teams could use it to explore more possibilities at lower fidelity.

“You can build things faster. So what?” she asked. “What does that mean in terms of what you should be building and how?”

Imagine a team that once had enough time to develop one prototype before putting it in front of customers. With AI-powered prototyping, that team might create three or four viable approaches.

The goal shouldn't be four times as much output.

It should be four opportunities to learn.

Jason captured the challenge in one question: “Can we get the acceleration of learning as quickly as we’ve seen the acceleration of building?”

That may be the metric that matters most.

Customer feedback becomes more important as AI gets faster

Faster experimentation also creates a danger: confusing the ability to test something with permission to impose it on customers.

Ranjitha described a future of lightweight interventions that allow teams to observe how people incorporate emerging AI experiences into their actual lives and workflows. Instead of relying solely on what customers say they might do, teams can learn from what they actually do.

That could make AI and customer feedback far more continuous.

Jason, however, offered an important caution. Companies need safe environments for experimentation rather than treating their live products—and their customers—as permanent laboratories.

“How do you do that in an environment that’s safe and not disruptive to your consumers?” he asked.

This is where human-centered AI becomes less of a design philosophy and more of an operating discipline.

AI may make experimentation cheaper. Customer trust remains expensive.

AI collaboration requires getting out of your lane

Perhaps the biggest organizational change won't be a new tool at all.

It will be a new definition of ownership.

AI gives designers access to engineering capabilities, engineers access to design capabilities and teams a shared medium for turning ideas into working experiences. Used poorly, those tools could encourage individuals to retreat into AI-assisted silos. Jason noted that many current tools reward individual focus rather than genuine team collaboration.

Used well, the opposite could happen.

Ranjitha believes broader capabilities can create deeper AI collaboration because people gain enough familiarity with neighboring disciplines to communicate more effectively while still respecting expertise.

That requires trust. It also requires abandoning the idea that professional value comes from guarding a particular artifact or task.

The designer’s value was never merely producing the design. The engineer’s value was never merely writing the code. The researcher’s value was never merely conducting the interview.

AI is simply making that distinction harder to ignore.

The last 20% may matter most

There is another reason to be skeptical of effortless productivity.

Jason described using AI to rapidly get prototypes “from 0 to 80% good enough.” Then came the remaining 20%.

It was slower. Harder. More frustrating.

His experience punctures one of the more seductive assumptions surrounding AI for product teams: because AI accelerates one stage of work, it must accelerate all of them.

It doesn't.

“In some cases it might actually slow you down,” Jason said.

Ranjitha has adapted accordingly. For tasks that simply need to get done, she often turns to AI. But when the finished work needs to reach a standard she is genuinely proud of, she becomes involved from the beginning.

That distinction may prove increasingly important as AI-generated output floods workplaces with things that are almost good enough.

The future of AI in product development is therefore unlikely to be a story about eliminating designers, engineers, researchers or product managers. It may instead force organizations to become much clearer about why those people mattered in the first place.

Their value isn't just production.

It is judgment. Taste. Accountability. Curiosity. Customer understanding. Knowing which possibilities deserve another hour of attention—and which should disappear before a customer ever sees them.

AI can make more people capable of building.

The harder challenge is creating teams capable of deciding what deserves to be built.

As Ranjitha put it: “I’d probably stop telling people to stay in their functional lane.”

Additional resources

• The AI-Native Product Loop: Build, Test, Learn Without Slowing Down: This on-demand webinar focuses on how AI-native teams can integrate real customer feedback throughout product development, continuously validate ideas, and keep learning at the same pace they build.
• Human insight for the AI-driven product development process: This guide examines how AI is making software development faster and cheaper, why the traditional product development lifecycle needs to change, and why discovery and customer feedback need to become more continuous as engineering and design accelerate.
• How AI agents are changing the product development lifecycle: This podcast episode explores what happens when AI removes many of the traditional constraints on building software, including why customer discovery becomes more important as teams can create and iterate faster. It also examines how AI is changing product team roles and why human insight remains critical.
• The hidden risk of moving too fast with AI in product design: This blog post addresses one of the strongest ideas from Ranjitha and Jason’s conversation: AI has dramatically accelerated prototyping, synthesis and development, but faster execution doesn't necessarily produce better decisions.

Frequently asked questions (FAQs)