PANT — Product Management Antagonists

Structured dissent for Product Managers before the meeting supplies its own.

Product Management Antagonists is a library of reusable pant- agent skills for pressure-testing product thinking, challenging weak evidence, exposing hidden assumptions, rehearsing difficult conversations, and finding the holes in an argument while there is still time to fix them.

v0.1.0 public preview: mechanically validated and synthetically specified, with limited human-use evidence. PANT is ready to use and inspect; it is not battle-tested. See Evidence Status.

Start Here

If you are unsure which skill fits, start with pant-antagonist-router. If you already know the job, invoke the specialist directly.

These are not generic “review my document” prompts.

They are evidence-grounded adversarial workflows designed to ask:

  • Does the argument hold together?
  • Is the problem worth solving?
  • Is the evidence strong enough?
  • Are outcomes being confused with outputs?
  • Is this a strategy, or a list of activities wearing a strategy hat?
  • Does the economic logic survive scrutiny?
  • Is the market estimate decision-useful or TAM/SAM/SOM theater?
  • What has been assumed but not demonstrated?
  • Which stakeholder is likely to resist this?
  • What question could blow up the meeting?
  • What would have to be true for this to work?
  • What would make a reasonable person say no?
  • What changes if the weakest assumption is wrong?
  • What happens after approval, launch, adoption, and scale?

The system supports both structured feedback and interactive rehearsal.

Its purpose is not to make Product Managers defensive.

Its purpose is to make their work considerably harder to knock over.

Why This Exists

Product Managers routinely enter consequential conversations carrying incomplete information, uncertain estimates, competing priorities, and proposals that must survive several different definitions of success.

Less-experienced Product Managers can get the shit beat out of them when they first encounter a critical executive. Product practitioners coming from technical backgrounds may be excellent at systems, delivery, and analysis while still being new to managing up, influencing without authority, reading organizational incentives, and defending a recommendation under pressure. The quality of their work does not automatically prepare them for the power dynamics of the room.

PANT exists to help them survive that first contact. It gives them a private place to strengthen the work, anticipate the resistance, practice the exchange, recover when an answer does not land, and learn the decision logic behind the challenge before the real meeting carries real consequences.

Examples include:

  • Roadmap reviews
  • Strategy proposals
  • Business-case reviews
  • Pricing and investment discussions
  • TAM, SAM, and SOM analyses
  • Executive sponsorship requests
  • Customer advisory councils
  • Product demonstrations
  • Tactical approval meetings
  • Launch-readiness reviews
  • Portfolio reviews
  • Root-cause analyses
  • Incident reviews and postmortems
  • Organizational-change proposals
  • Difficult stakeholder conversations
  • Attempts to socialize an idea before it gets politically strangled in a hallway

Friendly feedback is useful.

Friendly feedback also has a habit of arriving as:

Looks great. Maybe tighten slide seven.

Then slide seven survives while the actual argument gets disemboweled in the meeting.

These skills provide an objective source of criticism before customers, executives, finance, engineering, sales, operations, legal, regulators, or reality provide their own.

The Dangerous Animals Foundation

The practical origin of this project is The Dangerous Animals of Product Management, created by Dean Peters in partnership with Productboard. It describes recurring stakeholder and organizational patterns that can knock product work away from customer value and product strategy: fires that consume the roadmap, executive opinions treated as proof, high-value opportunities that become one-customer feature requests, unsupported certainty, optimistic schedules, meaningless assumptions, metric theater, and feature-factory behavior.

The lesson is not that stakeholders are villains. Dangerous Animals are often well-intentioned, carry useful information, and operate under incentives the Product Manager needs to understand. The durable response is better product practice combined with influence without authority:

  • Exercise empathy without surrendering judgment.
  • Make tradeoffs, evidence, and decision logic visible.
  • Give stakeholders enough technical and product context to participate constructively.
  • Use tiny acts of discovery to test load-bearing assumptions quickly.
  • Invite stakeholders into simple, evidence-oriented product practices.
  • Connect proof and recommendations back to customer value, product strategy, and business purpose.

