Spot the conflict between two stakeholder requests

Most product disasters start as two reasonable requests from two reasonable stakeholders that quietly contradict each other. The PM either spots the conflict in week one and forces a decision, or doesn't and ships something that satisfies neither. This use case is about doing it in week one.

The input

Two documents. They can be:

• Two slack threads from different teams
• A sales-led PRD and a security-led requirements doc
• A user research summary and a compliance memo
• Any two artifacts that touch the same surface area

Pasted in as plain text. No formatting required.

The flow

1. Create a new intent. Title it after the surface area: "Team invites," "Permissions model," "Data export."

2. Paste both documents into the conversation, one at a time. Pathmode treats each paste as evidence — quotes go on the Evidence Board, requests become candidate outcomes.

3. Ask the conversation to compare them. Something like "Where do these two requests conflict, and what assumptions does each one make?" The Socratic personality will look for direct contradictions, hidden assumptions, scope mismatches, and dependencies — and ask you which to dig into first.

4. Pull tensions into the spec. As the conversation surfaces conflicts, they get added to the spec — sometimes as explicit edge cases, sometimes as constraints, sometimes as open questions. Each one cites the originating quotes via Linked Evidence.

5. Sharpen via the ThinkingQuality score. Tension is one of the four dimensions. A spec that hasn't grappled with conflict scores low — which is the point. Specs that score high on tension are the ones where stakeholder conflicts surfaced and got resolved (or explicitly deferred), not buried.

The output

A spec that:

• Names the conflicts instead of papering over them
• Cites both stakeholders by quote, not paraphrase
• Proposes resolutions with explicit tradeoffs
• Flags unresolved tensions as open questions, not hidden assumptions

Your stakeholders see their own words reflected back. They know they were heard. They also know the conflict exists, which is the first step to resolving it.

Why this beats the "compromise spec"

Most PMs handle stakeholder conflict by writing a vague spec that could be read either way, then letting engineering discover the conflict during implementation. That's the most expensive place to find it. Surfacing the conflict in spec review means the discussion happens once, with the people who can actually decide.

Try it yourself

1. Find two stakeholder docs that overlap (Sales and Security is a perennial favorite)
2. Open Pathmode → product → New intent
3. Paste both as evidence
4. Ask: "Where do these two requests conflict, and what does each assume?"

Related

• Use case: Audit a draft spec for missing edge cases
• Playbook: Why Specs Fail
• Use case: Triage a backlog into a Build Queue in 10 minutes