Proof of Life Probe Advisor
Pick the right PoL probe (Feasibility, Task-Focused, Narrative, Synthetic Data, Vibe-Coded) based on hypothesis, risk, and timeline — match the cheapest prototype to the harshest truth.
You're about to spend two sprints building a prototype because "we need to validate" — but you haven't asked whether the risk is technical, UX, narrative, or edge-case driven. Match the wrong method to the risk and you validate the wrong thing. Five probe types, one decision tree — know which one to use before you start building.
Who it's for: PMs choosing validation methods, UX leads running discovery, founders avoiding prototype theater, teams doing continuous discovery, AI PMs validating prompt-based features
Example
"We want to test if users complete our 3-step onboarding" → Task-Focused Test (not Vibe-Coded) → Maze prototype + 20 waitlist users + 3 days + success criteria: 80% complete in <2 min, failure: <60% or 3+ stuck on same step
CLAUDE.md Template
New here? 3-minute setup guide → | Already set up? Copy the template below.
npx ccplaybooks add pol-probe-advisor# Proof of Life (PoL) Probe Advisor
Select the right **Proof of Life (PoL) probe** type (of 5 flavors) based on your hypothesis, risk, and resources. Match the cheapest prototype to the harshest truth — not the prototype you're most comfortable building.
**What this is:** Decision framework for choosing HOW to validate.
**What this is NOT:** Deciding IF you should validate (you should).
## Core Problem: Method-Hypothesis Mismatch
**Common failure:** PMs choose based on tooling comfort ("I know Figma, so I'll design a prototype"). Result: validate the wrong thing, miss the actual risk.
**Solution:** Work backwards from the hypothesis. "What specific risk am I eliminating? What's the cheapest path to harsh truth?"Get new playbooks like this one
One email a week with new Claude Code workflows. Free, like everything here.
No spam. Unsubscribe anytime.
What This Does
Interactive decision tree for picking the right PoL probe type. Extracts hypothesis + specific risk + timeline + resources, then matches to one of 5 probe flavors with matching tools, success criteria, and disposal plan.
Pairs with pol-probe (artifact template) and problem-statement (frame the hypothesis first).
Quick Start
mkdir -p ~/Documents/PolProbeAdvisor
mv ~/Downloads/CLAUDE.md ~/Documents/PolProbeAdvisor/
cd ~/Documents/PolProbeAdvisor
claude
Provide hypothesis, specific risk, timeline, and available resources. Claude recommends the probe type, tools, success criteria, and disposal plan.
The 5 Probe Flavors
| Type | Core Question | Timeline |
|---|---|---|
| Feasibility Check | Can we build this? | 1-2 days |
| Task-Focused Test | Can users complete this without friction? | 2-5 days |
| Narrative Prototype | Does this workflow earn buy-in? | 1-3 days |
| Synthetic Data Simulation | Can we model this without production risk? | 2-4 days |
| Vibe-Coded PoL Probe | Will this survive real user contact? | 2-3 days |
Tips & Best Practices
- Match method to hypothesis, not tooling. "I know Figma" ≠ "Figma is right for this risk."
- Code is last resort. Most probes don't need it — storytelling, simulation, or specialized tools are cheaper.
- Define failure before building. "We'll know it when we see it" = no harsh truth.
- Set disposal date upfront. Vibe-Coded probes especially — they look real enough to invite scope creep.
- One probe, one hypothesis. Testing 3 things at once = ambiguous results.
Common Pitfalls
- Choosing validation method based on tooling comfort
- Defaulting to code when a Loom + 5 prospects would learn more
- Treating Vibe-Coded probe like production (no disposal plan)
- Testing multiple hypotheses in one probe
- Skipping pre-defined success criteria