23 July 2026 · Philipp John
Stakeholder mapping for B2B product discovery
Map stakeholders before the first interview, so the people who use the product but did not write the brief are heard. An example from a B2B planning platform.
In B2B products the people who write the brief are often not the people who use the product. Map stakeholders before the first interview, so users with no say in the brief are still in your sample. Then turn what you learn into testable hypotheses and test the riskiest one first.
This is how I approach discovery for B2B and SaaS products.
Why does B2B discovery need a stakeholder map?
In a B2C app you can often reach users directly. In a B2B platform the picture is more complex. There are buyers, managers, product owners, engineers and the people who work with the tool every day. Each group wants something different, and the loudest one is not always the most affected.
A stakeholder map shows who decides, who uses, who is affected and who has influence. It makes missing voices visible before you plan the interviews.
What did this look like at Bosch Security?
At Bosch Security I designed an in-house platform to plan surveillance installations from end to end. Before the first interview I mapped stakeholders. That is how field technicians, who had no say in the brief, ended up in the sample.
The research then led to one key finding, which became a hypothesis: capacity shown as a live traffic light. It was the riskiest assumption, because it could have invalidated the whole direction. So we tested it first.
You can read the full project in the Bosch Security Planning case study.
How do you run it step by step?
- Map the stakeholders. List groups and people. Mark who decides, who uses and who is affected.
- Check for missing voices. Ask who is not in the room and who would be hurt by a wrong decision.
- Interview across the map. Talk to users and stakeholders, on site where possible.
- Turn findings into hypotheses. Each one needs a signal that can prove it wrong.
- Test the riskiest one first. If it fails, you save the most time.
- Test with working prototypes. At Bosch Security, two field technicians saw prototypes against the live build in five-day cycles and chose between real options.
Where does AI help?
AI can cluster interview notes and find patterns quickly. I still check every pattern myself, because a wrong cluster is easy to believe. The people and the judgement stay human, which is why the first steps of my process are human-led.
Key takeaways
- Map stakeholders before you plan interviews.
- Include users who have no say in the brief.
- Write hypotheses that can be proven wrong, and test the riskiest first.
- Test with working prototypes in short cycles.