Product Lens
Pressure-test whether a feature or launch is worth building before it becomes an implementation contract, and capture answers in a PRODUCT-BRIEF.md.
Overview
Product Lens is an agent skill most often used in Validate (also Idea, Ship launch prep) that runs a seven-question product diagnostic and PRODUCT-BRIEF.md go/no-go before implementation planning.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill product-lensWhat is this skill?
- 7-question Product Diagnostic (who, pain, why now, 10-star, MVP, anti-goal, success metric)
- Outputs PRODUCT-BRIEF.md with risks and an explicit go/no-go recommendation
- Explicit handoff: after a “yes, build,” route to product-capability—not more founder theater
- Weekly product review and pre-launch user-journey sanity checks
- Owns product diagnosis only—not PRD/SRS or implementation-ready spec writing
- 7-question Product Diagnostic checklist
- Delivers PRODUCT-BRIEF.md with go/no-go recommendation
Adoption & trust: 3.4k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to commit agent and calendar time to a feature without a crisp user, pain, MVP boundary, or success metric.
Who is it for?
Solo founders and indie builders who want a fast, structured “office hours” pass before specs, sprints, or agent implementation tasks.
Skip if: Teams that already have an approved capability contract or PRD/SRS artifact—use product-capability or execution skills instead.
When should I use this skill?
Before starting any feature, weekly product review, choosing between features, before launch sanity check, or converting a vague idea into a product brief before engineering planning.
What do I get? / Deliverables
You get a PRODUCT-BRIEF.md with answered diagnostics, risks, and go/no-go—then invoke product-capability when the answer is yes, build.
- PRODUCT-BRIEF.md with diagnostic answers, risks, and go/no-go
- Explicit recommendation to hand off to product-capability when build is approved
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Validate because the skill’s core job is proving the thesis—MVP, anti-goals, and metrics—before engineering planning locks in. Scope subphase fits idea-to-brief conversion, go/no-go, and choosing between features without writing a full capability contract.
Where it fits
Turn a vague opportunity into a specific user, pain, and “why now” before you pick a stack or pitch.
Compare two feature bets using MVP, anti-goals, and a metric instead of roadmap politics.
Sanity-check whether the pain is frequent and costly enough to justify a paid wedge in the brief.
Run a pre-launch user-journey check so shipping day matches the story in the brief.
How it compares
Product diagnosis and brief lane—not implementation-ready PRD/SRS writing (that is product-capability).
Common Questions / FAQ
Who is product-lens for?
Solo and indie builders shipping with AI coding agents who need to validate product direction before it hardens into an implementation contract.
When should I use product-lens?
Before starting any feature, during weekly product review, when choosing between features, before launch sanity checks, or when converting a vague idea into a brief—across Validate scope work and early Idea research framing.
Is product-lens safe to install?
It is prose workflow guidance with no mandated shell or network access; review the Security Audits panel on this Prism page before trusting any third-party skill package in your agent.
Workflow Chain
Then invoke: product capability
SKILL.md
READMESKILL.md - Product Lens
# Product Lens — Think Before You Build This lane owns product diagnosis, not implementation-ready specification writing. If the user needs a durable PRD-to-SRS or capability-contract artifact, hand off to `product-capability`. ## When to Use - Before starting any feature — validate the "why" - Weekly product review — are we building the right thing? - When stuck choosing between features - Before a launch — sanity check the user journey - When converting a vague idea into a product brief before engineering planning starts ## How It Works ### Mode 1: Product Diagnostic Like YC office hours but automated. Asks the hard questions: ``` 1. Who is this for? (specific person, not "developers") 2. What's the pain? (quantify: how often, how bad, what do they do today?) 3. Why now? (what changed that makes this possible/necessary?) 4. What's the 10-star version? (if money/time were unlimited) 5. What's the MVP? (smallest thing that proves the thesis) 6. What's the anti-goal? (what are you explicitly NOT building?) 7. How do you know it's working? (metric, not vibes) ``` Output: a `PRODUCT-BRIEF.md` with answers, risks, and a go/no-go recommendation. If the result is "yes, build this," the next lane is `product-capability`, not more founder-theater. ### Mode 2: Founder Review Reviews your current project through a founder lens: ``` 1. Read README, CLAUDE.md, package.json, recent commits 2. Infer: what is this trying to be? 3. Score: product-market fit signals (0-10) - Usage growth trajectory - Retention indicators (repeat contributors, return users) - Revenue signals (pricing page, billing code, Stripe integration) - Competitive moat (what's hard to copy?) 4. Identify: the one thing that would 10x this 5. Flag: things you're building that don't matter ``` ### Mode 3: User Journey Audit Maps the actual user experience: ``` 1. Clone/install the product as a new user 2. Document every friction point (confusing steps, errors, missing docs) 3. Time each step 4. Compare to competitor onboarding 5. Score: time-to-value (how long until the user gets their first win?) 6. Recommend: top 3 fixes for onboarding ``` ### Mode 4: Feature Prioritization When you have 10 ideas and need to pick 2: ``` 1. List all candidate features 2. Score each on: impact (1-5) × confidence (1-5) ÷ effort (1-5) 3. Rank by ICE score 4. Apply constraints: runway, team size, dependencies 5. Output: prioritized roadmap with rationale ``` ## Output All modes output actionable docs, not essays. Every recommendation has a specific next step. ## Integration Pair with: - `/browser-qa` to verify the user journey audit findings - `/design-system audit` for visual polish assessment - `/canary-watch` for post-launch monitoring - `product-capability` when the product brief needs to become an implementation-ready capability plan