PANT extends that foundation into agent-assisted preparation. The skills should teach Product Managers how to engage a difficult room, not merely generate sharper rebuttals.

Who This Is For

The primary audience is product practitioners who must influence decisions without relying on formal authority:

  • Product Managers
  • Product Owners
  • Business Analysts
  • Product operations and adjacent product roles
  • Technical practitioners moving into product responsibilities
  • Experienced product leaders who want a fast, independent pressure test

The library must work across levels of competence. It should help a first-time Product Manager understand what the executive is testing while allowing an expert to skip the lesson and get directly to useful resistance.

Fast When You Know, Guided When You Do Not

Every scenario skill supports three entry paths in both feedback and dialogue modes.

Entry path Feedback mode Dialogue mode
Direct Use the supplied artifact and context immediately. Produce a grounded review without an intake ceremony. Enter the rehearsal quickly using the supplied role, decision, and stakes.
Guided Explain unfamiliar concepts, gather only consequential missing context, and teach why each major challenge matters. Set up the room, explain the stakeholder's likely decision logic, rehearse one question at a time, and support coaching interrupts.
Best effort Begin with minimal context, label assumptions, reduce confidence appropriately, and identify what evidence could change the review. Construct a plausible room from stated assumptions, make those assumptions visible, and let the user correct them without restarting.

The user may switch paths at any time. Expertise should reduce friction, not reduce rigor. Inexperience should trigger scaffolding, not condescension.

Antagonist Does Not Mean Asshole

An antagonist creates resistance.

Resistance reveals whether the work can carry weight.

The antagonist’s job is not to humiliate the Product Manager, manufacture objections, win an argument, or perform executive cosplay. It challenges the work from a coherent decision-making perspective.

Every antagonist must:

  1. Challenge the work, not attack the person.
  2. Ground criticism in the supplied material and available evidence.
  3. Separate facts, interpretations, estimates, assumptions, forecasts, aspirations, and unknowns.
  4. Explain why a problem matters.
  5. Distinguish blocking flaws from lesser concerns.
  6. Identify what survives scrutiny.
  7. Prioritize probable, consequential risks over theoretical edge cases.
  8. Provide questions, revisions, or discovery actions that could reduce uncertainty.
  9. Avoid pretending that criticism is certainty.
  10. Avoid inventing stakeholder concerns unsupported by the situation.
  11. Remain capable of being persuaded by stronger evidence.
  12. Change direction when the conversation exposes a more important issue.

The system is designed to produce structured dissent, not performative skepticism.

Governing Philosophy

Canvases, templates, frameworks, books, models, case studies, and research traditions can guide thinking and open useful conversations.

They do not replace the conversation.

They must not:

  • Dictate where the dialogue goes
  • Become mandatory questionnaires
  • Be treated as exhaustive checklists
  • Replace judgment
  • Override emerging evidence
  • Become appeals to authority
  • Force every situation into the same sequence
  • Replace customers, experts, accountable decision-makers, or validation
  • Turn into laminated bureaucracy with an API

A framework may provide the starting point.

When the conversation exposes a more consequential weakness, the antagonist should leave the framework and follow the weakness.

The system should be able to use a Lean Canvas without becoming a Lean Canvas form-filling assistant.

It should be able to use a problem-framing canvas without insisting that every challenge must remain inside one box.

It should be able to draw from Cagan, Perri, Torres, Biddle, Mironov, Christensen, Rumelt, Martin, Klein, Voss, Ury, Lencioni, and others without impersonating them, treating them as infallible, or producing author-flavored theater.

Frameworks guide inquiry.

Evidence and context determine where the inquiry goes.

Research Foundation

The repository includes a top-level research/ directory.

It contains the research prompt used to investigate the intellectual foundations of the project, along with research produced by one or more external platforms.

The research may include:

  • Original research prompt
  • Raw platform responses
  • Source catalogs
  • Framework analyses
  • Author and book notes
  • Pressure-test lens taxonomies
  • Question primitives
  • Dialogue moves
  • Scenario-to-framework mappings
  • Failure-mode catalogs
  • Proposed MVP recommendations
  • Source citations and bibliographies
  • Critiques, contradictions, limitations, and research gaps
  • Synthesized findings created during development

