Customer Discovery for Product Engineers: A Lightweight Workflow
A practical customer discovery workflow for product engineers: choose a decision, ask about recent behavior, separate evidence from assumptions, and test the smallest useful change.
Share
Product engineers need customer evidence as much as they need a clean implementation
When a team can ship a prototype in an afternoon, the scarce resource is often no longer code. It is confidence that the problem matters, that the proposed change fits the user's workflow, and that the team will know whether it helped.
Customer discovery is the work of learning about a user's problem and context before making a product decision. It does not mean that engineers must become full-time researchers or wait for a long study before shipping. A small, repeatable discovery loop can fit around a sprint and help a team avoid polishing a solution to the wrong problem.
The goal is not to collect opinions. It is to gather enough evidence to make one specific decision better.
1. Start with a decision you might change
Before scheduling interviews, write down the decision the team is trying to make. For example:
Should we build a bulk edit flow for this workflow?
Which step in onboarding should we simplify first?
Is this request caused by missing functionality or by confusing setup?
Should this be a product feature, a support workflow, or a one-off service?
A useful discovery question has a possible answer that would change what the team builds, measures, or deliberately leaves out. If every answer leads to the same implementation, the research question is too broad.
Write the current assumption beside the decision. Keep it plain: “We believe small support teams lose time because they copy customer context between tools.” This makes it possible to test the assumption instead of asking users to endorse the proposed feature.
2. Choose a narrow group and a recent situation
“Users” is usually too broad for a useful first conversation. Pick people who share a relevant role, workflow, or constraint. Then ask about a recent occurrence of the problem, rather than a hypothetical future.
S
Specky Team
Writing about AI-native product development at Specky.
A handful of conversations can reveal confusing language, missing steps, and plausible causes. They do not prove how common a problem is across a market. Treat a small sample as formative evidence: useful for finding what to test next, not as a statistical estimate.
For each conversation, note why this person belongs in the group. If the people have very different jobs or use cases, keep their evidence separate instead of averaging it into one fictional user.
3. Ask about what happened, not what they might do
People are usually trying to be helpful when they answer hypothetical questions. That kindness can make a weak idea sound stronger than it is. Ask for a specific past event and let the person describe the sequence.
Try questions like:
“Walk me through the last time you needed to do this.”
“What started the task, and what did you do next?”
“Where did you get stuck or switch tools?”
“What workaround did you use?”
“What happened because it took longer or did not work?”
“Have you tried to solve it another way? What happened?”
“Who else was involved in the decision?”
Avoid leading with “Would you use a feature that…” or “Do you like this prototype?” If you show a prototype, first learn the current workflow. Then ask the person to try a realistic task while you watch where they hesitate, what they ignore, and what they expect to happen.
4. Keep observations separate from interpretation
After the conversation, write down three different things:
Record
Example
Observation
The engineer copied an account ID from the ticket into a second tool before reproducing the issue.
Interpretation
The handoff may be losing context between support and engineering.
Open question
Does this happen often enough to justify a shared context panel?
This separation matters. “Users need a dashboard” is a proposed solution, not an observation. Preserve the person's actual words when they are useful, and link each conclusion back to the note, call, ticket, or artifact that supports it.
Do not turn one vivid interview into a roadmap commitment. Look for repeated patterns across the relevant group, and keep counterexamples visible. If the evidence is mixed, that is a reason to run a smaller test, not to hide uncertainty.
5. Test the smallest change that can teach you something
The first test does not always need production code. Depending on the risk, the team might:
change a label or default and watch task completion;
manually perform a step for a few users before automating it;
show a clickable prototype in a realistic scenario;
add a clearly described early-access flow;
instrument an existing workflow to find where users stop.
Be honest about what the test does. A mock screen can test whether a workflow makes sense; it cannot prove that the underlying service is reliable. A signup is evidence of interest, not proof of repeated value. Choose a test that matches the uncertainty you are trying to reduce.
Before running it, name one outcome and one guardrail. For example, “More invited users complete setup” is an outcome; “support requests do not increase” can be a guardrail. The exact measure depends on the product and should be defined before looking at results.
6. Turn the learning into a buildable issue
A useful discovery handoff gives engineering enough context to make a good implementation decision without pretending every question has already been answered. Include:
User and situation: who encounters the problem and when.
Evidence: what they did, said, or tried, with links to the source.
Problem statement: the obstacle in the user's workflow, without prescribing the UI.
Desired outcome: what should become easier or safer.
Non-goals: what this change will not attempt to solve.
Acceptance criteria: observable behavior that can be checked.
Open questions: uncertainties that could affect scope.
Success measure and guardrail: what the team will inspect after shipping.
This can be a short issue for a reversible change or a fuller product requirements document when the work has more dependencies, risk, or coordination.
7. Use AI to organize evidence, not invent it
AI tools can help group interview notes, find repeated phrases, draft a first summary, or turn a verified problem statement into acceptance-criteria options. Keep the source material attached. Review every claimed pattern against the original notes, and correct summaries that blend different people or imply certainty that the interviews did not provide.
Do not ask a model to fabricate customer quotes, fill gaps with a plausible persona, or decide which segment matters. The team remains responsible for the product judgment. A generated summary is a navigation aid, not new evidence.
A 30-minute weekly discovery loop
For a small product engineering team, a lightweight cadence can look like this:
Five minutes: choose one decision and state the current assumption.
Ten minutes: review one or two recent customer conversations, tickets, or session recordings.
Ten minutes: separate observations, interpretations, and open questions.
Five minutes: choose the smallest next test and assign an owner.
If the evidence does not support a change, record that too. “We checked and do not yet know” is more useful than quietly turning a guess into scope.
Good product discovery for engineers does not slow down delivery. It helps the team spend its speed on problems users actually have. For a broader view of the role and the evidence-to-spec workflow, see product management for product engineers.