Protecting engineers from user conversations to preserve focus produces worse products.
How to Run Research as a Team Without It Dying in a Handoff
Continuous discovery only works if the people who build the product hear users directly. A PM relay is not a substitute for that - it produces teams that have been told conclusions rather than teams that understand context.
The Relay That Looks Like Research
A product team runs eight user interviews over three weeks. The PM takes notes, tags themes, and presents a synthesis doc at the next sprint planning session. The deck is clean. The findings are organized into three buckets. The team nods and moves to prioritization.
Nobody asks what the user's voice sounded like when they described the workaround they had been living with for two years. Nobody heard the pause before they said the current tool "mostly works." Nobody knows whether the frustration was sharp or resigned, because neither of those things survives transcription into a bullet point.
This is not a research failure. The PM did the job correctly. It is a structural failure - the team was handed conclusions when what they needed was exposure.
What Actually Gets Lost in the Handoff
Everyone says their team is user-focused. Most teams have one person who talks to users while the rest of the team reads about it later.
The gap is not about access to information. Synthesis documents can be thorough. The gap is about what information does to a person who was present versus what it does to a person who read about it.
When a researcher describes that a user "struggled with onboarding," the engineering team receives a claim. When an engineer watches a user close the product three minutes into setup and say "I will figure this out later," the engineer has an experience. Those two things produce different decisions.
The Texture Problem
Research that travels through a single interpreter loses texture before it arrives. Texture is not color commentary - it is the signal layer that tells you whether a problem is a surface complaint or a structural one.
A user who says "the search does not work well" while shrugging is telling you something different from a user who says the same thing while pulling up a spreadsheet they built to work around it. The shrug and the spreadsheet are both gone by the time the synthesis doc is written. The PM chose which story to tell, and the team received the PM's version of the user's reality.
This is not a criticism of PMs. It is a description of what relay structures do to signal fidelity.
PM-Only Research vs. Cross-Functional Discovery
| Dimension | PM-Only Research | Cross-Functional Discovery |
|---|---|---|
| Who is present | PM (and sometimes a researcher) | PM plus a rotating engineer or designer |
| What the team receives | A synthesized readout | Shared firsthand experience |
| Signal fidelity | Filtered through one interpreter | Multiple interpreters present simultaneously |
| Engineer relationship to findings | Conclusions to accept or contest | Context to reason from |
| Debate pattern after readout | "Did the PM interpret this correctly?" | "Here is what I noticed in that session" |
| Velocity of conviction | Slower - requires trust in the PM's read | Faster - team members have direct reference points |
| Risk | PM becomes the single point of failure for user understanding | Coordination cost of rotating schedules |
| What it optimizes for | PM efficiency | Team understanding |
The comparison is not clean. Cross-functional discovery requires more scheduling overhead. Engineers have to protect time that is already contested. The cost is real. The question is whether the team's current research setup is solving for PM efficiency or for product quality - and whether those two things are in tension here.
The Rotating-Engineer Model
Some cross-functional product teams have adopted a practice where engineers participate in user research sessions on a periodic rotation - not every session, but often enough that, over a quarter, most engineers on the team have been in at least one live conversation with a user.
The session structure does not change when an engineer is present. There is no modified version of the questions, no debrief deck prepared specifically for the engineering audience. The engineer sits in the same session the PM would have run alone. The outputs - notes, recordings - are not written up differently.
What changes is who has a reference point. When a PM says "users are confused by the permission model," an engineer who was in a session can say "yes, I watched that happen - the user kept clicking the same dropdown twice because she expected it to behave like the one in settings." That is a different conversation than one where the engineer is deciding whether to believe the PM's claim.
The rotation also changes what engineers ask the PM between sessions. When engineers know they will eventually be in a session, they start thinking about what they want to understand before the next one. The questions that come back to the PM are sharper, because the engineer is preparing to see something - not waiting to be told something.
The Judgment Turn
Protecting engineers from user conversations to preserve their focus is a management choice that produces worse products.
The argument for keeping engineers out of research is a focus argument: context-switching is expensive, research is the PM's domain, and engineers should be shipping. This is a reasonable-sounding argument that confuses efficiency with effectiveness.
A team of engineers who are isolated from user reality is a team that builds to specification rather than builds to understanding. The difference shows up at the edges - in the decisions that do not appear in any requirement, in the places where the spec ran out and the engineer had to guess. An engineer who has heard a user explain their actual workflow guesses differently than one who has only read about it.
The uncomfortable position is this: when research is a PM-owned function that produces a readout, the team has been organized to minimize the PM's interpretation bottleneck - and the result is a team that debates the PM's conclusions rather than the user's words. The team's collective model of the user is only as accurate as the PM's synthesis, and that model degrades with every handoff.
This does not mean engineers should run research. It means engineers should be present in research - periodically, not constantly. There is a difference between owning the function and having access to the raw material.
How to Introduce Rotating Participation in a Team That Has Never Done It
The failure mode when introducing this is overengineering the entry point. Teams that have never had engineers in research sessions tend to design elaborate programs with pre-session briefs and post-session retrospectives, and then the overhead kills the practice before it builds momentum.
Start with one session, no briefing
Pick one upcoming user interview. Invite one engineer - ideally someone who has been asking good questions about user behavior recently, because they are already primed. Do not brief them extensively. Tell them: "You are here to listen and to ask one question at the end if something stood out to you."
The first session is not about the engineer contributing. It is about the engineer being present. The contribution comes later, when they reference what they heard.
Protect the session structure
The researcher or PM still runs the session. The engineer does not become a second interviewer. One question at the end is a ceiling, not a floor. The moment the engineer starts driving the conversation, the session becomes about what the engineer is curious about rather than what the research plan requires.
This is a boundary worth holding explicitly, because engineers who are curious - the ones you want in the room - will have opinions about what to ask next.
Establish the rotation cadence before it is needed
If you announce rotation as a response to a specific research finding, it reads as a reaction. If you establish it as a standing practice - rotating on a predictable schedule - it becomes part of how the team runs. The model works because it is not optional or situational. It is the default.
Set the rotation calendar before you run the first session. Even if the first three rotations are placebo - even if the research findings from those sessions do not drive any immediate decisions - the cadence builds the habit. The value compounds.
Read the room after the first session
The session is done. Ask the engineer one question: "What did you notice that you would not have noticed from a written summary?" That question is diagnostic. If the engineer has an answer - a specific observation, a contradiction they saw that the PM would not have flagged - the rotation is working. If the engineer shrugs, either the session design was wrong or the engineer was not the right starting point.
Do not interpret a bad first session as evidence that the model does not work. Interpret it as data about where to adjust.
Key Takeaways
- Research that travels through a single interpreter loses the texture that changes how engineers make decisions - a synthesis document carries conclusions, not context.
- The goal of rotating engineers into research sessions is not to make engineers better researchers; it is to give the team shared reference points instead of a shared summary.
- A rotation model works because it is structural and non-negotiable - engineers are present for real conversations on a predictable cadence, not in modified or specially prepared sessions.
- Protecting engineers from user research to preserve focus is a tradeoff that optimizes for engineering throughput at the cost of product accuracy.
- The signal that your research process has a handoff problem is not that engineers disagree with findings - it is that engineers debate the PM's interpretation rather than the user's words.
Related Articles
What is the primary failure mode of PM-only research according to this article?
Make the call in Reps and see how your reasoning holds up.
Make the call