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.mdorproblem-framing-canvas.mdfirst) - 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):
- "Can we build this?" — You're uncertain about technical feasibility, API integration, data availability, or third-party dependencies
- "Can users complete this job without friction?" — You're validating critical UI moments, field labels, navigation, or decision points
- "Does this workflow earn stakeholder buy-in?" — You need to explain a complex flow, align leadership, or "tell vs. test" the story
- "Can we model this without production risk?" — You need to explore edge cases, simulate user behavior, or test prompt logic safely
- "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: Validate critical moments—field labels, decision points, navigation, drop-off zones—using specialized testing tools. Focus on observable task completion, not opinions.
Methods:
- Optimal Workshop (tree testing, card sorting)
- UsabilityHub (5-second tests, click tests, preference tests)
- Maze (prototype testing with heatmaps)
- Loom-recorded task walkthroughs (ask users to "think aloud")
Timeline: 2-5 days
Tools:
- Optimal Workshop ($200/month)
- UsabilityHub ($100-300/month)
- Maze (free tier available)
- Loom (free for basic)
Success Criteria Example:
- Pass: 80%+ users complete task in <2 minutes
- Fail: <60% completion, or 3+ users get stuck on same step
- Learn: Identify exact friction point (specific field, button, etc.)
Disposal Plan: Archive session