Product Strategy & Execution Skill

Core Philosophy

Transform vague product ideas into concrete, executable strategies with clear metrics, user impact, and technical feasibility.

When to Use This Skill

• •Product discovery and opportunity assessment
• •PRD (Product Requirements Document) creation
• •Feature prioritization and roadmap planning
• •Stakeholder alignment documents
• •Go-to-market strategy
• •Product metrics and success criteria definition

Execution Framework

1. Problem Definition Phase

Before diving into solutions, deeply understand:

• •What is the actual user problem? (Not what stakeholders think it is)
• •What evidence validates this problem exists?
• •What is the cost of NOT solving this problem?
• •Who are the users affected and what's their current workaround?

Output a Problem Statement:

• •Clear, concise articulation
• •Quantified impact (users affected, revenue at stake, time wasted)
• •Current state vs desired state

2. Opportunity Sizing

Calculate potential impact using:

• •TAM/SAM/SOM framework
• •User segmentation analysis
• •Revenue/engagement/efficiency impact projections
• •Competitive positioning assessment

Deliver:

• •Expected business metrics (revenue, retention, MAU growth)
• •User value metrics (time saved, success rate, NPS impact)
• •Strategic value (market position, moat building)

3. Solution Exploration

Generate multiple solution approaches:

• •Quick wins vs long-term bets
• •Build vs buy vs partner analysis
• •MVP vs full feature comparison
• •Technical feasibility assessment

For each solution provide:

• •User experience flow (narrative form)
• •Key technical requirements
• •Resource estimate (eng weeks, design weeks)
• •Risk assessment
• •Dependencies and blockers

4. Prioritization Matrix

Evaluate using ICE Score framework:

• •Impact (1-10): Business + user value
• •Confidence (1-10): Evidence quality
• •Ease (1-10): Implementation simplicity

Additional filters:

• •Strategic alignment score
• •Technical debt consideration
• •Team capacity reality check

5. PRD Structure

When creating PRDs, include:

Executive Summary

• •Problem statement
• •Proposed solution (1 paragraph)
• •Success metrics
• •Resource ask

User Stories & Jobs-to-be-Done

• •Primary user personas
• •User journey maps
• •Job stories: "When [situation], I want to [motivation], so I can [outcome]"

Requirements

• •Functional requirements (what it must do)
• •Non-functional requirements (performance, security, accessibility)
• •Out of scope (explicitly stated)

Success Metrics

• •Leading indicators (what we can measure immediately)
• •Lagging indicators (long-term impact)
• •Counter-metrics (what we DON'T want to harm)

Go-to-Market

• •Launch plan
• •Communication strategy
• •Training requirements
• •Rollout phases

6. Stakeholder Communication

Tailor communication by audience

• •Executives: Impact, cost, timeline - 3 bullets max
• •Engineering: Technical requirements, edge cases, scalability
• •Design: User problems, success criteria, constraints
• •Sales/CS: Value prop, customer benefits, FAQs

Output Format Principles

Always Include

1. •TL;DR at top - Busy execs need the headline
2. •Clear decision required - What needs to be decided and by when
3. •Data over opinions - Link to research, metrics, user feedback
4. •Risks explicitly called out - What could go wrong
5. •Next steps with owners - Who does what by when

Never Include

• •Jargon without definitions
• •Solutions before problems
• •Unvalidated assumptions
• •Vague timelines like "Q2" without dates
• •Success metrics without baselines

Quality Checks

Before delivering any product document

• • Is the user problem crystal clear?
• • Are success metrics measurable and time-bound?
• • Have I included 2-3 alternatives considered?
• • Are risks and mitigation strategies explicit?
• • Can engineering start work from this?
• • Would I bet my bonus on these estimates?

Advanced Techniques

Jobs-to-be-Done Framework

Instead of: "User wants a faster dashboard" Use: "When I arrive at work Monday morning, I want to immediately see which deals need attention, so I can prioritize my week before my calendar fills up"

Working Backwards (Amazon style)

Start with the press release announcement, then work backwards to figure out what to build.

Outcome over Output

Focus on user outcomes achieved, not features shipped. "Users complete onboarding 40% faster" beats "Built 5 new onboarding screens"

Common Pitfalls to Avoid

1. •Feature Factory Syndrome - Shipping features nobody asked for
2. •The HiPPO Problem - Highest Paid Person's Opinion trumps data
3. •Sunk Cost Fallacy - Continuing failed initiatives because of past investment
4. •Assumption Stacking - Building assumptions on assumptions
5. •Scope Creep - "While we're at it, let's also..."

Example Application

User Request: "Help me write a PRD for a new analytics dashboard"

Elite PM Approach:

1. •First clarify: What problem does the current dashboard not solve?
2. •Who specifically is struggling and what's their current workaround?
3. •What business metric improves if we solve this?
4. •What have we tried before and why didn't it work?
5. •THEN begin PRD with validated problem statement

Metrics That Matter

Product Health:

• •Activation rate (% users reaching "aha moment")
• •Engagement frequency (DAU/MAU ratio)
• •Feature adoption rate
• •Time to value
• •Net Retention Rate

Execution Health:

• •Velocity vs plan
• •Scope creep percentage
• •Bug escape rate
• •Deploy frequency
• •Time to resolve customer issues

Final Principle

The best product managers make decisions reversible. Structure every decision as a two-way door when possible. Test, learn, iterate. Perfect is the enemy of shipped.