I’ve had the privilege of leading many functions outside of Design, such as Growth and Marketing. A function close to my heart is User Research, which I had the pleasure of leading it during my time at One Medical, Webflow, and Replit. To be completely honest, User Research is one of the most misunderstood functions, but it is mission critical.
In this post, let’s cover the intangibles researchers possess, what hurdles they must get through, and imagine what their way of working can do. With the way of working shifting with AI, I believe this group, with the right investment and conviction, can become emerging leaders in product development.
Researchers have an interesting advantage in this moment. They have been trained to make sense of ambiguity. A good researcher can sit with messy signals, contradictory customer feedback, unclear business goals, and an impatient product team, then still find the thread worth pulling.
This may not sound as important as writing code and shipping features, but this is exactly what becomes important when the cost of coding and shipping reduces. If AI makes it easier to generate interfaces, prototypes, and even production software, the scarce skill becomes deciding which questions are worth asking and which direction is worth pursuing when there are so many directions to go.
Let’s look at a few areas where researchers are advantaged before and during the AI era.
Before there were Forward Deployed Engineers, great researchers were already going to where the work happens. This is where Gemba comes in: the Japanese word for “actual place.” In lean manufacturing, the most valuable ideas for improvement are thought to occur at the genba, where problems are visible. A gemba walk is not just management wandering around and hoping to notice something. It has a clear frequency, goal, and structure. You go to the real environment because the real environment tells the truth.
That is what good research has always done.
Xin Xin, Lead Researcher on my team at One Medical, was forward deployed before Forward Deployed Engineering was popular. When she wasn’t at our office, everyone knew she was onsite at a clinic close to care teams, patients, operators, designers, product managers, and engineers. In healthcare, the product is not only the app. The product is the service, the operational model, the handoff, the policy, the room, the person who picks up the phone, and the software tying it all together.
That kind of environment makes research feel less like an isolated phase and an ecosystem you’re growing; built on relationships. You have to understand the workflow before you can improve the product. This isn’t testing at your desk with your large monitors, but in the environment where it’s trained and used in production. You have to know where behavior is brittle. You have to know what breaks when the interface meets the real world.
This is why researchers can be so valuable in the next era of product development. The work is moving closer to the field again. Teams can prototype faster, but the value of embedding with the problem has remained the same. If anything, it matters more because it is easier than ever to build the wrong thing.
Researchers understand behavior change. That is a much harder skill than asking people what they want. People are not APIs. You cannot send a request for “honest customer need” and expect a clean response. People rationalize, forget, describe the idealized version of themselves. They ask for features that represent pain, not necessarily solutions. Researchers are trained to read the gap.
In product development, this matters because most meaningful product work is behavior change. You are asking someone to trust a new workflow, switch tools, adopt a habit, collaborate differently, pay for something, or stop doing something familiar. Even an internal tool has to win behavior. A dashboard nobody checks is not a product; it is decorative infrastructure.
Before management consulting got its hands on Design Thinking and Design Sprints, researchers were conducting generative research. They were running exercises, interviews, field studies, diary studies, and observations to help teams understand the problem before everyone sprinted toward a solution.
Generative research opens the problem space. It helps teams understand the world before they decide what to build. Evaluative research sharpens the solution space. It helps teams understand whether the thing they made works, where it fails, and what needs to change.
Product teams often want to skip to evaluative work because it feels closer to shipping. “Can you test this prototype?” is a clean request. “Can you help us understand why this problem exists?” is messier. But in the AI era, skipping generative work is even more expensive. You can now generate convincing prototypes from weak assumptions. The prototype looks real enough to create confidence before the team has earned it.
The researcher who builds can connect both modes. They can observe, synthesize, prototype, test, and revise in one learning loop. Instead of handing a deck to a team and hoping the insight survives translation, they can turn the insight into something people can react to.
Example: Experience prototyping at offices
When I was at One Medical, I built prototypes with the research team to run through different experience scenarios. In this case, it was developing a point of view on what the modern office could look like with new technologies.
Mixed methods research combines quantitative data such as numbers, metrics, and trends with qualitative data such as stories, interviews, and observations. That combination matters because most interesting product questions are too complex for one type of evidence.
Quantitative data can show where behavior is happening. Qualitative research can explain why. Operational context can reveal why the “obvious” product fix is not actually feasible. Business context can show which problem is worth solving now.
This is where research starts to blend with product and operations. Great researchers are not religious about method. They use interviews, surveys, diary studies, analytics, concept tests, usability studies, market signals, support tickets, community posts, sales calls, and product telemetry. The point is not the method. The point is finding the clearest signal for the question at hand.
Mixed methods researchers are already system thinkers. Give them the ability to build, and they become even more dangerous in the best way. They can move from signal to artifact without waiting for the entire product machine to spin up around them.
There are a lot of misconceptions about user research. Some of it is due to cross-functional partners not quite understanding the role, and another part is self-inflicted by researchers themselves, similar to other UX functions. Simply put, people want to know how you’re helping with the collective success, not be lectured to.
Fair or not, many researchers are pigeonholed as academics who do not contribute to the product. Meanwhile, product teams can look to research to defend their decisions instead of creating open-ended learning. Research slows teams down when it becomes a checkpoint instead of a learning loop. Research accelerates teams when it helps them make better decisions sooner. The best research does not add ceremony. It removes confusion. The truth is the best researchers are product makers.
Academic rigor has its place, but product research is not a dissertation defense. The goal is not to prove you know the method. The goal is to help a team make a better decision with the evidence available. The best researchers know how to translate rigor into momentum. They can explain what they learned, how confident they are, what they are still uncertain about, and what the team should do next. That is not watered-down research. That is research doing its job inside a product organization.
Being technical does not only mean writing production code. It means understanding systems, constraints, data, workflows, and how software behaves once it leaves the slide deck. Many researchers already think this way. They map complex systems, understand causal relationships, and look for the hidden dependency that explains why behavior is happening.
AI-assisted building gives researchers a new way to express that technical understanding. They can prototype a workflow, query a dataset, build a small analysis tool, or create a concept people can react to. They do not need to become engineers to become more technical. They need to become more fluent in how artifacts are made.
Good research methods matter. It allows the quality of work to flow in, ensuring you don’t bias yourself and get to the actual evidence. However, researchers are perceived as un-opinionated as a result of this; quite the balancing act. Methods don’t replace conviction. This is one of the tensions researchers have to get comfortable with. A method can improve the quality of evidence, but it will not make the decision for you. At some point, product development requires taste, timing, and a point of view.
AI will make this more obvious. Teams will have more data, more transcripts, more synthetic summaries, more dashboards, and more generated prototypes. The limiting factor will not be access to artifacts. The limiting factor will be interpretation.
The researcher who leads in this environment will not be the person who says, “The research says...” as if the research is a separate creature that walked into the room with a roadmap. They will say, “Based on what we know, here is the strongest interpretation. Here is where I have conviction and what we should do.”
If Design blends more to Engineering and Business Teams, Research blends with Product and Operations.
Imagine a researcher who can turn interview findings into a prototype the same day, build a small tool to help the team explore customer feedback, create a coded concept for participants to react to, pull product usage data and qualitative themes into one view, and prototype an operational workflow instead of only a screen.
The Research Builder has a few habits:
They (vibe) code. Researchers do not need to become production engineers, but they do need to get closer to the material. Vibe coding is a useful on-ramp because it lowers the cost of turning an insight into an artifact. A researcher can take a workflow observed and create the concept in the same session is very powerful. Researchers often relied on designers to create the concept test. Now they don’t.
They stay close to the real environment. They do not abstract the work too early. If the problem lives in a clinic, a support queue, a spreadsheet, a construction site, a developer terminal, or a sales call, they go there.
They make artifacts, not just summaries. A deck can be useful, but artifacts travel differently. A prototype, map, benchmark, decision tree, or internal tool can become part of how the team works. The research synthesis is now multi-modal.
They teach people to fish. The best researchers scale research judgment across the team. They help product managers ask better questions, designers test sharper assumptions, and engineers understand the customer context behind the system.
They know when evidence is enough. Not every decision deserves another study. Sometimes the most useful thing a researcher can do is tell the team, “We know enough to move, and here is the risk we are accepting.”
At Atlassian, we have a Research Technology team led by Dave Yeats. They’re exploring what the modern research stack looks like. Camille Basilio and her team are running a forward deployed program with researchers not afraid to build their own concepts. Hira Qarni, a researcher I worked with twice at Webflow and now Atlassian, never shies away from building her own concept.s
My hope is that research does not become more passive in the age of AI but plays an active role in giving direction. We don’t need more prototypes, mockups, and apparent progress. What we need is the craft of research rise and take new form to be the people who help teams find evidence and evaluate it.
There is a lot of valid discussion that in the age of abundance, when everyone can build anything, what to build and what matters is the most crucial question. I can’t think of anyone who can help navigate to the answer better than User Researchers.
The future belongs to the researcher who builds.
The return to craft in AI Design Leadership → My podcast conversation with Allie Vogel