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 goal, not tooling comfort.

Purpose Guide product managers through selecting the right Proof of Life (PoL) probe type (of 5 flavors) based on their hypothesis, risk, and available resources. Use this when you need to eliminate a specific risk or test a narrow hypothesis, but aren't sure which validation method to use. This interactive skill ensures you match the cheapest prototype to the harshest truth—not the prototype you're most comfortable building. This is not a tool for deciding if you should validate (you should). It's a decision framework for choosing how to validate most effectively. Input Works best with: The hypothesis you want to validate or the risk you want to eliminate. Also useful: Your resources (time, budget, engineering access), audience access, and what failure would cost. 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 advisor opens by asking what you're trying to learn, then matches you to one of the 5 probe flavors. Example invocation: Which probe fits? Hypothesis: mid market HR teams will trust AI drafted job descriptions enough to publish them; 2 weeks, no eng support. Key Concepts The Core Problem: Method Hypothesis Mismatch Common failure mode: PMs choose validation methods based on tooling comfort ("I know Figma, so I'll design a prototype") rather than learning goal. Result: validate the wrong thing, miss the actual risk. Solution: Work backwards from the hypothesis. Ask: "What specific risk am I eliminating? What's the cheapest path to harsh truth?" The 5 PoL Probe Flavors (Quick Reference) Type Core Question Best For Timeline Feasibility Check "Can we build this?" Technical unknowns, API dependencies, data integrity 1 2 days Task Focused Test "Can users complete this job without friction?" Critical UI moments, field labels, decision points 2 5 days Narrative Prototype "Does this workflow earn stakeholder buy in?" Storytelling, explaining complex flows, alignment 1 3 days Synthetic Data Simulation "Can we model this without production risk?" Edge cases, unknown unknowns, statistical modeling 2 4 days Vibe Coded PoL Probe "Will this solution survive real user contact?" Workflow/UX validation with real interactions 2 3 days Golden Rule: "Use the cheapest prototype that tells the harshest truth." Anti Patterns (What This Is NOT) Not "build the prototype you're comfortable with": Match method to hypothesis, not skillset Not "pick based on stakeholder preference": Optimize for learning, not internal politics Not "choose the most impressive option": Impressive ≠ informative Not "default to code": Writing code should be your last resort, not your first When to Use This Skill ✅ Use this when: You have a clear hypothesis but don't know which validation method to use You're unsure whether to build code, create a video, or run a simulation You need to eliminate a specific risk quickly (within days) You want to avoid prototype theater ❌ Don't use this when: You don't have a hypothesis yet (use problem statement.md or problem framing canvas.md first) You're trying to impress executives (that's not validation) You already know the answer (confirmation bias) You need to ship an MVP (this is for pre MVP reconnaissance) Facilitation Source of Truth Use [ workshop facilitation ](../workshop facilitation/SKILL.md) as the default interaction protocol for this skill. It defines: session heads up + entry mode (Guided, Context dump, Best guess) one question turns with plain language prompts progress labels (for example, Context Qx/8 and Scoring Qx/5) interruption handling and pause/resume behavior numbered recommendations at decision points quick select numbered response options for regular questions (include Other (specify) when useful) This file defines the domain specific assessment content. If there is a conflict, follow this file's domain logic. Application This interactive skill uses adaptive questioning to recommend the right PoL probe type based on your context. Step 0: Gather Context Agent asks: Let's figure out which PoL probe type is right for your validation needs. First, I need some context: 1. What hypothesis are you testing? (Describe in one sentence, or use "If [we do X] for [persona], then [outcome]" format) 2. What specific risk are you trying to eliminate? Examples: Technical feasibility ("Can our API handle real time data?") User task completion ("Can users find the 'export' button?") Stakeholder alignment ("Will leadership approve this direction?") Edge case behavior ("How does the system handle duplicate entries?") Workflow validation ("Will users complete the 3 step onboarding?") 3. What's your timeline? Hours (same day validation) 1 2 days (quick spike) 3 5 days (moderate effort) 1 week+ (too long—consider breaking into smaller probes) 4. What resources do you have available? Examples: Engineering capacity (1 dev for 1 day) Design tools (Figma, Loom, Sora) AI/no code tools (ChatGPT Canvas, Replit, Airtable) User access (10 users from waitlist, 5 beta customers, etc.) Budget (for UsabilityHub, Optimal Workshop, etc.) Step 1: Identify the Core Question Agent synthesizes user input and asks: Based on your hypothesis and risk, which of these core questions are you really trying to answer? Offer 5 options (aligned to probe types): 1. "Can we build this?" — You're uncertain about technical feasibility, API integration, data availability, or third party dependencies 2. "Can users complete this job without friction?" — You're validating critical UI moments, field labels, navigation, or decision points 3. "Does this workflow earn stakeholder buy in?" — You need to explain a complex flow, align leadership, or "tell vs. test" the story 4. "Can we model this without production risk?" — You need to explore edge cases, simulate user behavior, or test prompt logic safely 5. "Will this solution survive real user contact?" — You need users to interact with a semi functional workflow to catch UX/workflow issues User response: [Select one number, or describe if none fit] Step 2: Recommend PoL Probe Type Based on user selection, agent recommends the matching probe type: Option 1 Selected: "Can we build this?" → Recommended Probe: Feasibility Check What it is: A 1 2 day spike and delete test to surface technical risk. Not meant to impress anyone—meant to reveal blockers fast. Methods: GenAI prompt chains (test if AI can handle your use case) API sniff tests (verify third party integrations work) Data integrity sweeps (check if your data supports the feature) Third party tool evaluation (test if Zapier/Stripe/Twilio does what you think) Timeline: 1 2 days Tools: ChatGPT/Claude (prompt testing) Postman/Insomnia (API testing) Jupyter notebooks (data exploration) Proof of concept scripts (throwaway code) Success Criteria Example: Pass: API returns expected data format in <200ms Fail: API times out, or data structure incompatible with our schema Learn: Identify specific technical blocker Disposal Plan: Delete all spike code after documenting findings. Next Step: Would you like me to generate a pol probe artifact documenting this feasibility check? Option 2 Selected: "Can users complete this job without friction?" → Recommended Probe: Task Focused Test What it is: Validate critical moments—field labels, decision points, navigation, drop off zones—using specialized testing tools. Focus on observable task completion , not opinions. Methods: Optimal Workshop (tree testing, card sorting) UsabilityHub (5 second tests, click tests, preference tests) Maze (prototype testing with heatmaps) Loom recorded task walkthroughs (ask users to "think aloud") Timeline: 2 5 days Tools: Optimal Workshop ($200/month) UsabilityHub ($100 300/month) Maze (free tier available) Loom (free for basic) Success Criteria Example: Pass: 80%+ users complete task in <2 minutes Fail: <60% completion, or 3+ users get stuck on same step Learn: Identify exact friction point (specific field, button, etc.) Disposal Plan: Archive session recordings, document learnings, delete test prototype. Next Step: Would you like me to generate a pol probe artifact documenting this task focused test? Option 3 Selected: "Does this workflow earn stakeholder buy in?" → Recommended Probe: Narrative Prototype What it is: Tell the story, don't test the interface. Use video walkthroughs or slideware storyboards to explain workflows and measure interest. This is "tell vs. test"—you're validating the narrative, not the UI. Methods: Loom walkthroughs (screen recording with voiceover) Sora/Synthesia/Veo3 (AI generated explainer videos) Slideware storyboards (PowerPoint/Keynote with illustrations) Storyboard sketches (use storyboard.md component skill) Timeline: 1 3 days Tools: Loom (free, fast) Sora/Synthesia (text to video, paid) PowerPoint/Keynote (slideware animation) Figma (static storyboard frames) Success Criteria Example: Pass: 8/10 stakeholders say "I'd use this" or "This solves the problem" Fail: Stakeholders ask "Why would I use this?" or suggest alternative approaches Learn: Identify which part of the narrative resonates (or doesn't) Disposal Plan: Archive video, document feedback, delete supporting files. Next Step: Would you like me to generate a pol probe artifact documenting this narrative prototype? Option 4 Selected: "Can we model this without production risk?" → Recommended Probe: Synthetic Data Simulation What it is: Use simulated users, synthetic data, or prompt logic testing to explore edge cases and unknown unknowns without touching production. Think "wind tunnel testing, cheaper than postmortem." Methods: Synthea (synthetic patient data generation) DataStax LangFlow (test prompt logic without real users) Monte Carlo simulations (model probabilistic outcomes) Synthetic user behavior scripts (simulate click patterns, load testing) Timeline: 2 4 days Tools: Synthea (open source, healthcare) DataStax LangFlow (prompt chain testing) Python + Faker library (generate synthetic data) Locust/k6 (load testing with synthetic users) Success Criteria Example: Pass: System handles 10,000 synthetic users with <1% error rate Fail: Edge cases cause crashes or incorrect outputs Learn: Identify which edge cases break the system Disposal Plan: Delete synthetic data, archive findings, document edge cases. Next Step: Would you like me to generate a pol probe artifact documenting this synthetic data simulation? Option 5 Selected: "Will this solution survive real user contact?" → Recommended Probe: Vibe Coded PoL Probe What it is: A Frankensoft stack (ChatGPT Canvas + Replit + Airtable) that creates just enough illusion for users to interact with a semi functional workflow. Not production grade—just enough to catch UX/workflow signals in 48 hours. ⚠️ Warning: This is the riskiest probe type. It looks real enough to confuse momentum with maturity. Use only when you need real user contact and other methods won't suffice. Methods: ChatGPT Canvas (quick UI generation) Replit (host throwaway code) Airtable (fake database) Carrd/Webflow (landing page + workflow mockup) Timeline: 2 3 days Stack Example: ChatGPT Canvas: Generate form UI Replit: Host simple Flask/Node app Airtable: Capture form submissions Loom: Record user sessions for post mortem analysis Success Criteria Example: Pass: 8/

pol-probe-advisor