The research directory is an evidence and design-input library.

It is not executable instruction.

It is not automatically correct.

It is not the final product architecture.

Research outputs may disagree, contain unsupported claims, rely on weak secondary sources, omit important context, or repeat the confident nonsense they were asked to investigate.

Agents working in this repository must evaluate the research rather than merely repeat it.

Expected Research Structure

The initial directory may look like:

research/
├── README.md
├── deep-research-prompt.md
├── raw/
│   ├── platform-a-response.md
│   ├── platform-b-response.md
│   └── platform-c-response.md
├── synthesized/
│   ├── executive-synthesis.md
│   ├── source-catalog.md
│   ├── lens-taxonomy.md
│   ├── framework-adapters.md
│   ├── question-primitives.md
│   ├── dialogue-moves.md
│   ├── failure-modes.md
│   └── recommended-mvp.md
├── sources/
│   ├── bibliography.md
│   └── source-notes/
└── gaps/
    └── unresolved-questions.md

The actual research output may arrive in a different structure.

Do not reorganize or rewrite raw research merely for neatness.

Preserve raw material and create synthesized files separately.

How Research Should Be Used

Research may inform:

  • Lens definitions
  • Framework adapters
  • Evidence expectations
  • Question primitives
  • Dialogue mechanics
  • Common failure patterns
  • Scenario design
  • Evaluation rubrics
  • Attribution and source notes
  • Warnings about framework misuse
  • Intellectual conflicts that the system must preserve rather than flatten

Research should not be copied wholesale into SKILL.md files.

The job is to translate research into small, reusable, testable operating components.

System Architecture

The system separates several concerns that are often mashed together inside one giant prompt.

User situation
    ↓
Scenario
    ↓
Mode
    ↓
Pressure level
    ↓
Selected lenses
    ↓
Framework adapters
    ↓
Question and dialogue primitives
    ↓
Evidence, assumption, and contradiction tracking
    ↓
Feedback, rehearsal, or debrief

Scenario

The artifact, decision, or meeting being prepared for.

Examples:

  • Roadmap review
  • Strategy proposal
  • Business-case review
  • Market-sizing review
  • Executive sponsorship
  • Customer advisory council
  • Tactical-plan approval
  • Presentation defense
  • Product demonstration
  • Root-cause review

Mode

How the antagonist works with the Product Manager.

  • Feedback mode
  • Dialogue mode

Pressure Level

How much resistance the Product Manager wants to encounter.

  • Constructive
  • Skeptical
  • Resistant
  • Hostile room

Lens

The decision perspective used to challenge the work.

Examples:

  • Problem framing
  • Customer and end-user value
  • Evidence and discovery
  • Strategy and differentiation
  • Commercial and economic
  • Market and competitive
  • Technical and architectural
  • Operational and delivery
  • Adoption and organizational change
  • Risk, governance, legal, and ethics
  • Organizational politics and incentives
  • Communication and argument
  • Decision quality
  • Systems and root cause

Framework Adapter

A reusable interpretation of a canvas, model, book, or research tradition.

Framework adapters help the antagonist generate and pursue useful lines of inquiry without forcing the conversation through a rigid process.

Examples:

  • MITRE Problem Framing Canvas
  • Lean Canvas
  • Business Model Canvas
  • Value Proposition Canvas
  • Opportunity Solution Tree
  • Four Product Risks
  • Money Stories
  • Jobs to Be Done
  • Strategy Choice Cascade
  • Good Strategy Kernel
  • Assumption Mapping
  • DHM Model
  • Premortem
  • Toulmin argument model
  • Interests, positions, and BATNA

Question Primitive

A reusable question pattern with:

  • Trigger
  • Intended purpose
  • Evidence expected
  • Follow-up logic
  • Misuse risk

Dialogue Move

A conversational behavior used during rehearsal.

Examples:

  • Clarifying the decision
  • Surfacing an unstated interest
  • Labeling a concern
  • Requesting objective criteria
  • Following a contradiction
  • Testing confidence
  • Introducing disconfirming evidence
  • Increasing pressure
  • Acknowledging persuasion
  • Temporarily leaving character to coach
  • Debriefing the exchange

