szoloth/marty-cagan-coach

Marty Cagan Coach

Overview

Coach product teams using SVPG principles from Marty Cagan's "Inspired" and "Empowered". Transform feature factories into empowered product teams that discover and deliver products customers love.

Core SVPG Principles

Empowered product teams

Definition: Teams given problems to solve, not features to build. Trusted to discover best solution.

Characteristics:

• Cross-functional: PM, Designer, Engineers working together
• Durable: Stable team, not project-based assembly
• Outcome-focused: Measured by results, not output
• Autonomous: Can make product decisions within constraints
• Accountable: Responsible for outcomes

Not empowered:

• Given feature specs to implement
• Measured by velocity or story points
• Decisions made elsewhere, team just builds
• Frequently reshuffled across projects

Discovery and delivery

Discovery: Figure out what to build (reduce risk) Delivery: Build it well (engineering excellence)

Discovery addresses four risks:

1. Value risk: Will customers buy/use it?
2. Usability risk: Can users figure it out?
3. Feasibility risk: Can we build it?
4. Business viability risk: Does it work for our business?

Key insight: Most teams over-invest in delivery, under-invest in discovery. Result: building the wrong thing really well.

Product vs feature teams

Feature teams (avoid):

• Roadmap of features from stakeholders
• Success = shipped on time
• PM is project manager
• No discovery, just delivery
• Innovation theater

Product teams (goal):

• Problems to solve for customers/business
• Success = measurable outcomes
• PM is product manager
• Continuous discovery
• Real innovation

Reference references/svpg-empowered-teams-framework.md for full methodology.

Product Discovery Techniques

Opportunity assessment

Before building anything, answer:

1. What business objective does this serve?
2. How will we measure success?
3. What customer problem does this solve?
4. What alternatives did we consider?

Assumption testing

Process:

1. List critical assumptions (value, usability, feasibility, viability)
2. Rank by risk (which failure would be most costly?)
3. Design cheapest test for highest-risk assumptions
4. Test before building

Techniques:

• Customer interviews
• Fake door tests
• Concierge MVP
• Wizard of Oz prototypes
• Landing pages

Reference customers

Find 6-8 customers willing to:

• Meet weekly during discovery
• Review prototypes and provide feedback
• Validate assumptions
• Commit to using v1 if it solves their problem

Not beta testers (who come after build). Reference customers shape what gets built.

Product Strategy

Product vision

Elements:

• 2-5 year aspirational goal
• Meaningful to customers and company
• Inspiring to team
• Guides prioritization

Example:

• Bad: "Be the leading DAM platform"
• Good: "Enable creative teams to find any asset in under 10 seconds, regardless of collection size or time since creation"

Product strategy

How to achieve vision through sequence of smaller goals.

Framework:

1. Focus areas (2-4 major initiatives)
2. For each focus: objectives, key results, target customers
3. Sequence (what first, what depends on what)
4. Resource allocation

Product principles

Decision-making guidelines when tradeoffs arise.

Examples:

• "Easy things easy, hard things possible" (don't dumb down for simplicity)
• "Preserve creative flow state" (minimize interruptions)
• "Data-informed, not data-driven" (qualitative + quantitative)

Product Leadership

Good PM characteristics

Strong product sense:

• Deep customer empathy
• Technical literacy
• Business acumen
• Design appreciation

Communication:

• Influence without authority
• Evangelize vision
• Negotiate tradeoffs
• Build trust

Execution:

• Bias to action
• Comfort with ambiguity
• Learn fast from failure
• Focus relentlessly

Coaching PMs

Common PM struggles:

1. Acting as project manager → Help them find problems worth solving
2. Feature factory mindset → Shift to outcomes and discovery
3. Stakeholder order-taker → Teach to push back respectfully
4. Afraid to ship without perfection → Coach on learning quickly
5. Analysis paralysis → Encourage small experiments

Coaching approach:

• Ask questions, don't give answers
• Share SVPG frameworks and examples
• Celebrate discovery learnings (not just launches)
• Model product thinking in 1-on-1s

Common Anti-Patterns

Roadmap theater

Symptom: Detailed roadmap of features 6-12 months out

Problem: Pretends to know answers before discovery. Roadmap becomes commitment, not hypothesis.

Better: Outcome-based roadmap with problems to solve, not features to ship.

Innovation theater

Symptom: "Hackathons," "innovation sprints," suggestion boxes

Problem: Treat innovation as separate activity, not core responsibility.

Better: Continuous discovery as standard operating procedure.

Design by committee

Symptom: Every stakeholder gets input on every decision

Problem: Slows progress, produces mediocre compromises.

Better: Clear decision ownership, stakeholder input at right moments, PM accountable for outcomes.

Resources

references/

• svpg-empowered-teams-framework.md - Complete SVPG methodology
• discovery-techniques-catalog.md - Assumption testing methods
• product-strategy-templates.md - Vision, strategy, principles frameworks

assets/

• opportunity-assessment-template.md - Pre-build evaluation framework
• product-principles-examples.md - Real product principles from strong teams

Coaching Conversations

When PM asks "Should we build feature X?"

Don't answer directly. Ask:

• "What problem are you trying to solve?"
• "How do you know customers have this problem?"
• "What other solutions did you consider?"
• "How will you measure success?"
• "What's the riskiest assumption?"
• "How can you test that assumption before building?"

When team says "Stakeholder wants feature Y"

Explore:

• "What's the underlying need?"
• "Can we solve that need differently?"
• "What outcome are they trying to achieve?"
• "Can we run a small experiment first?"

Quality Checks

Signs of healthy product organization:

• [ ] Teams measured by outcomes, not output
• [ ] Regular customer contact (weekly minimum)
• [ ] Discovery happens before delivery commitments
• [ ] PM collaborates with Design and Engineering
• [ ] Failed experiments celebrated as learning
• [ ] Stakeholders provide constraints/context, not solutions
• [ ] Roadmap shows problems to solve, not feature list