Product Discovery
Handle conflicting stakeholder requests transparently
Conflicting stakeholder requests need a visible decision process, not a hidden compromise in the backlog. Compare underlying needs, expose non-negotiable constraints, and document who accepts the tradeoff before implementation begins.
Sales may request immediate activation while operations requests a review before any work starts. Both positions can be reasonable within their local goals. The product team should not silently average them into an unclear requirement. Make the conflict visible and identify which business outcome the organization values in the specific situation.
Separate the request from the reason
Ask each stakeholder for the event or consequence behind the request. Distinguish a policy requirement from a preferred interface or habit. GOV.UK discovery guidance recommends reframing predefined solutions as problems and investigating constraints.[1] This creates room for alternatives that address the underlying need.
Record which groups benefit, which carry extra work, and which risks remain. Avoid presenting the loudest stakeholder’s account as the only evidence. Include people who must operate the compromise, especially where decisions create manual review or customer follow-up.
Make decision rights explicit
Identify who can make the cross-team tradeoff. A delivery team can explain technical consequences but should not invent authority over business policy. Escalate when nobody present can accept the consequences, rather than disguising the unresolved issue as a technical detail.
For organizations using Scrum, the Product Owner orders the Product Backlog and remains accountable for its management.[5] That is a useful product decision point, not a reason to ignore policy owners. Clarify how the Product Owner’s authority connects to wider governance.
Hypothetical example: activating an installer account
A hypothetical trade supplier faces competing requests for instant installer access and verification before purchase. The team separates viewing product information from placing an order. It compares immediate limited access with full activation after review against the same operating criteria.
The selected option gives applicants information access while a named reviewer decides purchasing eligibility. The decision record states the support workload and unresolved review capacity. It does not claim the compromise eliminates risk or satisfies every stakeholder equally.
Use a transparent conflict checklist
Keep the record understandable to someone who missed the discussion. Its purpose is to explain the decision, not to assign blame.
- Describe each request and the underlying need or constraint.
- Identify affected users and the work transferred to other teams.
- Compare feasible alternatives against agreed business criteria.
- Name the authorized decision-maker and record material objections.
- State review conditions and the owner of remaining questions.
Avoid both endless consensus and silent closure
Not every participant must prefer the final choice, but participants should be able to see how it was made. Ask them to correct factual errors. Do not rewrite a disagreement as unanimous support just because the implementation needs to move forward.
A transparent process takes time and cannot resolve a missing business strategy. If priorities remain incompatible, narrow the scope or pause the dependent work. An explicit unresolved decision is less costly to discuss than software that embeds a compromise nobody knowingly accepted.
