Essay · UX Research · AI & Product Development · May 2026

How AI Is Reshaping Product Development —
And the Role of Research

AI products don't just get informed by people — they learn from them. When the development process changes, every role around it changes. Research included. The role doesn't shrink. It becomes more integral than before.

By Manisha Dewal  ·  May 2026

"Will AI replace researchers?" is the wrong question.

I understand the concern. For years, research earned its keep by helping teams avoid expensive mistakes: study people first, build the right thing, don't waste months. Now AI is collapsing the cost of building, and "avoid the expensive mistake" stops sounding like reason enough to research first.

But here's what that read misses. AI products don't just get informed by people — they learn from them. Human behavior, preferences, and judgment are no longer just inputs to the design; they're shaping what the system becomes. Understanding people and influencing the technology have become part of the product itself.

AI products don't just get informed by people — they learn from them.

So the question isn't whether AI can replace researchers because it can do the analysis faster. The more interesting shift is that AI is changing how products are built — and when the development process changes, every role around it changes, research included. As people-understanding becomes part of the system itself, the role doesn't get smaller. It becomes a more integral part of execution than before.

The Structural Change

A new loop got added to the SDLC.

For most software products, the lifecycle looked roughly like this:

The Familiar Lifecycle

🔎Research
📋Requirements
✏️Design
🛠️Build
QA
🚀Launch
🔁Iterate

Traditional software translates human-written requirements into deterministic systems: you specify the behavior, the code executes it, and it does the same thing every time.

AI products behave differently. Their behavior is probabilistic and learned — shaped by data (human understanding) and refined continuously rather than written once. That adds a new loop inside the familiar lifecycle: collect data, train, evaluate, deploy, monitor, retrain — and around again.

Diagram showing the traditional product lifecycle with a new behavior loop nested inside it, fed by human signal.

The product lifecycle stays the same shape. What's new is the loop running inside it — and the human signal that feeds it.

The Shift

So behavior becomes the product.

Here's the part that reorganizes everyone's job. In traditional software, behavior is programmed — written explicitly into the code. In AI systems, behavior is shaped — it emerges from data, training, and the signals we reinforce.

That turns design decisions into a different kind of question:

None of these questions are purely technical.

  • Which examples should we train on?
  • Which responses should be rewarded, and which discouraged?
  • What counts as a successful interaction?
  • Which failures matter most?
  • What tradeoffs are acceptable?

They're questions about people — about language, intent, context, and what "good" means to a real human in a real situation.

And this is where the roles shift. In traditional development, the people who understand humans — researchers, designers, content folks — informed the build and then handed off. Their work shaped the spec; the spec shaped the product. They sat next to execution, not inside it.

The behavior loop changes that. Because the system learns from human signal, those human judgments are the inputs to what it becomes: which examples it sees, which responses get reinforced, what we measure when we ask "is this good?" The work that used to be advisory is now load-bearing.

"Understanding people stopped being the thing you do before execution. It became part of execution."

That's why it now shows up at every stage — not just the bookends.

Diagram comparing traditional product development, where research sits at the edges, to AI development, where human understanding runs through pre-training, training and post-training, and deployment.

Pre-training: understanding language, behavior, diversity, edge cases. Training & post-training: defining preferences, quality signals, desirable and undesirable behavior. Deployment: understanding trust, adoption, workflow integration, failure recovery.

The Overlap

The boundaries are blurring everywhere you look.

This is one of the most interesting shifts I've seen up close — the old division of labor is dissolving. It used to be clean: researchers studied humans, engineers built systems.

Today, engineers increasingly have to reason about trust, ambiguity, social norms, and how people make decisions. Researchers increasingly have to reason about models, evaluations, training data, and failure modes. Neither discipline can operate cleanly in isolation anymore.

The interesting work is happening in the overlap — and the overlap is getting wider.

Not The Same Thing

And no — AI evaluations are not UX research.

If research is now woven into how models get built, it's tempting to assume the evals teams have it covered. They don't — because evals answer a different question.

AI Evaluations Ask

Is it correct? Is it safe? Is it robust? Increasingly they fold in human judgment too — preference ratings, helpfulness scores — so the line isn't simply technical versus human.

UX Research Asks

Is it understandable? Is it useful? Does it fit the way people actually work? Does it change what they do? That's the product meeting a real life — not an output meeting a rubric.

Even the most human-informed eval is still scoring outputs against criteria we defined. UX research asks something different.

One doesn't replace the other

QA never eliminated the need for UX research. AI evaluations won't either. They become research's closest partner — the richest place for research to sit is right next to evals: helping decide what they should measure in the first place, turning the fuzzy realities of how people work into the criteria and test sets evals run against.

Understanding humans is moving closer to the center of how technology gets built.

And honestly, we're at the very beginning of this. Most of today's conversation assumes "AI interaction" means typing into a chat box. That's a snapshot, not the destination. The systems coming next are increasingly multimodal, contextual, and agentic — they'll see, hear, act, and coordinate in ways that feel much closer to natural human interaction. As that happens, questions of trust, autonomy, feedback, and human behavior don't get smaller. They get bigger.

This is the part that excites me the most, and I'll admit it's personal. I started in engineering before I moved into research, and I've spent the years since on emerging technologies — voice and gesture interfaces, virtual worlds, spatial computing, and now AI systems. For most of that time, the engineering instinct and the research instinct sat in different parts of my work. Now they're converging into the same job — and that convergence is exactly why the work gets larger, not smaller.

For a field that spent years fighting for a seat at the table, that's not a threat to the discipline. It's the biggest opening it's ever had.