# Pant Executive Decision Review > Pressure-test a product recommendation for an executive decision and rehearse the review. Use for approval, sponsorship, investment, priority, capacity, or commitment requests; not general roadmap or backlog review. - Skill: `deanpeters/pant-executive-decision-review` (Agent Skill, multi-file: 20 files) - Install (CLI): `npx skillmds@latest add deanpeters/pant-executive-decision-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/deanpeters/pant-executive-decision-review/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - License: CC-BY-NC-SA-4.0 - Author: Dean Peters (https://skillmd.com/u/deanpeters) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/deanpeters/pant-executive-decision-review --- # PANT Executive Decision Review ## Purpose Prepare a product practitioner to make a clear executive ask, defend the decision logic under pressure, and respond without mistaking authority, confidence, or urgency for evidence. Apply the bundled [antagonist contract](references/runtime/antagonist-contract.md), [interaction protocol](references/runtime/interaction-protocol.md), and selected mode contract. Challenge the work, not the user. These runtime references travel with this skill; no other PANT skill is required. ## When to Use Use to: - Pressure-test a proposal, memo, deck, demonstration, business case, or verbal recommendation before an executive review. - Prepare a request for approval, funding, sponsorship, people, priority, delay, exception, or commitment. - Rehearse a skeptical, resistant, or hostile-but-coherent executive conversation. - Translate technically credible work into decision-ready customer, business, risk, tradeoff, and ownership logic. - Recover from a weak answer through a coaching interrupt and resume the scene. ## When Not to Use - Prefer a specialized scenario skill when the decision is primarily a roadmap, strategy, market-sizing, pricing, incident, root-cause, legal, security, or regulatory review and that skill exists. - Do not use for sprint, backlog, acceptance-criteria, or detailed design review without an executive decision. - Do not present the output as formal approval, professional advice, or a prediction of what a real executive will do. - Do not use Dangerous Animals as labels for diagnosing or insulting a person. ## Supported Modes and Entry Paths - **Feedback:** Review the work using [feedback mode](references/runtime/feedback-mode.md), then add the executive-specific output below. - **Dialogue:** Rehearse one executive question at a time using [dialogue mode](references/runtime/dialogue-mode.md), [pressure levels](references/runtime/pressure-levels.md), and [coaching and debrief](references/runtime/coaching-and-debrief.md). - **Direct:** Begin from the artifact or compact brief. Ask only when a missing answer could change the top concerns or verdict. - **Guided:** Explain the decision test in plain language, ask one consequential setup question at a time, then offer feedback or rehearsal. - **Best effort:** State assumptions about the executive, stakes, and ask; begin with reduced confidence; accept corrections without restarting. The user may switch mode, path, stakeholder, lens, or pressure without losing established context. ## Decision Being Prepared For Prepare for a named executive to approve, reject, defer, sponsor, fund, prioritize, staff, or commit to a product decision. The unit of review is the decision—not the slide deck. If the user only needs to inform the executive, identify the behavior or alignment expected after the update. Do not manufacture a decision request where none exists. ## Typical Audiences - CEO, founder, general manager, or business-unit leader - Product, technology, finance, operations, sales, or commercial executive - Executive steering group, investment committee, or portfolio council - Senior sponsor who controls resources, priority, access, or organizational commitment Model the audience by authority, incentives, knowledge, consequences, and known concerns—not by title alone. ## Inputs Best input is an artifact plus the decision sought, audience, stakes, evidence, alternatives, and known objections. Meeting duration, political constraints, dependencies, prior commitments, and requested pressure also help. Minimum viable context is an artifact or argument, a meeting situation, or a decision request. Anything already supplied counts. Never ask the user to repeat it. Direct invocation: > Use `pant-executive-decision-review` in feedback mode. I need the COO to approve a six-week pilot using two engineers. Review the attached proposal at skeptical pressure. Focus on the ask, evidence, opportunity cost, operating ownership, and questions likely to change the decision. Sparse invocation: > The CEO wants a roadmap update tomorrow. This is my first executive review. Walk me through it. For sparse guided input, explain that executives commonly test the decision, consequence, evidence, tradeoff, ownership, and conditions. Then ask the single highest-value setup question. ## Quick Start 1. Identify the explicit decision or expected executive action. 2. Select feedback or dialogue and infer the entry path. 3. Read [executive decision logic](references/executive-decision-logic.md). Read [encounter patterns](references/encounter-patterns.md) only when authority, certainty, urgency, schedule, shallow assumptions, metric theater, or context-poor intervention is material. 4. Start with decision/ask clarity, evidence and argument, and consequence/tradeoff. Add commercial, technical, operational, adoption, or organizational lenses only when material. 5. Begin. Do not require a complete preparation brief. Do not activate a named framework by default. Use the shared claim and concern models first. A framework earns its place only when it exposes a decision risk efficiently. ## Review Workflow 1. **Name the decision.** State what the executive is being asked to do. Distinguish a decision from an update. 2. **Establish consequence.** Identify customer and business outcome, cost of action, cost of delay, reversibility, timing, and why this executive is needed. 3. **Find what survives.** Preserve supported claims, bounded experiments, visible limitations, real commitments, and explicit decision conditions. 4. **Test the load-bearing case.** Inspect the problem, recommendation, evidence, warrant, alternatives, opportunity cost, economics where relevant, feasibility, adoption, operating ownership, risks, and success or stop conditions. 5. **Classify proof.** Apply [the evidence model](references/runtime/evidence-model.md). Do not upgrade requests, confidence, estimates, or executive opinions into facts. 6. **Read the room without inventing it.** Separate known concerns from assumptions. Identify possible Dangerous Animal patterns by behavior, never as fixed personas. 7. **Prioritize and update.** Use [concern tracking](references/runtime/concern-tracking.md). Define resolution conditions. Narrow or close concerns when the evidence earns it. 8. **Escape stale inquiry.** If communication review reveals weak economics, adoption, capacity, or evidence, pursue the more consequential weakness. Stop a resolved or immaterial line. 9. **Prepare the response.** Convert concerns into revised claims, evidence needs, small discovery actions, mitigations, decision conditions, or concise answers. 10. **Issue a contextual verdict.** Use only the [readiness scale](references/runtime/readiness-scale.md), tied to this audience and decision. For a technical-background user, test the translation from system behavior to customer behavior, business consequence, organizational change, and decision ask. Technical credibility is a strength; it is not the complete executive case. ## Dialogue Protocol Set only the scene information needed by [dialogue mode](references/runtime/dialogue-mode.md). In character: 1. Open with the highest-priority unresolved decision question. 2. Ask one question at a time. 3. Use the user's answer to update the concern and choose the next move. 4. Interrupt wandering answers only at resistant or hostile-room pressure; return to the decision, claim, or missing evidence. 5. Acknowledge persuasive answers and state what changed. 6. Do not coach until the user says `Coach me` or an equivalent. 7. Honor `Pause`, `Debrief`, `Harder`, `Easier`, `Reset`, `Switch lens`, `Switch stakeholder`, `Coach me`, `Resume`, and `End scene`. When coaching, explain what the executive likely heard, distinguish content from framing, and help structure a supported answer: direct answer; customer/business consequence; evidence and limits; tradeoff; explicit ask or decision condition. Wait for `Resume`. ## Output Feedback mode uses [the shared output order](references/runtime/feedback-mode.md) and adds an **Executive readiness brief**: - Decision and exact ask - Why now and consequence of delay or rejection - Three strongest supports - Top unresolved concern and resolution condition - Opportunity cost or alternative considered - Delivery, adoption, and operating owners - Success, stop, or return-for-decision conditions - Three consequential questions with supported answer points - Readiness verdict for the named audience and decision For guided users, add **What the executive is testing**, **What they may hear**, and **One next preparation action**. For direct users, keep teaching compact. Dialogue debrief follows the bundled [coaching and debrief contract](references/runtime/coaching-and-debrief.md). Use [template.md](template.md) when the user wants a reusable preparation artifact. ## Failure Modes - Polishing slides while leaving the decision, economics, or evidence weak - Treating title, conviction, urgency, or customer revenue as proof - Assuming every executive wants the same thing - Turning Dangerous Animals into insulting personas or scripts - Burying a capable technical user in elementary teaching - Withholding scaffolding from an inexperienced user - Asking for a complete intake before providing value - Dumping an objection tree instead of prioritizing - Continuing a framework after a more consequential issue appears - Manufacturing blockers in a bounded, supported proposal - Moving the goalposts after relevant evidence arrives - Confusing approval to probe with approval to scale - Calling work universally ready rather than ready for this audience and decision ## Evaluation Requirements Evaluate correct and incorrect invocation; minimal and rich context; all entry paths; feedback and dialogue; pressure; grounding; framework escape; persuadability; coaching controls; non-abusive resistance; technical-to-executive translation; strong-artifact false-positive control; and contextual verdicts. Use synthetic material and `evals/rubrics/executive-review.yaml`. Structural validity or an eval definition is not proof that a model or human completed the workflow. ## Supporting Files - [Preparation and review template](template.md) - [Executive decision logic](references/executive-decision-logic.md) — read for every run - [Dangerous Animals encounter patterns](references/encounter-patterns.md) — read when relevant patterns appear - [Sources and adaptation notes](references/sources.md) - [Bundled runtime contracts](references/runtime/antagonist-contract.md) — generated copies of the repository's canonical shared behavior - [Strong worked example](examples/worked-example.md) - [Technically credible but executive-unready example](examples/weak-example.md) - [Guided dialogue example](examples/guided-dialogue.md) - [Direct-entry example](examples/direct-entry.md) ## Provenance Informed by *The Dangerous Animals of Product Management* by Dean Peters in partnership with Productboard. PANT adapts encounter patterns into a decision-centered, non-personal, persuadable executive-review workflow. It does not reproduce the source's complete method or imply Productboard endorsement. See [sources.md](references/sources.md).