Pol Probe

What Is This?

Overview

A Proof of Life (PoL) probe is a lightweight, disposable validation artifact designed to surface critical truths before committing to expensive development cycles. The core idea is simple: before building a real product, you run a cheap reconnaissance mission to determine whether a specific hypothesis is worth pursuing. This approach treats uncertainty as a risk to be eliminated early, not a problem to be solved after shipping.

PoL probes are not prototypes, minimum viable products, or beta releases. They are narrow, focused experiments targeting a single risky assumption. The probe either confirms that life exists in the hypothesis, meaning there is real demand, feasibility, or value, or it kills the idea quickly and cheaply. Either outcome is a win, because the cost of learning is far lower than the cost of building the wrong thing.

The discipline behind PoL probes comes from lean product development and scientific experimentation. You define a falsifiable hypothesis, design the cheapest possible test, run it, and read the results honestly. The emphasis on honesty is intentional. PoL probes are built to deliver harsh truth, not comfortable validation.

Who Should Use This

• Product managers who need to validate risky feature ideas before committing engineering resources to a sprint or roadmap cycle
• Startup founders testing whether a market problem is real before writing a single line of production code
• UX researchers who want to validate a core user behavior assumption before designing full interaction flows

Why Use It?

Problems It Solves

• Wasted development cycles: Teams build features that users never wanted because no one tested the underlying assumption before writing code
• Late discovery of fatal flaws: Critical problems surface during QA or post-launch, when fixing them is expensive and disruptive
• Confirmation bias in planning: Stakeholders advocate for ideas they believe in rather than ideas that evidence supports

Core Highlights

• Targets a single, specific hypothesis rather than exploring broad problem spaces
• Designed to be disposable, meaning it is not intended to become production code or a shipped artifact
• Produces a binary or near-binary signal: the hypothesis is supported or it is not
• Requires defining success criteria before running the probe, not after
• Keeps costs low by using the simplest possible method to generate a valid signal
• Encourages intellectual honesty by framing the probe as a search for disconfirming evidence
• Separates learning from building, protecting engineering capacity for validated work
• Creates a documented record of what was tested, how, and what was learned

How to Use It?

Basic Usage

A PoL probe follows a structured definition format. Document each probe using a consistent template before running any experiment.

Probe Name: [Short descriptive label]
Hypothesis: [Specific, falsifiable statement]
Risk Level: [High / Medium / Low]
Test Method: [Describe the cheapest valid test]
Success Criteria: [Measurable threshold that confirms the hypothesis]
Failure Criteria: [Measurable threshold that kills the hypothesis]
Time Box: [Maximum time allowed, e.g., 3 days]
Cost Ceiling: [Maximum spend allowed, e.g., $200]
Result: [Recorded after running the probe]
Decision: [Proceed / Pivot / Kill]

Specific Scenarios

Scenario 1: Validating demand before building a feature A product team believes users want a bulk export function. Before building it, they add a fake button to the interface that logs clicks and displays a message saying the feature is coming soon. After one week, they measure click rate against the success threshold defined in the probe.

Scenario 2: Testing technical feasibility An engineering team is unsure whether a third-party API can handle the required data volume. They write a minimal script to call the API at target load and measure response time and error rate against defined thresholds.

## Minimal feasibility probe script
for i in $(seq 1 100); do
  curl -s -o /dev/null -w "%{http_code} %{time_total}\n" \
    https://api.example.com/endpoint
done | tee probe_results.txt

Scenario 3: Validating willingness to pay A founder creates a simple landing page describing a product that does not exist yet, includes a pricing page, and drives traffic to it. The probe measures how many visitors click the purchase button.

Real-World Examples

• A SaaS company tests whether enterprise buyers will engage with a self-serve onboarding flow by running a five-day concierge simulation before building the automated system
• A mobile app team validates a new notification strategy by manually sending messages to a small user segment before implementing the notification engine
• A logistics startup tests route optimization demand by having a human dispatcher manually optimize routes for ten pilot customers before writing any algorithm code