Pol Probe Advisor

Pol Probe Advisor

Select the right Proof of Life (PoL) probe based on hypothesis, risk, and resources. Use this to match the validation method to the real learning

Category: development Source: deanpeters/Product-Manager-Skills

What Is This?

Overview

The Pol Probe Advisor is a decision-support skill designed to help product managers select the correct Proof of Life (PoL) probe for a given hypothesis. Rather than defaulting to familiar validation methods out of habit or tooling comfort, this skill guides practitioners through a structured selection process based on three core inputs: the hypothesis being tested, the level of risk involved, and the resources available to run the experiment.

Proof of Life probes are lightweight validation instruments used early in product development to confirm whether a core assumption holds before committing significant time or budget. There are five distinct probe types, each suited to different learning goals. Choosing the wrong probe type can produce misleading signals, waste resources, or delay critical decisions. The Pol Probe Advisor eliminates that mismatch by anchoring the selection to the actual learning goal.

This skill is particularly valuable in environments where teams conflate activity with validation. Running a survey when you need behavioral evidence, or building a prototype when a conversation would suffice, are common and costly mistakes. The Pol Probe Advisor provides a repeatable framework to avoid them.

Who Should Use This

  • Product managers who are early in discovery and need to validate a hypothesis before committing to a roadmap item
  • Startup founders who must conserve resources and cannot afford to run the wrong experiment
  • Product designers who want to confirm problem framing before investing in solution design
  • Innovation leads inside larger organizations who need to justify probe selection to stakeholders
  • Agile coaches and delivery leads who support teams in structuring discovery work
  • Product operations professionals who are building or standardizing a discovery playbook

Why Use It?

Problems It Solves

  • Teams default to familiar methods such as surveys or usability tests regardless of whether those methods match the hypothesis, producing weak or irrelevant evidence
  • Probe selection is often driven by tooling availability rather than learning goals, creating a systematic bias in discovery work
  • Without a structured framework, teams struggle to communicate why a particular validation method was chosen, making it harder to defend decisions to stakeholders
  • Risk level is rarely factored into probe selection, leading to over-engineered experiments for low-risk assumptions and under-powered ones for high-stakes bets
  • Resource constraints are ignored during planning, resulting in probes that cannot be completed within the available time or budget

Core Highlights

  • Maps each of the five PoL probe types to specific hypothesis categories and risk profiles
  • Prompts the user to articulate the hypothesis in a testable format before selecting a method
  • Incorporates resource constraints as a first-class input, not an afterthought
  • Reduces cognitive load by narrowing probe options based on structured inputs
  • Produces a clear rationale for the selected probe type that can be shared with stakeholders
  • Supports both qualitative and quantitative validation approaches
  • Works across B2B and B2C product contexts
  • Integrates naturally into existing discovery and sprint planning workflows

How to Use It?

Basic Usage

To invoke the Pol Probe Advisor, provide three structured inputs in your prompt or planning session.

Hypothesis: [State the assumption you are testing]
Risk Level: [Low / Medium / High]
Available Resources: [Time in days, team size, budget range]

Example input:

Hypothesis: Small business owners will pay for automated invoice reconciliation
Risk Level: High
Available Resources: 5 days, 1 researcher, no paid tooling budget

The advisor evaluates these inputs against the five probe types and returns a recommended method with a rationale.

Specific Scenarios

Scenario 1: Validating desirability before building. A product manager suspects users want a new notification feature but has no behavioral evidence. The advisor would recommend a problem interview probe rather than a prototype, because the hypothesis concerns whether the problem exists, not whether a solution works.

Scenario 2: Testing willingness to pay under resource constraints. A team has three days and no budget. The advisor would recommend a smoke test landing page over a concierge experiment, because the latter requires manual fulfillment capacity that is not available.

Real-World Examples

A fintech startup used probe selection guidance to avoid building a full onboarding flow before confirming that target users understood the core value proposition. A single-question intercept probe surfaced a critical comprehension gap in two days.

An enterprise product team used the framework to justify a five-interview discovery sprint to leadership, replacing a planned six-week prototype cycle.