Product Lens

by affaan-mef648e01899ba3e8dc6371642deaaf64b4477775No license275K starsListed Oct 9, 2026Updated Oct 9, 2026Repository updated 4 days ago

Validate the why before building through four product diagnostics — a YC-style product diagnostic that produces PRODUCT-BRIEF.md with a go/no-go recommendation, a founder review scoring product-market-fit signals, a user journey audit measuring time-to-value, and ICE feature prioritization. Use when pressure-testing product direction, choosing between features, sanity-checking a launch, or converting a vague idea into a product brief.

Instructions onlyBusiness & Finance Productivity & Workflow

AI-generated overview

Runs four product diagnostics — a YC-style brief, founder review, user journey audit, and ICE feature prioritization.

What it does: This skill applies four product-diagnosis modes: a YC-style diagnostic that asks hard questions and produces a PRODUCT-BRIEF.md with risks and a go/no-go recommendation; a founder review that reads project files and scores product-market-fit signals; a user journey audit that maps friction points and time-to-value; and ICE-based feature prioritization that ranks candidates into a roadmap. All modes are meant to output actionable documents with a specific next step rather than essays. It explicitly owns product diagnosis, not implementation-ready specification writing, and hands off to product-capability when a brief must become a capability plan.
When to use it: Use it before starting a feature to validate the why, during a weekly product review, when choosing between features, before a launch to sanity-check the user journey, or when turning a vague idea into a product brief before engineering planning.
Requirements: Instructions only; no scripts are shipped. Mode 2 reads project files such as README, CLAUDE.md, package.json and recent commits, and Mode 3 involves cloning or installing the product as a new user, so repository and product access are needed. It references companion commands (/browser-qa, /design-system audit, /canary-watch) and a product-capability lane.

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)

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 commits2. 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 this5. Flag: things you're building that don't matter

1. Read README, CLAUDE.md, package.json, recent commits2. 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 this5. 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 user2. Document every friction point (confusing steps, errors, missing docs)3. Time each step4. Compare to competitor onboarding5. Score: time-to-value (how long until the user gets their first win?)6. Recommend: top 3 fixes for onboarding

1. Clone/install the product as a new user2. Document every friction point (confusing steps, errors, missing docs)3. Time each step4. Compare to competitor onboarding5. 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 features2. Score each on: impact (1-5) × confidence (1-5) ÷ effort (1-5)3. Rank by ICE score4. Apply constraints: runway, team size, dependencies5. Output: prioritized roadmap with rationale

1. List all candidate features2. Score each on: impact (1-5) × confidence (1-5) ÷ effort (1-5)3. Rank by ICE score4. Apply constraints: runway, team size, dependencies5. 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

Source and attribution

Source:affaan-m/ECCinskills/product-lensat commitef648e0

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal

Product Lens

Product Lens — Think Before You Build

When to Use

How It Works

Mode 1: Product Diagnostic

Mode 2: Founder Review

Mode 3: User Journey Audit

Mode 4: Feature Prioritization

Output

Integration

Source and attribution

More from affaan-m/ECC

Unified Notifications Ops

Verification Loop

Ui To Vue

Unified Memory

Visa Doc Translate

Team Builder

More in Business & Finance

Audit Xls

Sector Overview

Lbo Model

Dcf Model

Comps Analysis

Audit Xls