| name | product-lens |
| description | Use this skill to validate the "why" before building, run product diagnostics, and convert vague ideas into specs. Includes YC-style forcing questions, founder review, user journey audit, and feature prioritization. |
| origin | ECC + gstack |
Product Lens — Think Before You Build
Core Rules (Apply to All Modes)
Anti-sycophancy is mandatory here. This skill exists to surface hard truths before you write code. Do not soften findings. Do not hedge recommendations.
- Take a position. State what evidence would change it.
- Push on weak answers. If the user's answer is vague, say so and ask again.
- If the idea has a fundamental problem, state it first — before any path forward.
- Never say "that's a valid approach" or "there are tradeoffs to consider" without immediately naming which approach wins here.
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 spec
Mode 1: Office Hours (Forcing Questions)
Default mode. Use this before any non-trivial feature or product decision.
Run through these six questions. Do not proceed to code until all six have real answers (not platitudes).
The Six Questions
Q1 — Who exactly?
Not "developers" or "teams." Name a specific type of person with a specific situation.
Push until you get: [Role] at [context] who [specific pain]
Q2 — What's the pain, quantified?
How often does this happen? What do they do today when this breaks? What does it cost them (time, money, quality)?
Push until you get numbers or a concrete "I currently..." description.
Q3 — Why now?
What changed recently that makes this necessary or newly possible? (Technology shift? Market shift? User behavior change? Regulation?)
If the answer is "nothing changed, it's always been a problem" — that is a warning sign. The lack of urgency kills products.
Q4 — What's the 10-star version?
Forget constraints. If time and money were unlimited, what would the perfect version look like?
This is not a roadmap item — it's a north star to verify your MVP is pointed in the right direction.
Q5 — What's the MVP?
The smallest version that proves the thesis. Not the smallest feature you can ship — the smallest thing that tests whether the core assumption is true.
A/B test, prototype, manual process, or a single workflow count. Full product does not.
Q6 — What's the anti-goal?
What are you explicitly NOT building? What would be a tempting scope expansion that you will refuse?
Anti-goals prevent scope creep and sharpen focus.
Q7 — How do you know it's working?
One metric. Not "engagement" or "user satisfaction." A number you can check next week.
Founder Signal Detection
While gathering answers, track these signals:
| Signal | What to look for |
|---|
| Payment evidence | Has anyone paid for this, or committed to pay? |
| Usage proof | Do people use the current workaround repeatedly? |
| Urgency | Do they ask for this unprompted, or only when you suggest it? |
| Specificity | Can they name a specific instance where this cost them? |
| Competitive pressure | Are competitors shipping this? Are users comparing you? |
Signal count → output tier:
- 3+ signals including payment evidence: Strong go. Build the MVP now.
- 2–3 signals without payment: Validate payment before full build. Run a pre-sale or commitment.
- 0–1 signals: Stop. The assumption is unvalidated. Run a discovery experiment first.
Output: PRODUCT-BRIEF.md
# Product Brief — [Feature/Product Name]
**Date:** [DATE]
**Status:** GO / NO-GO / VALIDATE-FIRST
## The User
[Specific person, not a category]
## The Pain
[Quantified — frequency, cost, current workaround]
## Why Now
[What changed, or honest admission that nothing has — and why you're building anyway]
## 10-Star Version
[Unconstrained ideal state]
## MVP
[Specific, testable, smallest possible version]
## Anti-Goals
[What you will not build, even if asked]
## Success Metric
[One number, checkable within 1 week of launch]
## Founder Signals
[List which signals are present and evidence for each]
## Risks
[Top 2 assumptions that could kill this if wrong]
## Next Step
[Specific action: build, validate payment, run experiment, etc.]
Mode 2: Founder Review
Reviews your current project through a founder lens. Run this when you're not sure if you're building the right thing.
Process
- Read the project: README, CLAUDE.md, package.json, recent commits, open issues.
- Infer the thesis: What is this project actually trying to be? What does success look like for it?
- Score PMF signals (0–10):
- Usage growth trajectory (commits, users, forks, stars trend)
- Retention indicators (repeat contributors, return users, continued engagement)
- Revenue signals (pricing page, billing code, payment integration, paying users)
- Competitive moat (what is genuinely hard to copy here?)
- The 10x question: What is the single change that would 10x the value of this project?
- Flag waste: What are you building that doesn't contribute to the thesis?
Output
Founder Review: [project name]
Thesis (inferred): [what this is trying to be]
PMF Score: [X/10]
- Usage growth: [finding]
- Retention: [finding]
- Revenue signals: [finding / absent]
- Moat: [finding / absent]
10x move: [specific, actionable]
Building that doesn't matter:
- [item] — [why it doesn't move the needle]
- [item]
Recommendation: [direct call — stay course / pivot / cut scope / validate first]
Mode 3: User Journey Audit
Maps the actual user experience as a new user would encounter it.
1. Clone/install the product as a brand new user (no prior context)
2. Document every friction point: confusing steps, errors, missing docs, dead ends
3. Time each step
4. Compare to the closest competitor's onboarding
5. Score time-to-value: how many minutes until the user gets their first meaningful result?
6. Recommend: top 3 fixes ranked by friction-removed per effort
Mode 4: Feature Prioritization
When you have 10 ideas and need to pick 2.
ICE Scoring:
Score = Impact (1-5) × Confidence (1-5) ÷ Effort (1-5)
- List all candidate features
- Score each on ICE
- Rank by score (higher = more worthy)
- Apply hard constraints: runway, dependencies, team capacity
- Output: prioritized list with rationale, and explicit statement of what you're NOT doing
Output
All modes output actionable docs, not essays. Every recommendation has a specific next step. If no specific next step exists, the analysis is incomplete.
Integration
Pair with:
/safety-guard before running destructive operations during the audit/browser-qa to verify the user journey audit findings/canary-watch for post-launch monitoring/retro to close the loop on whether the product decision was right
