Handle conflicting requests by understanding the need, evidence, urgency, and consequence behind each one, then compare them using product strategy, outcomes, risk, reach, effort, and commitments. Make the decision owner and criteria explicit. Communicate what was decided, why, what changes, and when the issue will be reviewed.
Who this is for: Product managers balancing requests from customers, sales, support, executives, operations, design, and engineering.
- Move from requested features to the underlying customer, business, operational, or risk need before comparing options.
- Use shared decision criteria and evidence while recognizing hard obligations that should not enter ordinary scoring.
- Close the loop with a direct decision and rationale instead of promising every requester a place on the roadmap.
Understand each request
Ask who is affected, what happened, how often, what consequence follows, what workaround exists, and why timing matters. A sales request for custom export may reflect one contractual promise, a broader regulated workflow, or a prospect preference. Those situations deserve different product responses even when the requested feature label is identical.
Gather source evidence and identify the requester's role. Sales sees opportunities and objections; support sees recurring pain; engineering sees system risk; executives see strategy and capital. No single viewpoint represents the entire product. Summarize each need fairly enough that its owner recognizes it before beginning prioritization.
Find the actual conflict
Requests may compete for capacity, point toward different customer segments, impose incompatible behavior, or operate on different time horizons. Sometimes they can coexist through sequencing or one solution to a shared opportunity. Map dependencies and identify whether the conflict is about strategy, evidence, timing, scope, or risk.
Separate legal, security, accessibility, contractual, and safety obligations from discretionary feature preference. Confirm obligations with accountable specialists rather than using a weighted score to trade them away. If leadership previously made incompatible commitments, surface that governance problem explicitly instead of asking the delivery team to absorb it silently.
Apply decision criteria
Evaluate strategic fit, customer outcome, reach, severity, evidence strength, risk reduction, commercial effect, effort, opportunity cost, and reversibility. Use ranges and confidence where estimates are weak. A scoring model can prompt discussion, but final judgment should explain why the selected dimensions matter for this product and period.
Explore alternatives such as a smaller scope, service workaround, discovery step, sequencing change, or explicit decline. Identify the accountable decision owner and any escalation path before debate stalls. Record assumptions and dissent. Consensus is useful but not always possible; clarity is better than a compromise that serves no target customer well.
Communicate and maintain trust
Tell requesters the decision, reasoning, affected outcome, and next step in language relevant to their need. Avoid vague backlog promises. If work is declined, explain the product choice and offer an approved alternative when one exists. If deferred, name the evidence or date that will trigger review rather than implying a hidden commitment.
Track decisions and recurring requests. New evidence can change priority, but senior repetition alone should not bypass the process. Review whether product criteria consistently disadvantage a segment or operational team. Trust grows when people see that requests are understood and resolved predictably, even when the answer is no.
Resolve export versus reliability work
Sales wants a custom prospect export while support and engineering want to fix recurring report timeouts for current customers.
- Clarify the prospect commitment, revenue confidence, exact export need, timeout frequency, affected accounts, and customer consequence.
- Identify shared capacity and reliability dependencies, then confirm whether either request carries a contractual obligation.
- Compare strategic segment fit, outcome impact, evidence, risk, effort range, and cost of delay.
- Choose timeout remediation first and offer a bounded manual export for the prospect if operations can support it accurately.
- Document the decision, communicate it to both groups, and set a review after reliability evidence is available.
Stakeholder request decision table
Use one comparable record for each competing request before the decision meeting.
- Need: requester, affected customer or operation, specific event, consequence, urgency, workaround, and evidence.
- Conflict: shared capacity, incompatible behavior, segment choice, dependency, commitment, obligation, or timing.
- Evaluation: strategy, outcome, reach, severity, confidence, risk, commercial effect, effort, and opportunity cost.
- Options: full scope, reduced scope, service response, discovery, sequencing, defer, or decline.
- Decision: owner, rationale, dissent, communication, affected commitment, review trigger, and outcome evidence.
Common mistakes
- Prioritizing by organizational seniority without examining the need, evidence, or opportunity cost.
- Treating every request as independent when several are symptoms of the same underlying customer obstacle.
- Saying 'not now' without a reason or review condition and allowing requesters to hear an implied promise.
Try one
An executive requests a dashboard while customer interviews point to inaccurate source data. How should the product manager respond?
A strong answer clarifies the executive's decision need, demonstrates how source accuracy affects dashboard trust, and compares options using outcome and evidence. It may propose a data-quality intervention plus a temporary report, or a narrow dashboard that exposes confidence. The final owner, tradeoff, and review point should be explicit rather than accepting or rejecting solely by authority.
Sources
- Atlassian product strategy guideOfficial guidance on connecting product vision, market context, goals, and initiatives.
- Atlassian product roadmaps guideOfficial guidance on communicating product direction, priorities, and progress.