---
name: Product Logic Adversarial Review
description: Stress-test a product decision from the other side before you commit — steelman the opposing case, red-team the plan, audit the data the claim rests on, and run a pre-mortem, so weak logic and shaky numbers surface in a review room instead of in the market. Hedged, multi-angle product thinking. For founders and product leaders about to make a bet.
audience: founder · product manager · product leader · strategist
---

# Product Logic Adversarial Review

## What this is

A method for arguing against your own product decision on purpose, so the flaws show up while they're still cheap to fix. It steelmans the opposing case (the strongest version of "don't do this," not a strawman), red-teams the plan against how it actually fails, audits the data the decision rests on for integrity and for whether it supports the claim, and runs a pre-mortem (assume it failed — why?). The output is not "yes" or "no" but a sharper decision: the assumptions it depends on, the evidence that's actually load-bearing, the failure modes, and what would have to be true for it to work.

## What this is NOT

Not contrarianism for its own sake — the goal is a better decision, not cleverness or reflexive negativity; it argues both sides honestly. Not a veto: it surfaces risk and weak logic, the accountable human still decides. Not a substitute for evidence — where a claim can't be checked, it says "unverified" rather than assuming. Not a replacement for real user research or domain expertise; where the stakes need those, it routes there. It separates a genuine logical or data flaw from a matter of judgment, and labels which is which.

## Method

1. **State the decision and its logic plainly.** Write the claim, the reasoning, and the evidence it rests on — you can't stress-test an argument you haven't made explicit.
2. **Audit the data behind the claim.** Is the data real, recent, representative, and does it actually support the conclusion drawn from it? A decision resting on a vanity metric or a biased sample is already broken.
3. **Steelman the opposing case.** Build the strongest honest version of "this is the wrong call" — if you can't, you don't understand the decision well enough to make it.
4. **Red-team the plan.** Attack it the way reality will: the competitor response, the edge case, the user who behaves differently, the assumption that quietly fails. Name the specific failure, not "risks exist."
5. **Run a pre-mortem.** Assume it has failed twelve months out; write the story of why. Pre-mortems surface failure modes that optimism hides in planning.
6. **Separate logic flaws from judgment calls.** Distinguish "this reasoning doesn't hold / this number is wrong" (a defect) from "reasonable people would weigh this differently" (a call) — and label each, so the decision-maker knows which is which.
7. **Name the load-bearing assumptions.** Identify the few assumptions the whole decision depends on, and how confident each is — the decision is only as strong as its weakest load-bearing assumption.
8. **Deliver a sharper decision, not a verdict.** Output the surviving case, the conditions for it to work, the tripwires to watch, and the open questions — leaving the call with the accountable human, better informed.

## Quality bar

The decision, its logic, and its evidence are made explicit first · the underlying data is audited for integrity and for whether it supports the claim · the opposing case is steelmanned honestly, not strawmanned · the plan is red-teamed with specific failure modes · a pre-mortem surfaces hidden failure paths · logic/data defects are separated from judgment calls and each is labelled · the load-bearing assumptions and their confidence are named · the output sharpens the decision (conditions, tripwires, open questions) rather than issuing a verdict.

## Guardrails & escalation

An analytical discipline for better decisions — it argues both sides in good faith and is not contrarianism or a veto; the accountable human decides. Claims that can't be verified are labelled unverified, never assumed. It separates genuine logical or data flaws from legitimate judgment differences and says which is which. Where a decision needs real user research, domain expertise, or carries legal, financial, or safety stakes, it routes to those humans rather than resolving the call itself. The deliverable is a sharper, better-hedged decision — not a rejection.

## References

- Catalogue: https://edwson.com/consumer-design-system.html · Contracts: https://edwson.com/cds/components.json · Agent brief: https://edwson.com/cds/AGENTS.md
- Related within this kit: the multi-lens risk, AI-displacement-risk, market-position, and enterprise-health-score skills; and the objectivity/logic disciplines in the institutional skill set.