القائمة
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 spe
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Full-stack software engineering via Claude Code CLI session with self-correction.
Review code for correctness, style, security vulnerabilities, and potential issues.
Guide product managers through evaluating whether to scale, test, or kill an acquisition channel based on unit economics (CAC, LTV, payback), customer quality (retention, NRR), and scalability (magic
Assess whether your product work is "AI-first" (using AI to automate existing tasks faster) or "AI-shaped" (fundamentally redesigning how product teams operate around AI capabilities). Use this to eva
Defines the two-axis mental model that distinguishes Director-level thinking from PM thinking: Altitude (how wide you zoom out) and Horizon (how far ahead you look). Use this to understand what actual
Diagnose overall SaaS business health by analyzing growth, retention, unit economics, and capital efficiency metrics together. Use this to identify problems early, prioritize actions by urgency, and d
| name | Pol Probe |
| description | 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 spe |
Type: component
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.
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."
Every PoL probe must satisfy these criteria:
| Characteristic | What It Means | Why It Matters |
|---|---|---|
| Lightweight | Minimal resource investment (hours/days, not weeks) | If it's expensive, you'll avoid killing it when the data says to |
| Disposable | Explicitly planned for deletion, not scaling | Prevents sunk-cost fallacy and scope creep |
| Narrow Scope | Tests one specific hypothesis or risk | Broad experiments yield ambiguous results |
| Brutally Honest | Surfaces harsh truths, not vanity metrics | Polite data is useless data |
| Tiny & Focused | Reconnaissance missions, never MVPs | Small surface area = faster learning cycles |
Anti-Pattern: If your "prototype" feels too polished to delete, it's not a PoL probe—it's prototype theater.
| Dimension | PoL Probe | MVP |
|---|---|---|
| Purpose | De-risk decisions through narrow hypothesis testing | Justify ideas or defend roadmap direction |
| Scope | Single question, single risk | Smallest shippable product increment |
| Lifespan | Hours to days, then deleted | Weeks to months, then iterated |
| Audience | Internal team + narrow user sample | Real customers in production |
| Fidelity | Just enough illusion to catch signals | Production-quality (or close) |
| Outcome | Learn what doesn't work | Learn what does work (and ship it) |
Key Distinction: PoL probes are pre-MVP reconnaissance. You run probes to decide if you should build an MVP, not to launch something.
Match the probe type to your hypothesis, not your tooling comfort.
| Type | Core Question | Timeline | Tools/Methods | When to Use |
|---|---|---|---|---|
| 1. Feasibility Checks | "Can we build this?" | 1-2 days | GenAI prompt chains, API tests, data integrity sweeps, spike-and-delete code | Technical risk is unknown; third-party dependencies unclear |
| 2. Task-Focused Tests | "Can users complete this job without friction?" | 2-5 days | Optimal Workshop, UsabilityHub, task flows | Critical moments (field labels, decision points, drop-off zones) need validation |
| 3. Narrative Prototypes | "Does this workflow earn stakeholder buy-in?" | 1-3 days | Loom walkthroughs, Sora/Synthesia videos, slideware storyboards | You need to "tell vs. test"—share the story, measure interest |
| 4. Synthetic Data Simulations | "Can we model this without production risk?" | 2-4 days | Synthea (user simulation), DataStax LangFlow (prompt logic testing) | Edge case exploration; unknown-unknown surfacing |
| 5. Vibe-Coded PoL Probes | "Will this solution survive real user contact?" | 2-3 days | ChatGPT Canvas + Replit + Airtable = "Frankensoft" | You need user feedback on workflow/UX, but not production-grade code |
Golden Rule: "Use the cheapest prototype that tells the harshest truth. If it doesn't sting, it's probably just theater."
✅ Use a PoL probe when:
❌ Don't use a PoL probe when:
Use template.md for the full fill-in structure.
Use this structure to document your probe:
# PoL Probe: [Descriptive Name]
## Hypothesis
[One-sentence statement of what you believe to be true]
Example: "If we reduce the onboarding form to 3 fields, completion rate will exceed 80%."
## Risk Being Eliminated
[What specific risk or unknown are you addressing?]
Example: "We don't know if users will abandon signup due to form length."
## Prototype Type
[Select one of the 5 flavors]
- [ ] Feasibility Check
- [ ] Task-Focused Test
- [ ] Narrative Prototype
- [ ] Synthetic Data Simulation
- [x] Vibe-Coded PoL Probe
## Target Users / Audience
[Who will interact with this probe?]
Example: "10 users from our early access waitlist, non-technical SMB owners."
## Success Criteria (Harsh Truth)
[What truth are you seeking? What would prove you wrong?]
- **Pass:** 8+ users complete signup in under 2 minutes
- **Fail:** <6 users complete, or average time exceeds 5 minutes
- **Learn:** Identify specific drop-off fields
## Tools / Stack
[What will you use to build this?]
Example: "ChatGPT Canvas for form UI, Airtable for data capture, Loom for post-session interviews."
## Timeline
- **Build:** 2 days
- **Test:** 1 day (10 user sessions)
- **Analyze:** 1 day
- **Disposal:** Day 5 (delete all code, keep learnings doc)
## Disposal Plan
[When and how will you delete this?]
Example: "After user sessions complete, archive recordings, delete Frankensoft code, document learnings in Notion."
## Owner
[Who is accountable for running and disposing of this probe?]
## Status
- [ ] Hypothesis defined
- [ ] Probe built
- [ ] Users recruited
- [ ] Testing complete
- [ ] Learnings documented
- [ ] Probe disposed
Before launching your PoL probe, verify:
If any answer is "no," revise your probe or reconsider whether you need one.
See examples/sample.md for full PoL probe examples.
Mini example excerpt:
**Hypothesis:** Users can distinguish "archive" vs "delete"
**Probe Type:** Task-Focused Test
**Pass:** 80%+ correct interpretation