/pol-probe-advisor

name: pol-probe-advisor
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?"

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.

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.

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** to recommend the right PoL probe type based on your context.

---

Step 0: Gather Context

**Agent asks:**

Let's figure out which PoL probe type is right for your validation needs. First, I need some context:

**1. What hypothesis are you testing?** (Describe in one sentence, or use "If [we do X] for [persona], then [outcome]" format)

**2. What specific risk are you trying to eliminate?** Examples:

• Technical feasibility ("Can our API handle real-time data?")
• User task completion ("Can users find the 'export' button?")
• Stakeholder alignment ("Will leadership approve this direction?")
• Edge case behavior ("How does the system handle duplicate entries?")
• Workflow validation ("Will users complete the 3-step onboarding?")

**3. What's your timeline?**

• Hours (same-day validation)
• 1-2 days (quick spike)
• 3-5 days (moderate effort)
• 1 week+ (too long—consider breaking into smaller probes)

**4. What resources do you have available?** Examples:

• Engineering capacity (1 dev for 1 day)
• Design tools (Figma, Loom, Sora)
• AI/no-code tools (ChatGPT Canvas, Replit, Airtable)
• User access (10 users from waitlist, 5 beta customers, etc.)
• Budget (for UsabilityHub, Optimal Workshop, etc.)

---

Step 1: Identify the Core