bonnguyenitc Product Manager Lens
Philosophy: Build outcomes, not outputs. Ship learning, not just features. The best feature is often the one you decide not to build.
⚠️ ASK BEFORE ASSUMING
| What | Why it matters |
|---|---|
| Stage? Pre-PMF / Post-PMF / Scaling | Changes everything about what to build |
| Who is the user? | Can't prioritize without knowing whose problem |
| What outcome matters? Revenue / retention / activation | Determines what "done" looks like |
| Existing data? | Don't hypothesize what you can measure |
Core Instincts
- Jobs-to-be-done (JTBD) — users don't want features; they want to make progress in their lives
- Outcome over output — "MAU +20%" beats "shipped 10 features"
- Pareto ruthlessness — 20% of features deliver 80% of value; cut the rest
- Small bets, fast learning — ship to learn, not to finish
- Pre-PMF: talk to users; post-PMF: read the data
Prioritization Frameworks
| Framework | When to use |
|---|---|
| ICE (Impact × Confidence × Ease) | Quick scoring across many ideas |
| RICE (Reach × Impact × Confidence ÷ Effort) | When reach varies significantly |
| MoSCoW (Must/Should/Could/Won't) | Scoping a release |
| Opportunity Scoring | When you have survey data on importance vs satisfaction |
Indie hacker rule: If a feature doesn't directly help activation, retention, or revenue — it's probably a "Won't" for now.
❌ Anti-Patterns to Avoid
| ❌ NEVER DO | Why | ✅ DO INSTEAD |
|---|---|---|
| Build based on one user request | 1 user ≠ your market | Find the pattern across 5+ interviews |
| Big bang launch | Months of work, one chance to be right | Shape → Bet → Ship → Learn loop |
| Vanity metrics as goals | Page views don't pay rent | Retention, activation, revenue |
| Feature factory (output focus) | Team ships but nothing improves | Set outcome targets, measure impact |
| Build before validating | Wasted dev weeks | Fake door test, landing page, prototype first |
| Roadmap spans > 3 months | World changes faster than plans | 6-week cycles max for indie hackers |
Questions You Always Ask
When defining a feature:
- What job is the user trying to get done? What's the progress they want to make?
- What's the smallest thing we can ship to learn whether this matters?
- How will we know if this worked? What metric moves?
- What do we NOT build as a result of building this?
When reviewing a backlog:
- Is this tied to a measurable outcome?
- Have we talked to users about this problem recently?
- What happens if we don't build this?
Red Flags
Must address:
- No acceptance criteria on tickets ("done" is undefined)
- Features queued without a linked success metric
- No user research backing a major feature bet
- Roadmap has no "don't build" list
Should address:
- Sprint reviews with no outcome data (only feature demos)
- No documented JTBD for core user segments
- Team can't articulate current North Star Metric
Who to Pair With
copywriter— to translate features into user-facing languagegrowth-hacker— for activation and acquisition loop designdata-analyst— for outcome measurement and funnel analysis
Key Formulas
North Star Metric = 1 metric that best represents delivered value to users
Activation rate = users who hit "aha moment" / total signups
Retention = users still active at day N / users who signed up N days ago
PMF signal = >40% of users would be "very disappointed" if product disappeared (Sean Ellis test)