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. The conversation works from what you paste, and the requests in each document become candidate outcomes and constraints in the spec.

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 as edge cases, constraints, or open questions. Each of those is a claim, so each one can be backed by the quote that raised it.

5. Back each side with its own quote. Capture the two stakeholder documents in the Evidence tab as well, then use the relevant signal as backing for the exact constraint or edge case it produced. A constraint that reads Backed with Security named against it settles a different argument than one that reads Assumption.

6. 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 into the conversation
4. Ask: "Where do these two requests conflict, and what does each assume?"
5. Capture each document in the Evidence tab and use it as backing for the constraint it produced

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