Pol Probe Advisor

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)

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` 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 Question

Agent synthesizes user input and asks:

Based on your hypothesis and risk, which of these core questions are you really trying to answer?

Offer 5 options (aligned to probe types):

1. "Can we build this?" — You're uncertain about technical feasibility, API integration, data availability, or third-party dependencies
2. "Can users complete this job without friction?" — You're validating critical UI moments, field labels, navigation, or decision points
3. "Does this workflow earn stakeholder buy-in?" — You need to explain a complex flow, align leadership, or "tell vs. test" the story
4. "Can we model this without production risk?" — You need to explore edge cases, simulate user behavior, or test prompt logic safely
5. "Will this solution survive real user contact?" — You need users to interact with a semi-functional workflow to catch UX/workflow issues

User response: [Select one number, or describe if none fit]

Step 2: Recommend PoL Probe Type

Based on user selection, agent recommends the matching probe type:

Option 1 Selected: "Can we build this?"

→ Recommended Probe: Feasibility Check

What it is: A 1-2 day spike-and-delete test to surface technical risk. Not meant to impress anyone—meant to reveal blockers fast.

Methods:

• GenAI prompt chains (test if AI can handle your use case)
• API sniff tests (verify third-party integrations work)
• Data integrity sweeps (check if your data supports the feature)
• Third-party tool evaluation (test if Zapier/Stripe/Twilio does what you think)

Timeline: 1-2 days

Tools:

• ChatGPT/Claude (prompt testing)
• Postman/Insomnia (API testing)
• Jupyter notebooks (data exploration)
• Proof-of-concept scripts (throwaway code)

Success Criteria Example:

• Pass: API returns expected data format in <200ms
• Fail: API times out, or data structure incompatible with our schema
• Learn: Identify specific technical blocker

Disposal Plan: Delete all spike code after documenting findings.

Next Step: Would you like me to generate a pol-probe artifact documenting this feasibility check?

Option 2 Selected: "Can users complete this job without friction?"

→ Recommended Probe: Task-Focused Test

What it is: