Customer shadowing for PMs
Our reviewers evaluate writing services independently. Learn how we stay transparent, our methodology, and tell us about anything we missed.
Customer shadowing is a research practice in which I observe a person doing real work in the context where the product is used. I pay attention to the task, environment, handoffs, tools, interruptions, and workarounds around the visible interface. A conversation can tell me what someone remembers or believes. Observation can show me what the workflow requires when the person is busy and the ideal path is not available.
I treat shadowing as an invitation to learn, not a license to watch without boundaries. I explain what I want to understand, obtain appropriate consent, protect sensitive information, and give the participant control over what I can see. The purpose is to improve a product decision, not to judge how someone works.
Define the learning question
I begin with a question that can be answered partly through observation. “Understand the customer” is too broad. “How does a support lead decide that an issue is ready to escalate?” gives me a situation, actors, tools, and a decision to explore. “Where do new administrators lose confidence during setup?” points me toward a journey and the moments around it.
I write down what I already believe and what would challenge that belief. I also state what shadowing cannot answer. Observing a workflow may reveal friction and adaptations, but it may not establish how common the behavior is, whether a new concept would be adopted, or what an entire market wants. Those questions may need interviews, data, experiments, or additional research.
I select participants for relevance to the question rather than convenience alone. I want enough variation in role, experience, environment, and workflow to notice meaningful differences. I do not need to force every possible segment into one study, but I record who I observed so I do not generalize beyond the evidence.
Prepare the conditions for honest observation
I explain the session in plain language: what I will observe, how long it should take, what may be recorded, who will see the notes, and how the participant can pause or skip something. If screens, customer records, financial data, or health information could appear, I agree on a safe process before the session begins. Sometimes the right choice is a redacted account, a simulated task, or no recording.
I ask the participant to work as normally as practical. I do not request a polished demonstration that removes the interruptions and workarounds I need to understand. At the same time, I avoid creating pressure by staring silently or taking over the workflow. I explain that I am evaluating the product and process, not the person.
I prepare a lightweight guide with the task context, prompts, and topics to notice. The guide is a guardrail, not a script. I leave room for unexpected events because the unexpected handoff or improvised spreadsheet may be the part that changes my understanding.
Observe the work around the screen
I record the sequence of actions, decisions, inputs, outputs, and handoffs. I note what triggers the work and what tells the person it is complete. I look for moments when they switch tools, ask a colleague, copy information, delay a task, or create a personal reminder. These behaviors are clues about the surrounding system.
I separate observation from interpretation. “The participant opened a spreadsheet after reviewing the dashboard” is an observation. “The dashboard is not trusted” is a hypothesis that may explain it. I ask a short, neutral question at a suitable pause: “What were you checking there?” or “What would you normally do next?” I avoid suggesting the answer I want.
I notice language. The participant’s words for a status, customer, object, or goal may differ from the product’s labels. I capture the phrase in context and ask what it means to them. I also note where the product’s workflow conflicts with a team policy, permission model, or physical environment. A usability issue may actually be an organizational or operational constraint.
Handle the researcher effect and sensitive moments
My presence changes the session. I can reduce that effect by building rapport, avoiding judgment, and spending enough time on the context for the interaction to become ordinary. I do not pretend that observation is invisible. I name the possibility and interpret the evidence modestly.
I protect the participant when a mistake, customer record, or internal disagreement appears. I do not capture more information than the research question requires. I remove identifying details from notes where possible and store materials according to the agreed process. If the session reveals a safety, privacy, or compliance concern, I follow the appropriate escalation path rather than turning it into a product anecdote.
I ask permission before taking a screenshot, recording a voice, or inviting another observer. A participant should not have to trade control of their work for access to a product improvement conversation.
Synthesize patterns without flattening context
After the session, I rewrite notes while details are fresh and label direct observations, participant explanations, my interpretation, and follow-up questions. I map the workflow from trigger to outcome and mark dependencies that the product interface does not show. A customer journey map for product managers helps me represent the handoffs and moments of uncertainty rather than reducing the session to a list of feature requests.
I compare sessions for recurring patterns and important differences. I do not count every mention as a vote. A repeated workaround may indicate a problem, but I still ask who experiences it, in which context, and with what consequence. A single unusual observation can matter if it exposes a serious risk, but it should not automatically become a universal claim.
I turn findings into decisions and questions. Some deserve a product change, some a service or process change, some more research, and some an explicit decision not to act. I preserve the evidence trail so the team can understand how we reached the conclusion.
My bottom line
I use customer shadowing to see the product inside the customer’s real system of work. The practice is strongest when the question is focused, consent is meaningful, observation is careful, and interpretation stays honest about its limits. I am not looking for a dramatic quote or a perfect workflow. I am looking for context that improves what we decide to build, explain, or change.
Next step
For a structured foundation in customer discovery and product decisions, I use the Product Manager Certification, a commercial Product HQ resource. The Product HQ newsletter shares practical product lessons and frameworks.
