/pol-probe-advisor

name: pol-probe-advisor
argument-hint: "[hypothesis or risk]"
description: Select the right Proof of Life (PoL) probe based on hypothesis, risk, and resources. Use this to match the validation method to the real learning goal, not tooling comfort.
intent: >-
  Guide product managers through selecting the right **Proof of Life (PoL) probe** type (of 5 flavors) based on their hypothesis, risk, and available resources. Use this when you need to eliminate a specific risk or test a narrow hypothesis, but aren't sure which validation method to use. This interactive skill ensures you match the cheapest prototype to the harshest truth—not the prototype you're most comfortable building.
type: interactive
best_for:
  - "Choosing the cheapest useful validation method for a risky idea"
  - "Matching a hypothesis to the right Proof of Life probe"
  - "Avoiding overbuilding before learning the harsh truth"
scenarios:
  - "Which Proof of Life probe should I use to test demand for this idea?"
  - "Help me pick the right validation method for an onboarding hypothesis"
  - "I have a risky AI concept. What PoL probe should I run first?"
theme: validation-experiments
estimated_time: "15-20 min"

Purpose

Guide product managers through selecting the right **Proof of Life (PoL) probe** type (of 5 flavors) based on their hypothesis, risk, and available resources. Use this when you need to eliminate a specific risk or test a narrow hypothesis, but aren't sure which validation method to use. This interactive skill ensures you match the cheapest prototype to the harshest truth—not the prototype you're most comfortable building.

This is **not** a tool for deciding *if* you should validate (you should). It's a decision framework for choosing *how* to validate most effectively.

Input

**Works best with:** The hypothesis you want to validate or the risk you want to eliminate. **Also useful:** Your resources (time, budget, engineering access), audience access, and what failure would cost.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended `ARGUMENTS:` line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

**Arriving empty-handed? That works too.** The advisor opens by asking what you're trying to learn, then matches you to one of the 5 probe flavors.

**Example invocation:** `Which probe fits? Hypothesis: mid-market HR teams will trust AI-drafted job descriptions enough to publish them; 2 weeks, no eng support.`

Key Concepts

The Core Problem: Method-Hypothesis Mismatch

**Common failure mode:** PMs choose validation methods based on tooling comfort ("I know Figma, so I'll design a prototype") rather than learning goal. Result: validate the wrong thing, miss the actual risk.

**Solution:** Work backwards from the hypothesis. Ask: "What specific risk am I eliminating? What's the cheapest path to harsh truth?"

---

The 5 PoL Probe Flavors (Quick Reference)

| Type | Core Question | Best For | Timeline | |------|---------------|----------|----------| | **Feasibility Check** | "Can we build this?" | Technical unknowns, API dependencies, data integrity | 1-2 days | | **Task-Focused Test** | "Can users complete this job without friction?" | Critical UI moments, field labels, decision points | 2-5 days | | **Narrative Prototype** | "Does this workflow earn stakeholder buy-in?" | Storytelling, explaining complex flows, alignment | 1-3 days | | **Synthetic Data Simulation** | "Can we model this without production risk?" | Edge cases, unknown-unknowns, statistical modeling | 2-4 days | | **Vibe-Coded PoL Probe** | "Will this solution survive real user contact?" | Workflow/UX validation with real interactions | 2-3 days |

**Golden Rule:** *"Use the cheapest prototype that tells the harshest truth."*

---

Anti-Patterns (What This Is NOT)

• **Not "build the prototype you're comfortable with":** Match method to hypothesis, not skillset
• **Not "pick based on stakeholder preference":** Optimize for learning, not internal politics
• **Not "choose the most impressive option":** Impressive ≠ informative
• **Not "default to code":** Writing code should be your last resort, not your first

---

When to Use This Skill

✅ **Use this when:**

• You have a clear hypothesis but don't know which validation method to use
• You're unsure whether to build code, create a video, or run a simulation
• You need to eliminate a specific risk quickly (within days)
• You want to avoid prototype theater

❌ **Don't use this when:**

• You don't have a hypothesis yet (use `problem-statement.md` or `problem-framing-canvas.md` first)
• You're trying to impress executives (that's not validation)
• You already know the answer (confirmation bias)
• You need to ship an MVP (this is for pre-MVP reconnaissance)

---

Facilitation Source of Truth

Use [`workshop-facilitation`](../workshop-facilitation/SKILL.md) as the default interaction protocol for this skill.

**Default entry mode:** Guided · set in `pm-skills.config.yaml` (library-wide default or a per-skill override); the user's own choice in the session always wins. On the first turn, offer all three modes, then open in the default without waiting for a pick: Guided asks the first question, Context dump invites the paste, Best guess asks for a one-sentence minimum and drafts with every assumption labeled.

It defines:

• session heads-up + entry mode (Guided, Context dump, Best guess)
• one-question turns with plain-language prompts
• progress labels (for example, Context Qx/8 and Scoring Qx/5)
• interruption handling and pause/resume behavior
• numbered recommendations at decision points
• quick-select numbered response options for regular questions (include `Other (specify)` when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

Application

This interactive skill uses **adaptive questioning** t