PoL Probe — A Pre-Development Product Hypothesis Validation Tool

Overview

PoL Probe (Proof of Life Probe) helps product teams test a narrow hypothesis and eliminate critical risks through lightweight, disposable validation experiments before expensive development begins. It is a reconnaissance mission, not an MVP. The goal is to obtain the brutal truth—not to build a demonstrable product.

Use Cases

1. Validating new ideas before project approval: Design a feasibility validation for a new idea, such as workflow automation, that can be completed within a few days. Determine whether “users would really use it this way” before deciding whether to invest engineering resources.
2. Testing pricing and conversion hypotheses: Before changing pricing or the registration flow, use a small-sample task test to validate assumptions—for example, “Can completion rates exceed 80% if the form is reduced to three fields?”—without turning real users into experimental subjects.
3. Low-cost risk screening before feature development: When uncertainty about technical feasibility or users’ ability to complete a task is blocking a decision, use a probe to gather data before deciding whether to proceed to the MVP stage.

Core Features

1. Structured probe document template: Fill in the hypothesis statement, risks to eliminate, prototype type, target users, success thresholds (Pass/Fail criteria), timeline, disposition plan, and owner using a consistent structure. A single document enables the team to reach agreement in advance on “what failure looks like.”
2. Five prototype types to choose from: Feasibility check (can it be built?), task-focused test (can users complete the task without friction?), narrative prototype (can the workflow gain support?), synthetic-data simulation, and Vibe-Coded probe. Choose the cheapest validation method for the hypothesis rather than defaulting to the tool at hand.
3. Quality checklist: Self-check across dimensions such as lightweight (buildable in 1–3 days), disposable (with a clear deletion date), narrow in scope (tests only one hypothesis), honest (bad data should hurt), falsifiable, and assigned to a clear owner. This prevents probes from turning into prototype theater that nobody is willing to delete.

Frequently Asked Questions

What is the difference between a PoL probe and an MVP?

A PoL probe is reconnaissance before an MVP: it answers one specific question, takes anywhere from a few hours to a few days, is deleted immediately after testing, and targets the internal team and a small sample of users. An MVP is the smallest shippable product increment for iterative development, aimed at real customers and built over several weeks to several months. The correct sequence is to use a probe to decide “whether to build an MVP,” rather than directly building a superficially polished MVP.

When should I use a PoL probe, and when should I not?

It is appropriate when you have a specific, falsifiable hypothesis; a risk is blocking the next decision; you need the truth within a few days; and you can describe in advance what failure would look like. It is not appropriate when you want to show off a demo to executives (that is prototype theater), already have an answer and are merely seeking validation, cannot articulate a clear hypothesis and deletion plan, or have an overly broad learning objective such as “Will users like it?”

How much time and how many resources does a PoL probe require?

A typical cycle takes 4–5 days: 1–2 days to build, 1 day to test (for example, 10 user sessions), and 1 day to analyze. Afterward, delete the code according to the disposition plan and retain only the learning record. Common tools include ChatGPT Canvas, Replit, Airtable, and Loom, assembled without writing production-grade code. Once the probe is complete, destroy the artifacts and preserve only the conclusions.