Download skills/pol-probe/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does pol-probe live?
The publisher keeps it at https://github.com/deanpeters/Product-Manager-Skills.
Which agents can use pol-probe?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.
Define a Proof of Life probe to test a risky hypothesis cheaply. Use when you need harsh truth before building real product.
name: pol-probe
argument-hint: "[hypothesis to test]"
description: Define a Proof of Life probe to test a risky hypothesis cheaply. Use when you need harsh truth before building real product.
intent: >-
Define and document a Proof of Life (PoL) probe—a lightweight, disposable validation artifact designed to surface harsh truths before expensive development. Use this when you need to eliminate a specific risk or test a narrow hypothesis without building production-quality software. PoL probes are reconnaissance missions, not MVPs—they're meant to be deleted, not scaled.
type: component
best_for:
"Documenting a lightweight validation artifact before build"
"Testing a narrow hypothesis without shipping production software"
"Reducing risk before spending engineering time"
scenarios:
"Define a Proof of Life probe for a new workflow automation idea"
"Help me write a PoL probe for this pricing hypothesis"
"Create a low-cost validation probe before we build this feature"
theme: validation-experiments
estimated_time: "15-25 min"
Purpose
Define and document a Proof of Life (PoL) probe—a lightweight, disposable validation artifact designed to surface harsh truths before expensive development. Use this when you need to eliminate a specific risk or test a narrow hypothesis without building production-quality software. PoL probes are reconnaissance missions, not MVPs—they're meant to be deleted, not scaled.
This framework prevents prototype theater (expensive demos that impress stakeholders but teach nothing) and forces you to match validation method to actual learning goal.
Input
Works best with: The hypothesis or risk you need to test.
Also useful: What evidence would change your mind, available time/resources, and what you've validated already.
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 skill asks for the hypothesis and the riskiest assumption inside it before designing the probe.
Example invocation:Define a PoL probe: we believe restaurant managers will photograph invoices daily if it auto-updates food costs.
Key Concepts
What is a PoL Probe?
A Proof of Life (PoL) probe is a deliberate, disposable validation experiment designed to answer one specific question as cheaply and quickly as possible. It's not a product, not an MVP, not a pilot—it's a targeted truth-seeking mission.
Origin: Coined by Dean Peters (Productside), building on Marty Cagan's 2014 work on prototype flavors and Jeff Patton's principle: "The most expensive way to test your idea is to build production-quality software."
The 5 Essential Characteristics
Every PoL probe must satisfy these criteria:
Characteristic
What It Means
Why It Matters
Lightweight
Minimal resource investment (hours/days, not weeks)
If it's expensive, you'll avoid killing it when the data says to
Disposable
Explicitly planned for deletion, not scaling
Prevents sunk-cost fallacy and scope creep
Narrow Scope
Tests one specific hypothesis or risk
Broad experiments yield ambiguous results
Brutally Honest
Surfaces harsh truths, not vanity metrics
Polite data is useless data
Tiny & Focused
Reconnaissance missions, never MVPs
Small surface area = faster learning cycles
Anti-Pattern: If your "prototype" feels too polished to delete, it's not a PoL probe—it's prototype theater.
PoL Probe vs. MVP
Dimension
PoL Probe
MVP
Purpose
De-risk decisions through narrow hypothesis testing
Justify ideas or defend roadmap direction
Scope
Single question, single risk
Smallest shippable product increment
Lifespan
Hours to days, then deleted
Weeks to months, then iterated
Audience
Internal team + narrow user sample
Real customers in production
Fidelity
Just enough illusion to catch signals
Production-quality (or close)
Outcome
Learn what doesn't work
Learn what does work (and ship it)
Key Distinction: PoL probes are pre-MVP reconnaissance. You run probes to decide if you should build an MVP, not to launch something.
The 5 Prototype Flavors
Match the probe type to your hypothesis, not your tooling comfort.
Type
Core Question
Timeline
Tools/Methods
When to Use
1. Feasibility Checks
"Can we build this?"
1-2 days
GenAI prompt chains, API tests, data integrity sweeps, spike-and-delete code
Technical risk is unknown; third-party dependencies unclear
2. Task-Focused Tests
"Can users complete this job without friction?"
2-5 days
Optimal Workshop, UsabilityHub, task flows
Critical moments (field labels, decision points, drop-off zones) need validation
You need user feedback on workflow/UX, but not production-grade code
Golden Rule:"Use the cheapest prototype that tells the harshest truth. If it doesn't sting, it's probably just theater."
When to Use a PoL Probe
✅ Use a PoL probe when:
You have a specific, falsifiable hypothesis to test
A particular risk blocks your next decision (technical feasibility, user task completion, stakeholder support)
You need harsh truth fast (within days, not weeks)
Building production software would be premature or wasteful
You can articulate what "failure" looks like before you start
❌ Don't use a PoL probe when:
You're trying to impress executives (that's prototype theater)
You already know the answer and just want validation (that's confirmation bias)
You can't articulate a clear hypothesis or disposal plan
The learning goal is too broad ("Will customers like this?")
You're using it to avoid making a hard decision
Application
Use template.md for the full fill-in structure.
PoL Probe Template
Use this structure to document your probe:
# PoL Probe: [Descriptive Name]
## Hypothesis
[One-sentence statement of what you believe to be true]
Example: "If we reduce the onboarding form to 3 fields, completion rate will exceed 80%."
## Risk Being Eliminated
[What specific risk or unknown are you addressing?]
Example: "We don't know if users will abandon signup due to form length."
## Prototype Type
[Select one of the 5 flavors]
- [ ] Feasibility Check
- [ ] Task-Focused Test
- [ ] Narrative Prototype
- [ ] Synthetic Data Simulation
- [x] Vibe-Coded PoL Probe
## Target Users / Audience
[Who will interact with this probe?]
Example: "10 users from our early access waitlist, non-technical SMB owners."
## Success Criteria (Harsh Truth)
[What truth are you seeking? What would prove you wrong?]
- **Pass:** 8+ users complete signup in under 2 minutes
- **Fail:** <6 users complete, or average time exceeds 5 minutes
- **Learn:** Identify specific drop-off fields
## Tools / Stack
[What will you use to build this?]
Example: "ChatGPT Canvas for form UI, Airtable for data capture, Loom for post-session interviews."
## Timeline
- **Build:** 2 days
- **Test:** 1 day (10 user sessions)
- **Analyze:** 1 day
- **Disposal:** Day 5 (delete all code, keep learnings doc)
## Disposal Plan
[When and how will you delete this?]
Example: "After user sessions complete, archive recordings, delete Frankensoft code, document learnings in Notion."
## Owner
[Who is accountable for running and disposing of this probe?]
## Status
- [ ] Hypothesis defined
- [ ] Probe built
- [ ] Users recruited
- [ ] Testing complete
- [ ] Learnings documented
- [ ] Probe disposed
Quality Checklist
Before launching your PoL probe, verify:
Lightweight: Can you build this in 1-3 days?
Disposable: Have you committed to a disposal date?
Narrow Scope: Does it test ONE hypothesis?
Brutally Honest: Will the data hurt if you're wrong?
Tiny & Focused: Is this smaller than an MVP?
Falsifiable: Can you describe what "failure" looks like?
Clear Owner: Is one person accountable for executing and disposing of this?
If any answer is "no," revise your probe or reconsider whether you need one.
Examples
See examples/sample.md for full PoL probe examples.
Mini example excerpt:
**Hypothesis:** Users can distinguish "archive" vs "delete"
**Probe Type:** Task-Focused Test
**Pass:** 80%+ correct interpretation
Common Pitfalls
Running a broad "will users like this?" experiment instead of testing one falsifiable hypothesis
Treating a PoL probe as a proto-MVP and refusing to dispose of it
Using vanity metrics that avoid uncomfortable truth
Skipping a pre-defined failure threshold before testing begins
Choosing tools first and hypothesis second
References
Related Skills
pol-probe-advisor (Interactive) — Decision framework for choosing which prototype type to use