pol-probe
Lightweight validation framework for testing risky hypotheses before expensive product development.
- Defines five prototype flavors (feasibility checks, task-focused tests, narrative prototypes, synthetic data simulations, vibe-coded probes) matched to specific learning goals, not tooling preference
- Emphasizes disposability and narrow scope: PoL probes are reconnaissance missions meant to surface harsh truths and be deleted, not scaled into MVPs
- Includes fill-in template with hypothesis, success criteria, timeline, and explicit disposal plan to prevent sunk-cost fallacy and prototype theater
- Quality checklist ensures probes stay lightweight (1–3 days), falsifiable, and focused on one specific risk or unknown before committing engineering resources
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.
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:
More from deanpeters/product-manager-skills
prd-development
Build a structured PRD that connects problem, users, solution, and success criteria. Use when turning discovery notes into an engineering-ready document for a major initiative.
1.7Kuser-story
Create user stories with Mike Cohn format and Gherkin acceptance criteria. Use when turning user needs into development-ready work with clear outcomes and testable conditions.
1.7Kroadmap-planning
Plan a strategic roadmap across prioritization, epic definition, stakeholder alignment, and sequencing. Use when turning strategy into a release plan that teams can execute.
1.5Kcompany-research
Create a company research brief with executive quotes, product strategy, and org context. Use when preparing for interviews, competitive analysis, partnerships, or market-entry work.
1.3Kproduct-strategy-session
Run an end-to-end product strategy session across positioning, discovery, and roadmap planning. Use when a team needs validated direction before committing to execution.
1.2Kprioritization-advisor
Choose a prioritization framework based on stage, team context, and stakeholder needs. Use when deciding between RICE, ICE, value/effort, or another scoring approach.
1.1K