Proof of Life (PoL) Probe
Define and document a lightweight, disposable validation artifact designed to surface harsh truths before expensive development — the artifact template that pairs with pol-probe-advisor.
Your prototype has three weeks of dev time in it, a real database, and a staging environment — and you haven't deleted anything yet. That's not a probe, that's a half-built product. A PoL probe has a disposal date, a single hypothesis, and a stinging success criterion that makes you wince if you fail. Reconnaissance, not MVP.
Who it's for: PMs documenting validation artifacts, UX leads running discovery sprints, founders avoiding prototype theater, teams committing to disposable experiments, engineers allocating spike time
Example
"Document a PoL probe for testing 3-field onboarding vs. 8-field" → Hypothesis + risk + probe type (Task-Focused) + 10 waitlist users + success criteria (8+ complete <2min / <6 or >5min fail) + tools (Maze + Loom) + 5-day timeline + disposal plan
CLAUDE.md Template
New here? 3-minute setup guide → | Already set up? Copy the template below.
npx ccplaybooks add pol-probe# Proof of Life (PoL) Probe
Define and document a **Proof of Life probe** — a lightweight, disposable validation artifact designed to surface harsh truths before expensive development. Reconnaissance missions, not MVPs. Meant to be **deleted, not scaled**.
Prevents prototype theater. Forces method to match actual learning goal.
## What Is a PoL Probe?
A deliberate, disposable validation experiment answering one specific question as cheaply and quickly as possible. Not a product, not an MVP, not a pilot — a targeted truth-seeking mission.
**Origin:** Coined by Dean Peters (Productside), building on Marty Cagan's 2014 prototype flavors and Jeff Patton: *"The most expensive way to test your idea is to build production-quality software."*
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
Template for documenting a Proof of Life probe with 5 essential characteristics (lightweight, disposable, narrow scope, brutally honest, tiny & focused), explicit disposal plan, and falsifiable success/fail criteria.
Pairs with pol-probe-advisor (decision tree for which probe type) and discovery-process (where probes live in the cycle).
Quick Start
mkdir -p ~/Documents/PolProbe
mv ~/Downloads/CLAUDE.md ~/Documents/PolProbe/
cd ~/Documents/PolProbe
claude
Provide hypothesis, risk, timeline, and chosen probe type. Claude produces the fully filled template with success criteria, tools, and disposal plan.
The 5 Essential Characteristics
| Characteristic | Meaning |
|---|---|
| Lightweight | Hours/days, not weeks |
| Disposable | Planned for deletion, not scaling |
| Narrow Scope | One hypothesis, one risk |
| Brutally Honest | Harsh truths, not vanity metrics |
| Tiny & Focused | Reconnaissance, never MVP |
If your probe feels too polished to delete, it's prototype theater.
PoL Probe vs. MVP
- PoL Probe: Hours-days, disposable, tests IF you should build
- MVP: Weeks-months, iterated, ships what you build
Probes are pre-MVP reconnaissance.
Tips & Best Practices
- Set disposal date before building. Without one, the probe becomes a product.
- Write success/fail/learn criteria before building. "We'll know it when we see it" = no truth.
- One probe, one hypothesis. Bundle 3 questions = ambiguous results.
- Choose method AFTER hypothesis. Tools-first biases toward what you can build, not what you need to learn.
- Celebrate the jank. Frankensoft is the point — a clean probe defeats its purpose.
Common Pitfalls
- Running broad "will users like this?" tests (not falsifiable)
- Treating the probe like a proto-MVP and refusing to delete it
- Vanity metrics that avoid uncomfortable truth
- No pre-defined failure threshold before testing starts
- Choosing tools before defining the hypothesis