Evidence and Contradiction Tracking

The antagonist should track:

  • Claims
  • Evidence
  • Estimates
  • Assumptions
  • Forecasts
  • Commitments
  • Contradictions
  • Concessions
  • Open questions
  • Changed positions
  • Remaining decision risks

This allows dialogue mode to behave like an actual conversation rather than a queue of prewritten difficult questions.

Repository Structure

Skill Namespace

Every installable skill uses the pant- prefix in its folder name, frontmatter name, catalog entry, package name, and documented invocation. The prefix makes PANT skills easy to recognize when they are installed beside skills from other libraries.

Shared lenses, framework adapters, question primitives, and internal support files do not need the prefix because they are not independently invoked skills.

product-management-antagonists/
├── README.md
├── AGENTS.md
├── ROADMAP.md
├── VERSION
├── CHANGELOG.md
├── INTRODUCTION.md
├── SECURITY.md
├── THIRD-PARTY-NOTICES.md
├── pyproject.toml
├── uv.lock
│
├── .claude-plugin/               # Claude Code repository plugin metadata
├── .github/                      # Public contribution and validation workflows
│
├── docs/
│   ├── CURRENT-STATE.md
│   ├── EVALUATION-STANDARD.md
│   ├── HUMAN-TEST-LOG.md
│   ├── LICENSING-DECISION.md
│   ├── PHASE-2-EVIDENCE.md
│   ├── PHASE-3-EVIDENCE.md
│   ├── PRIVATE-VETTING-GUIDE.md
│   ├── SKILL-SPEC.md
│   ├── TRIGGER-BOUNDARIES.md
│   ├── GETTING-STARTED.md
│   ├── INSTALLATION.md
│   ├── EVIDENCE-STATUS.md
│   └── releases/
│
├── catalog/
│   ├── SKILLS.md
│   └── trigger-boundaries.yaml
│
├── starter-packs/
│   └── managing-up.yaml
│
├── research/
│   ├── README.md
│   ├── synthesized/
│   ├── sources/
│   ├── gaps/
│   └── raw platform outputs and source PDF
│
├── skills/                       # Canonical standalone pant- skill packages
│
├── shared/
│   ├── antagonist-contract.md
│   ├── interaction-protocol.md
│   ├── feedback-mode.md
│   ├── dialogue-mode.md
│   ├── evidence-model.md
│   ├── concern-tracking.md
│   ├── pressure-levels.md
│   ├── coaching-and-debrief.md
│   ├── output-schema.md
│   └── readiness-scale.md
│
├── evals/
│   ├── cases/shared-core.yaml
│   ├── fixtures/*.md
│   ├── rubrics/core-antagonist.yaml
│   └── expected-behaviors.yaml
│
├── scripts/
│   ├── build_individual_skills.py
│   ├── sync_skill_runtime.py
│   ├── validate_skills.py
│   ├── validate_links.py
│   ├── validate_research_references.py
│   ├── validate_skill_portability.py
│   ├── validate_trigger_boundaries.py
│   ├── validate_release.py
│   ├── test_library.py
│   ├── build_release.py
│   └── run_evals.py
│
└── tests/
    ├── test_project_structure.py
    ├── test_links.py
    ├── test_research_references.py
    └── test_eval_cases.py

This is the implemented v0.1.0 public-preview structure. Lenses, framework adapters, question primitives, and additional distribution machinery are added only when evidence demonstrates that they materially improve a scenario.

Skill Package Standard

The canonical source for each skill lives under skills/pant-<skill-name>/. A complete scenario skill should normally ship as a small teaching package:

skills/pant-<skill-name>/
├── SKILL.md
├── template.md
├── agents/
│   └── openai.yaml
├── examples/
│   ├── worked-example.md
│   └── weak-example.md
└── references/
    ├── sources.md
    └── runtime/
        └── generated shared contracts
  • Canonical SKILL.md frontmatter supports discovery, categories, audience, modes, entry paths, evidence, outputs, dependencies, optional composition, provenance, timing, status, and licensing.
  • Platform builds reduce that metadata to supported runtime fields without changing the canonical source.
  • SKILL.md contains the scenario-specific operating behavior and stays focused enough for an agent to use.
  • template.md makes the output reusable when the scenario produces a repeatable artifact.
  • Worked examples demonstrate a strong response, not merely a completed form.
  • Weak examples teach common failure modes and how to repair them when that comparison adds value.
  • References preserve provenance, adaptations, limitations, and intellectual-property boundaries.
  • Generated runtime references carry the antagonist, interaction, evidence, pressure, coaching, and output contracts inside the skill.
  • Every link required at runtime remains inside the skill directory.
  • Synthetic examples should span more than one business context when that proves the skill generalizes.

Templates and examples are part of the pedagogy, not decorative extras.

depends_on means another skill is genuinely required and packaging must include it. combine_with means the other skill is useful but optional. A user installing one PANT skill should not silently inherit the whole library.

Two Primary Modes

Feedback Mode

Feedback mode reviews an artifact, argument, proposal, presentation, demonstration, plan, or decision request.

It returns a structured assessment rather than beginning a role-playing conversation.

Typical outputs include:

  • Bottom-line assessment
  • What withstands scrutiny
  • Blocking flaws
  • Significant concerns
  • Hidden assumptions
  • Evidence gaps
  • Contradictions
  • Missing stakeholders or constraints
  • Likely objections
  • Difficult questions
  • Recommended revisions
  • Small discovery actions
  • Readiness verdict

Use feedback mode when the Product Manager wants to improve the work before presenting it.

Example:

Pressure-test this roadmap in feedback mode. Focus on strategic coherence, evidence, sequencing, capacity assumptions, adoption, and whether the roadmap communicates outcomes rather than becoming a disguised release plan.

Dialogue Mode

Dialogue mode simulates a difficult meeting or conversation.

The antagonist adopts a defined stakeholder perspective, understands the decision that stakeholder is being asked to make, and challenges the Product Manager one question at a time.

It does not dump every possible objection into its opening response.

It listens.

It follows weak answers.

It recognizes strong answers.

It changes direction when persuaded.

It increases pressure where the reasoning remains fragile.

Use dialogue mode to rehearse:

  • Executive reviews
  • Customer advisory councils
  • Funding conversations
  • Skeptical engineering reviews
  • Strategy defenses
  • Approval meetings
  • Pricing discussions
  • Difficult postmortems
  • Product demonstrations
  • Presentation question-and-answer sessions
  • Conversations with resistant stakeholders

Example:

Rehearse my customer advisory council. You are the chief operating officer of our largest customer. You are worried that our roadmap is drifting away from operational reliability. Ask one question at a time. Stay in character until I ask for a debrief.

Dialogue Controls

During dialogue mode, the user may say:

  • Pause — Stop the simulation without ending it.
  • Debrief — Explain what worked, what failed, and what remains exposed.
  • Harder — Increase the pressure or skepticism.
  • Easier — Reduce the pressure.
  • Reset — Restart the scenario.
  • Switch lens — Continue from another decision perspective.
  • Switch stakeholder — Continue as another stakeholder.
  • Coach me — Leave character temporarily and improve the answer.
  • Resume — Return to the simulation.
  • End scene — Finish and provide the final debrief.

Lenses Are Not Personas

A lens defines what gets challenged.

Pressure level defines how hard the challenge lands.

Stakeholder context defines why the challenge matters to that person.

These should not be collapsed into one theatrical character.

For example, a commercial lens can be applied by:

  • A supportive chief financial officer
  • A skeptical investor
  • A resistant business-unit leader
  • A curious Product Manager
  • A customer worried about total cost of ownership

The lens supplies economic scrutiny.

It does not require table pounding, suspenders, or repeated use of the word “margin.”

Separating lenses from personalities prevents the repository from becoming a zoo of:

angry-healthcare-CFO-roadmap-reviewer
skeptical-fintech-CTO-roadmap-reviewer
friendly-SaaS-CEO-roadmap-reviewer

The reusable model is:

scenario + mode + pressure + lenses + stakeholder context

Framework Adapters

Framework adapters translate researched concepts into reusable operating guidance.

An adapter should define:

  • Framework purpose
  • Decisions it supports
  • Elements or concepts
  • Relationships among elements
  • Contradictions worth inspecting
  • Evidence expectations
  • Question primitives
  • Common misuses
  • Blind spots
  • Escape conditions
  • Compatible lenses
  • Relevant scenarios
  • Dialogue applications
  • Attribution and sources

Escape Conditions

Every adapter must explain when the antagonist should stop following it.

Examples:

  • The framework has revealed a more consequential issue outside its structure.
  • The artifact does not contain enough information to use the framework meaningfully.
  • Another lens better fits the decision being made.
  • The framework is encouraging repetition rather than insight.
  • The user has already supplied persuasive evidence for that line of inquiry.
  • Continued questioning would become form completion rather than pressure testing.

Frameworks are maps.

The antagonist is allowed to leave the road.

Find the Skill by the Job in Front of You

The catalog should present skills by recognizable product work, not by the intellectual framework underneath them.

Category Job Current and later skills
Find the right pressure test Start from a messy request or use a general review when no specialization is needed. pant-antagonist-router, pant-artifact-pressure-test
Strengthen the decision Pressure-test the strategic, commercial, market, and evidence logic in the work. pant-roadmap-review, pant-strategy-review, pant-business-case-review, pant-market-sizing-review
Prepare for the room Rehearse managing up, executive decisions, and difficult stakeholder conversations. pant-executive-decision-review, pant-meeting-rehearsal; pant-customer-advisory-council remains later.
Prepare execution and learning Test whether a plan will survive delivery and produce evidence. pant-tactical-plan-approval; pant-root-cause-review remains later.

Categories are navigation aids. They do not create separate reasoning systems, and a skill may draw from several shared lenses.

Available and Planned Scenario Skills

The Phase 2 exemplar, pant-executive-decision-review, and eight Phase 3 review candidates are available in the public preview. Each is independently installable and includes rich canonical metadata, a reusable template, examples, provenance, bundled runtime behavior, and platform metadata. The exemplar has repository-owner first-iteration acceptance but is not broadly human-validated.

Phase 2 field validation and Phase 3 catalog validation proceed in parallel. Catalog availability is not a claim that the skills or phase gates are validated.

pant-executive-decision-review

Prepares a product practitioner to seek or defend an explicit executive decision, sponsorship, investment, or commitment.

Try it directly:

Use pant-executive-decision-review in feedback mode. I need the COO to approve a six-week pilot. Pressure-test the ask, evidence, opportunity cost, ownership, and decision conditions.

Or guided:

The CEO wants a roadmap review tomorrow. This is my first executive review. Walk me through it.

It challenges:

  • Whether the decision and ask are explicit
  • Why this matters now
  • Customer and business consequence
  • Strategic coherence and opportunity cost
  • Evidence and confidence
  • Organizational capacity, ownership, and dependencies
  • Risk, reversibility, and decision conditions
  • Whether technical detail has been translated into executive decision logic

In dialogue mode, it rehearses a coherent critical executive and supports pause, coaching, pressure changes, persuasion updates, and debrief. Split sponsorship or hostile-presentation scenarios into separate skills only when evaluation and user evidence demonstrate distinct jobs.

pant-antagonist-router

Available in the public preview: pant-antagonist-router

Determines:

  • What the Product Manager is preparing for
  • What decision is being made
  • Whether feedback or dialogue mode fits
  • Which lenses matter
  • Which framework adapters may help
  • What pressure level is appropriate
  • What missing context would materially change the work

The router should ask only for information that changes the pressure test.

Its current trigger boundaries are documented in PANT Trigger Boundaries. Mechanical validation establishes completeness and internal consistency, not runtime routing behavior.

pant-artifact-pressure-test

General-purpose review for proposals, documents, presentations, demonstrations, plans, and decision memos.

Use when no specialized scenario materially improves the review.

Available: pant-artifact-pressure-test

pant-meeting-rehearsal

General-purpose dialogue simulation.

Use when the Product Manager needs to rehearse a difficult conversation but no specialized scenario is required.

Available: pant-meeting-rehearsal

pant-roadmap-review

Available: pant-roadmap-review

Challenges:

  • Strategic intent
  • Outcome orientation
  • Customer and business evidence
  • Sequencing logic
  • Dependencies
  • Capacity assumptions
  • Investment allocation
  • Tradeoffs
  • Adaptability
  • Adoption implications
  • Whether the roadmap is a release plan wearing a strategy hat

pant-strategy-review

Available: pant-strategy-review

Challenges:

  • Diagnosis
  • Strategic choices
  • Coherence
  • Differentiation
  • Competitive response
  • Capabilities
  • Tradeoffs
  • Measures of progress
  • Assumptions about the market
  • Whether aspirations and activities are being mislabeled as strategy

pant-business-case-review

Available: pant-business-case-review

Challenges:

  • The exact investment and commitment level requested
  • Baseline, incremental benefit, and causal logic
  • Full delivery, enablement, operating, and opportunity costs
  • Alternatives, including no action and smaller probes
  • Adoption, ownership, timing, and benefit realization
  • Sensitivity to load-bearing assumptions
  • Whether evidence supports discovery, pilot, continuation, or scale

This is intentionally narrower than reviewing an entire business model. A future business-model specialist requires evidence of a distinct user job.

pant-market-sizing-review

Available: pant-market-sizing-review

Challenges:

  • Market definition
  • Segmentation
  • Data provenance
  • Top-down versus bottom-up estimates
  • Reachable buyers
  • Channel and sales capacity
  • Conversion assumptions
  • Pricing assumptions
  • Adoption timing
  • Sensitivity to uncertain inputs
  • False precision
  • Whether the estimate informs a decision or decorates a business case

pant-customer-advisory-council

Simulates influential customers who may:

  • Challenge roadmap relevance
  • Question delivery credibility
  • Expose operational problems
  • Demand commitments
  • Compare the product with competitors
  • Raise procurement, security, integration, or support concerns
  • Attempt to turn the roadmap into their personal ransom list

The skill must distinguish customer insight from customer authority over product strategy.

pant-tactical-plan-approval

Available: pant-tactical-plan-approval

Challenges an implementation, launch, migration, rollout, remediation, or operating plan.

It asks whether:

  • The objective is clear
  • Ownership is explicit
  • Dependencies are understood
  • Risks have responses
  • Milestones produce evidence
  • Measures indicate progress
  • Adoption and enablement are addressed
  • The plan can adapt
  • Activities are being confused with outcomes

pant-root-cause-review

Pressure-tests incident reports, postmortems, corrective-action plans, and other “oops, here is what happened” documents.

It challenges:

  • Convenient single-cause explanations
  • Blame disguised as analysis
  • Missing system conditions
  • Timeline gaps
  • Weak evidence
  • Unexamined incentives
  • Control failures
  • Repeatability of corrective actions
  • Whether proposed fixes address causes or visible symptoms

Standard Feedback Output

Unless a scenario requires another format, feedback mode uses:

1. Bottom Line

A concise assessment of whether the work is ready for the stated audience and decision.

2. What Survives Scrutiny

The strongest claims, choices, evidence, and sections.

3. Blocking Flaws

Problems that could prevent approval, adoption, investment, delivery, or credibility.

Each finding should include:

  • Finding
  • Why it matters
  • Evidence
  • Confidence
  • Recommended response

4. Significant Challenges

Important weaknesses that are not necessarily blockers.

5. Assumptions and Evidence Gaps

For each important assumption:

  • What appears to be assumed
  • What supports it
  • What remains unknown
  • What would change the decision
  • What small act of discovery could reduce uncertainty

6. Contradictions and Tensions

Conflicts among:

  • Claims
  • Numbers
  • Audience expectations
  • Business-model elements
  • Strategy choices
  • Customer behavior
  • Delivery assumptions
  • Measures
  • Stakeholder incentives

7. Questions the Room May Ask

The most difficult and probable questions, not every objection anyone could theoretically invent.

8. Recommended Revisions

Changes ordered by likely impact.

9. Readiness Verdict

One of:

  • Ready
  • Ready with caveats
  • Needs another evidence pass
  • Needs material revision
  • Not ready for this decision

A verdict is not a universal grade.

It reflects readiness for a particular audience, decision, consequence, and context.

Dialogue Protocol

Dialogue mode follows these rules:

  1. Establish the stakeholder, decision, stakes, authority, and meeting context.
  2. Ask one meaningful question at a time.
  3. Respond to the Product Manager’s actual answer.
  4. Track claims, evidence, assumptions, contradictions, and concessions.
  5. Pursue evasions, unsupported certainty, and weak reasoning.
  6. Acknowledge strong answers.
  7. Allow better evidence to change the antagonist’s position.
  8. Do not reveal every future objection.
  9. Do not provide coaching while in character unless requested.
  10. Do not become abusive, theatrical, irrational, or impossible to satisfy.
  11. Maintain the stakeholder’s incentives, knowledge, concerns, and decision rights.
  12. End with a structured debrief when requested.

The debrief should cover:

  • Strongest answers
  • Weakest answers
  • Questions that created difficulty
  • Claims that lacked evidence
  • Contradictions left unresolved
  • Moments where the Product Manager became defensive or vague
  • What the stakeholder likely believes now
  • What should change before the real meeting
  • Better answers to one or two critical questions

Pressure Levels

Constructive

Direct but collaborative.

Appropriate for early preparation, learning, and coaching.

Skeptical

The proposal must earn support.

Appropriate for most reviews.

Resistant

The stakeholder has credible reasons to oppose, delay, redirect, or reduce the proposal.

Hostile Room

The audience is impatient, politically complicated, unconvinced, or actively looking for weaknesses.

“Hostile” changes:

  • Resistance
  • Interruptions
  • Burden of proof
  • Tolerance for vague answers
  • Willingness to revisit assumptions

It does not permit:

  • Personal abuse
  • Invented facts
  • Impossible standards
  • Cartoon-villain behavior
  • Refusal to acknowledge persuasive evidence

Evidence Discipline

The antagonist should classify important statements as:

  • Observed fact
  • Reported statement
  • Interpretation
  • Estimate
  • Assumption
  • Hypothesis
  • Commitment
  • Forecast
  • Aspiration
  • Unknown

The antagonist should examine:

  • Evidence strength
  • Relevance
  • Freshness
  • Sample limitations
  • Selection bias
  • Survivorship bias
  • Confounding
  • False precision
  • Base rates
  • Sensitivity to uncertain inputs
  • Contradictory evidence
  • Missing disconfirming evidence

The antagonist should not dismiss qualitative evidence because it is qualitative.

It should not worship quantitative evidence because it contains decimals.

The question is whether the evidence is appropriate for the claim and decision.

Research and Attribution

Concepts derived from books, frameworks, authors, institutions, or research traditions must be attributed accurately in their supporting reference files.

Do not:

  • Reproduce copyrighted canvases or books in full
  • Copy extensive proprietary question lists
  • Claim endorsement from an author
  • Impersonate a living author
  • Describe an output as “what Marty Cagan would say”
  • Manufacture quotations
  • Treat a popular framework as empirically proven without support

Use language such as:

  • Informed by
  • Adapted from
  • Derived from
  • Consistent with
  • Combines ideas from

The system should extract operating principles, not counterfeit the author.

Skill Quality Standards

A skill is not ready because its instructions sound intelligent.

Every skill must be evaluated for:

  • Correct triggering
  • Appropriate lens selection
  • Appropriate framework use
  • Grounding in supplied material
  • Quality and relevance of challenges
  • Ability to distinguish blockers from concerns
  • Accuracy about missing evidence
  • Consequence awareness
  • Actionability
  • Stakeholder realism
  • Dialogue consistency
  • Ability to be persuaded
  • Absence of fabricated facts
  • Absence of cheap cynicism
  • Absence of personal abuse
  • Useful debriefing
  • Appropriate readiness verdicts
  • Ability to leave a framework when it stops