product-lens
Use when pressure-testing whether a feature or product is worth building: YC-style diagnostic, founder review or user-journey audit with a go/no-go brief. For turning an approved idea into an implementation contract, use product-capability.
- License 许可
- MIT
- 所属仓库
- monoes/monomind
- 最近更新
- 2026-11-10
- Stars
- ★ 23
- Forks
- 2
01 前言 Front Matter
- name
- product-lens
- tags
- [ "product", "strategy", "ux", "planning" ]
- tools
- []
- source
- https://github.com/affaan-m/ECC
- license
- MIT
- description
- Use when pressure-testing whether a feature or product is worth building: YC-style diagnostic, founder review or user-journey audit with a go/no-go brief. For turning an approved idea into an implementation contract, use product-capability.
- source_path
- skills/product-lens
- source_commit
- bf70150eb2df8070024e5bdf08e4aa08959e2735
02 资源文件 1
- 许可证LICENSE.txt1.0 KB
03 SKILL.md 正文
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-qato verify the user journey audit findings/design-system auditfor visual polish assessment/canary-watchfor post-launch monitoringproduct-capabilitywhen the product brief needs to become an implementation-ready capability plan
04 同仓库更多 Skills
zk-steward
Org role guidance for a ZK steward: engineer zero-knowledge proof systems with circuit design, SNARK vs STARK choice and security review. This is zero-knowledge cryptography, not Zettelkasten note-taking.
writing-plans
Use when you have a spec or requirements for a multi-step coding task and must write an implementation plan before touching code. Produces bite-sized TDD tasks with exact file paths, code and commands for an engineer with zero context.
write-spec
Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea or user request into a structured document, scoping a feature with goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into a phased spec.
write-query
Write optimized SQL for your dialect with best practices. Use when translating a natural-language data need into SQL, building a multi-CTE query with joins and aggregations, optimizing a query against a large partitioned table, or getting dialect-specific syntax for Snowflake, BigQuery, Postgres, etc.
workflow-automation
Org role guidance for workflow automation: build and maintain CI/CD definitions in GitHub Actions or equivalent: triggers, jobs, matrices, caching. Covers path filters, dependency caching, parallel jobs, timeouts and fail-fast ordering.
workflow-architect
Org role guidance for a workflow architect: map full workflow trees for systems, user journeys and agents, covering every branch and failure. Covers discovering workflows from code, handoff contracts, timeouts, recovery paths and observable state.