Product lens

Product lens

Validates the why before engineering commits to the how. This is upstream of /role-pm:spec-draft — use this first when the idea is still wobbly.

Modes

Pick the mode based on where the user is in the arc:

• diagnostic (default) — they have an idea, haven't built. "Is this worth specing?"
• review — they have a built feature or project. "Is this working? Where's the real leverage?"
• journey — they have a user-facing flow. "Where do users drop off, get confused, or disengage?"
• prioritize — they have 3+ candidate features. "Which should we build next?"

Parse $ARGUMENTS. If the mode isn't explicit, pick based on what the target is and confirm with the user.

Mode 1 — Diagnostic

For an idea that hasn't become a spec yet. Tighter than /role-ceo:office-hours — it's PM-altitude (one feature / one initiative) rather than company-altitude (should we even do this at all).

Ask, one at a time:

1. User — who specifically, by role and context? ("Sarah at Ops in a 50-person logistics company" not "ops people")
2. Pain quantified — how often does this hurt them, and how much? Hours? Dollars? Missed deadlines?
3. Why now — what changed recently that makes this solvable or urgent?
4. Ambitious version — what would the 10× solution look like if we had unlimited resources?
5. Minimal version — what's the smallest thing someone would pay / use this week?
6. What this is NOT — name 3 things we explicitly won't do. Forcing this exposes hidden scope creep.
7. Success metric — how we'll know this worked. Specific and measurable within 30-90 days.

Output a 1-pager brief ready for /role-pm:spec-draft:

# Product brief: <one-line title>

**Status:** Pre-spec. Direction validated, implementation not yet contracted.

## User & pain
<who + quantified pain>

## Why now
<trigger or change>

## Minimal version (what we'd build first)
<specific>

## Ambitious version (what this could become)
<specific>

## Non-goals
- <explicit exclusion>
- <explicit exclusion>
- <explicit exclusion>

## Success metric
<specific + measurable + timebound>

## Open questions before spec
- <question>
- <question>

Mode 2 — Review

For a shipped feature or an initiative the team is running on. Pressure-test it without re-doing the whole diagnostic.

Pull context:

• Current Notion pages referencing the feature
• Usage analytics if a product analytics MCP is available, else ask the user for the numbers
• Recent support tickets, feedback threads, sales mentions of this feature

Score 0-10 on these dimensions (explain each score with evidence, not intuition):

• Product-market fit signal — are users sticky? Are they expanding use? Would they panic if it disappeared?
• Growth leverage — does improving this compound (affects acquisition, retention, or revenue non-trivially)?
• Strategic alignment — does this feature match what the company's supposed to be excellent at?
• Effort-to-impact — where we stand on the cost-benefit frontier given current evidence

Then:

• What's working — anchored in evidence
• What's quietly broken — patterns in feedback / usage that we haven't named
• Scaling opportunities — things that could 3-10× this with focused work
• Misaligned effort — work we're doing on this feature that isn't paying off

Mode 3 — Journey audit

For a specific user-facing flow — onboarding, purchase, activation, etc.

Walk through the flow as a new user would. Document:

1. Each step — numbered, with timing if measurable
2. Friction points — where someone would pause, be confused, or consider giving up
3. Time-to-value — how long until the user gets their first "whoa" or their first real outcome?
4. Benchmark — if a competitor has a comparable flow, how do we compare on timing and friction?

Output:

# Journey audit: <flow name>

## Step-by-step
1. <step> — <time> — <friction level: smooth / paused / blocked>
2. ...

## Time to first value
<measured or estimated, with definition of "value">

## Friction points (ranked by severity)
1. <point> — evidence — suggested fix
2. ...

## Competitor benchmark (if available)
<comparison summary>

## Top 3 fixes
<prioritized, with estimated effort>

Mode 4 — Prioritize

For a list of 3+ candidate features / projects / initiatives.

Score each using ICE:

• Impact (1-10) — how much this moves our primary success metric
• Confidence (1-10) — how sure we are the impact estimate holds up
• Effort (1-10) — cost, where 1 = a week and 10 = multiple quarters

ICE score = Impact × Confidence ÷ Effort. Rank and present.

Then apply real constraints:

• What's locked in by commitments (to customers, investors, other teams)?
• What's sequenced — blocks or is blocked by other work?
• What reuses existing capability vs. requires new infrastructure?

Output:

# Prioritization: <list title>

| # | Candidate | I | C | E | ICE | Rank | Recommend |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | <name> | 8 | 7 | 3 | 18.7 | 1 | **Next** |
| 2 | ... |

## Real-constraint adjustments
- <item> moved up because it's blocking customer X's expansion
- <item> moved down because it depends on <other item> landing first

## Recommended order
1. <item>
2. <item>
3. ...

## Deferred (with trigger to revisit)
- <item> — revisit when <trigger>

Don't

• Don't run diagnostic if the user's at review altitude. Match the mode to where they are.
• Don't score ICE without exposing the reasoning for each number. "8/10 impact" with no evidence is a guess dressed up.
• Don't write a spec in this skill. The point is to decide whether there should be a spec. If yes, the next step is /role-pm:spec-draft.

---

Methodology inspired by the Affaan M "product-lens" skill.