Triangulating Multi-Role Perspectives: Compare How Executives, Architects and Operators Describe One Problem

Ask a CIO about a workflow problem and you hear about cost and risk. Ask the architect and you hear about coupling and data flow. Ask the person who runs the process every day and you hear about the twelve manual steps nobody else mentions. Each account is true, and none is complete. A Solution Engineer who designs from only one of them builds a solution for a problem that does not quite exist.

This article covers an atomic discovery skill from the SE Ignite catalog: comparing how executives, architects and daily operators describe the same workflow problem, and using the differences to find the real requirement.

The problem this solves

• Problem: discovery captures one role’s version of the problem, usually whoever was on the first call. The proposal then fails a different role’s test later: the operator rejects it in the pilot, or the executive cannot see the value.
• Reader: Solution Engineers and presales consultants leading discovery across several stakeholders.
• Stage: discovery and qualification, before solution design.
• Decision it supports: which version of the problem the solution must address first, and which stakeholder needs to validate it.
• Success test: you can write one problem statement that each role reads and says “yes, that is it”, and you can name where their accounts disagree.

A four-step method

1. Ask the same core question in each conversation. For example: “Walk me through what happens when this process goes wrong.” Use the same wording so the answers are comparable.
2. Record each answer in a three-column grid. Columns for executive, architect and operator; rows for symptom, cause, impact, frequency and current workaround.
3. Mark the gaps and contradictions. A cell that is empty for one role, or a cause that two roles describe differently, is a discovery lead, not a data quality problem.
4. Close the gaps with a follow-up. Take the operator’s detail back to the architect (“Your team mentioned a manual re-run every Monday. How does that fit the design?”) and the architect’s constraint back to the executive in business terms.

What the differences usually mean

• The executive describes impact the operator never mentions: the pain is real at the top but may be normalised on the floor. Measure it before relying on it, using baseline performance metrics.
• The operator describes steps the architect does not know about: you have probably found unofficial tooling. See uncovering unofficial tool dependencies.
• The architect names a cause the executive does not accept: there is a political disagreement about priorities. Note it for influence mapping before you take sides.
• All three agree completely: either the problem is genuinely well understood, or you heard one rehearsed story three times. A short pause after each answer, as described in pausing for stakeholder elaboration, helps tell the two apart.

Adapting it to the situation

• A guarded engineering executive on a first call: ask for permission to speak with one architect and one operator. Frame it as protecting their time from a solution that misses the detail.
• An executive briefing focused on consolidation and total cost: bring the operator’s view in as evidence, not opinion, so the cost discussion rests on how work actually gets done.
• A competitive displacement against an entrenched incumbent: operators often have the most specific complaints about the incumbent, and executives the strongest loyalty to the original decision. Map both before you position.
• A merger or acquisition: triangulate across both organisations as well as across roles. The same job title often means different work in each company.
• Multi-region rollouts: treat regional operators as separate voices. A process that works in one region can fail in another on an older version.

Common mistakes

• Averaging the answers. The value is in the differences. Do not blend them into one vague statement too early.
• Treating the most senior voice as the truth. Seniority decides budget, not facts about the workflow.
• Exposing a contradiction publicly. Bring disagreements back carefully and privately where possible, so no stakeholder feels contradicted in front of peers.

Where this skill sits

Triangulation builds on current-state workflow mapping and gives you the agreed problem statement you need before quantifying impact with the cost of inaction. Later, the same grid becomes the backbone of persona-specific demo narratives.

Practising the 80%

Comparing stakeholder perspectives works the same way whatever you sell. It belongs to the vendor-neutral 80% of Solution Engineering that SE Ignite teaches. Practise it by running the same discovery question with three different simulated personas and comparing your grids. The SE Ignite curriculum is free to use.