Who participates — and a map almost nobody makes
The composition of the discovery team is not a logistical detail. It's a design decision that determines the quality of what you'll discover. Including the wrong people produces the wrong findings. Excluding the right people produces blind spots you'll pay for later.
Essential participants
| Participant | Why they participate |
|---|---|
| Product or solution team | The people who will be responsible for turning findings into action. They cannot delegate this phase because they need first-hand understanding. A discovery mediated through a summary loses critical nuances. |
| Direct clients or users | The people who live the problem. Not executives who talk about the problem, not managers who report on it. The people whose daily reality is affected. Minimum five different people to avoid sample bias. |
| Stakeholders with direct contact | People who, while they don't live the problem, observe it closely: customer service, support, field sales, operations. They provide complementary perspective based on real contact. |
Who does NOT participate
This is the most important rule and the hardest to enforce: in this phase, no one participates whose only relationship with the problem is organizational or hierarchical.
This means a director who has never spoken with a user doesn't sit in on interviews. A VP who sponsors the project but doesn't know the details of the problem doesn't influence the synthesis. Their participation will come in Phase 2, Solution Phase, where their organizational perspective is valuable. Here, their presence distorts the conversation, introduces authority bias, and frequently shortens interviews because their mere presence changes what people are willing to say.
The Actor Map
There's an exercise that almost no team does and that radically changes the quality of discovery: explicitly mapping all the actors surrounding the problem before starting interviews.
Not just those who live the problem. Everyone who touches it: those who cause it, those who suffer it as an indirect consequence, those who tried to solve it before, those who benefit from it not being solved (yes, they exist), those who will make the final decision about the solution, and those who will implement it. Each of these actors has a distinct and potentially contradictory perspective on the same problem.
The Actor Map is built at the kick-off and answers these questions:
| Question | What it reveals |
|---|---|
| Who lives the problem daily? | The primary informants: the people whose experience is the source of truth. |
| Who decides whether the problem gets solved? | The decision owner. Their success criteria may differ from the user's. Understanding what they consider "resolved" is critical. |
| Who will be affected by the solution? | Indirect actors who can block or boost adoption. A change that solves a problem for some may create another for others. |
| Who has tried to solve this before? | Source of learning about what doesn't work and why. Frequently, also a source of resistance if the new solution implies their attempt was a failure. |
| Who has relevant information we're not seeing? | The team's blind spots. There's almost always someone who knows something crucial and nobody has asked them. |
This map doesn't replace interviews. It enriches them. It ensures you're not only talking to the most obvious actors and that the Problem Statement reflects the real complexity of the human relationships surrounding the problem.
The client doesn't know what they want, but they know what they feel. Don't ask the client what solution they need. Ask them what hurts, what slows them down, what costs them. The solution is your job. The problem is theirs. Respect that division.