When market positioning is unclear, /product-strategist evaluates PMF and competitive gaps, so you can bet on the right moves. — Claude Skill

---

title: Section Organization

1. Product Vision (vision)

Impact: CRITICAL Description: Foundational vision, mission, and north star metrics. The "why" that guides all product decisions. Get this right first.

2. Market Assessment (market)

Impact: CRITICAL Description: Product-market fit evaluation, market sizing (TAM/SAM/SOM), and opportunity analysis. Understand where you're playing.

3. Competitive Strategy (competitive)

Impact: HIGH Description: Competitive positioning, differentiation, moat building, and defensive strategy. How you win against alternatives.

4. Strategic Frameworks (strategy)

Impact: HIGH Description: Strategy development, prioritization frameworks, and decision-making tools. The "how" behind strategy.

5. Business Model (business)

Impact: HIGH Description: Business model design, monetization strategy, and pricing frameworks. How value translates to revenue.

6. Build Decisions (build)

Impact: MEDIUM-HIGH Description: Build vs buy vs partner analysis, platform decisions, and technical strategy. Execution choices that shape strategy.

---

title: Platform vs Product Decisions impact: MEDIUM-HIGH tags: platform, product, ecosystem, strategy

Platform vs Product Decisions

Impact: MEDIUM-HIGH

The platform vs product decision shapes your company's future. Products solve problems directly. Platforms enable others to solve problems. Each path has different economics, moats, and challenges.

Product vs Platform Spectrum

PRODUCT ─────────────────────────────────────────── PLATFORM
    │                                                   │
 Focused                                            Extensible
 Direct value                                       Enabled value
 Linear scaling                                     Network effects
 Simpler GTM                                        Complex ecosystem
    │                                                   │
 Examples:                                          Examples:
 - Basecamp                                         - Salesforce
 - Linear                                           - Shopify
 - Superhuman                                       - Stripe

Product-Platform Matrix

When to Build a Product

Product is right when:

✓ Focused problem with clear solution
✓ Value is fully realized in your product
✓ No need for third-party extensions
✓ Simpler GTM motion
✓ Limited resources (startup)
✓ Time to market is critical

Product characteristics:

• Direct value delivery
• Opinionated workflow
• Integrated experience
• Subscription revenue model
• Linear cost scaling

When to Build a Platform

Platform is right when:

✓ Problem space has many variations
✓ Third parties can add unique value
✓ Network effects possible
✓ Large enough market for ecosystem
✓ Resources to support developers
✓ Long-term moat building priority

Platform characteristics:

• Enabled value delivery
• Flexible, extensible
• Ecosystem of solutions
• Multiple revenue streams
• Network effect scaling

Platform Business Models

Platform Flywheel

        ┌─────────────────────────────────────┐
        │                                     │
        ▼                                     │
   More Users ──────► More Value ◄────────────┤
        │               for Users             │
        │                                     │
        ▼                                     │
   More Developers ──► More Apps ─────────────┘
        │
        │
        ▼
   More Integration ──► Harder to Leave

Platform Transition Strategy

From Product to Platform:

Warning signs you're too early:

• Core product not stable
• Less than 1,000 active users
• No demand from customers for extensions
• No budget for developer support

Platform Metrics

Minimum Viable Platform

What you need to launch a platform:

Must Have:
□ Stable, documented APIs
□ Authentication (OAuth)
□ Developer portal/docs
□ Sandbox environment
□ Basic support channel

Should Have:
□ SDKs for major languages
□ Webhooks for events
□ Rate limiting
□ Versioning strategy
□ Sample apps

Nice to Have:
□ Marketplace
□ Partner program
□ Developer community
□ Certification program
□ Revenue sharing

Platform Governance

Decision framework for platform rules:

Platform Risks

Case Studies

Slack: Product → Platform

2014: Chat product
2015: Basic integrations
2016: App directory
2018: Slack Platform
2020: 2,400+ apps, platform moat

Shopify: Platform from Day 1

2006: E-commerce platform
2009: App store launched
2013: Shopify Payments
2020: Shop app, Fulfillment Network
Today: Platform revenue ~30%

Notion: Product (So Far)

2016: Note-taking product
2020: Still no public API
2021: Limited API beta
Approach: Product excellence first

Platform vs Product Decision Checklist

Answer these questions:

□ Can third parties add meaningful value?
  Yes → Platform consideration
  No → Product focus

□ Is there market demand for extensions?
  Yes → Platform consideration
  No → Product focus

□ Do you have resources for developer support?
  Yes → Platform possible
  No → Product focus

□ Will network effects create defensibility?
  Yes → Platform worth investment
  No → Product may be better

□ Is your core product stable and loved?
  Yes → Platform timing may be right
  No → Focus on product first

Anti-Patterns

• Premature platforming — Building platform before product works
• Platform as strategy — "We're a platform" without clear value
• Ignored developers — APIs without support or docs
• Closed gardens — Over-restricting what can be built
• Revenue-first — Monetizing before ecosystem has value
• Feature competition — Building what developers build
• Platform theater — APIs no one uses, marketing says "platform"
• Neglecting core — Platform investment at expense of core product

---

title: Build vs Buy vs Partner impact: MEDIUM-HIGH tags: build, buy, partner, make-vs-buy, strategy

Build vs Buy vs Partner

Impact: MEDIUM-HIGH

Every feature is a choice: build it yourself, buy a solution, or partner with someone who has it. The right choice depends on strategy, not just cost.

The Build/Buy/Partner Framework

                            STRATEGIC IMPORTANCE
                   Low ──────────────────────────── High
                    │                                │
        ┌───────────┴────────────┬───────────────────┴───────────┐
        │                        │                               │
    BUY/PARTNER              EVALUATE                         BUILD
        │                        │                               │
    Commodity                 Important but                Core to
    Not differentiating       not core                     value prop
        │                        │                               │
    Examples:                 Examples:                    Examples:
    - Auth (Auth0)            - Billing (Stripe)           - Core product
    - Email (SendGrid)        - Analytics (Mixpanel)       - Key differentiators
    - Monitoring (Datadog)    - Search (Algolia)           - Unique algorithms

Decision Matrix

When to Build

Build when:

✓ Core to your value proposition
✓ Sustainable competitive advantage
✓ Unique requirements not met by market
✓ Integration complexity makes buy impractical
✓ Volume economics favor in-house
✓ Strategic IP/data you want to own

Don't build when:

✗ Solved problem with good solutions
✗ Not your core competency
✗ Faster alternatives exist
✗ Opportunity cost too high
✗ Maintenance burden distracts from core

When to Buy

Buy when:

✓ Commodity/infrastructure need
✓ Market solutions are mature
✓ Speed to market critical
✓ Not a differentiator
✓ Vendor provides ongoing innovation
✓ Compliance/security better outsourced

Don't buy when:

✗ Core to product differentiation
✗ Vendor lock-in unacceptable
✗ Long-term costs exceed build costs
✗ Customization needs are extreme
✗ Vendor stability questionable

When to Partner

Partner when:

✓ Complementary capabilities needed
✓ Faster market access desired
✓ Distribution channel partnership
✓ Technology integration needed
✓ Credibility/brand association valuable
✓ Shared customer base benefit

Don't partner when:

✗ Misaligned incentives
✗ Core IP at risk
✗ Partner could become competitor
✗ Integration costs high
✗ Dependency creates strategic risk

Total Cost of Ownership (TCO)

Build TCO:

Year 1:
  Engineering time: $200K (2 engineers × 4 months)
  Infrastructure:   $10K
  Opportunity cost: $100K (what else could they build?)
  Total:            $310K

Years 2-5:
  Maintenance (20%): $40K/year
  Infrastructure:    $15K/year
  Total:             $220K

5-Year TCO: $530K

Buy TCO:

Year 1:
  Subscription:      $24K
  Integration:       $20K (1 engineer × 2 weeks)
  Total:             $44K

Years 2-5:
  Subscription:      $24K/year (may increase)
  Integration maint: $5K/year
  Total:             $116K

5-Year TCO: $160K

Vendor Evaluation Framework

Common Build/Buy Decisions

Partnership Types

Partnership Success Factors

Good partnership structure:

1. Clear mutual benefit (not one-sided)
2. Aligned incentives (both profit together)
3. Defined boundaries (who does what)
4. Exit clauses (how to unwind if needed)
5. Success metrics (how to measure)
6. Escalation path (how to resolve issues)

Migration Strategy

From Buy to Build:

Phase 1: Identify limitations of bought solution
Phase 2: Build abstraction layer
Phase 3: Build replacement behind abstraction
Phase 4: Migrate traffic gradually
Phase 5: Deprecate bought solution

From Build to Buy:

Phase 1: Document current functionality
Phase 2: Evaluate vendors against requirements
Phase 3: Build integration with abstraction
Phase 4: Run parallel, validate parity
Phase 5: Deprecate built solution

Anti-Patterns

• NIH Syndrome — Building everything, rejecting external solutions
• Vendor hoarding — Too many vendors, integration complexity
• False economy — Building to save money when time is scarcer
• Lock-in paranoia — Avoiding all vendors, building commodity tools
• Partnership without strategy — Partnering without clear goals
• Build then abandon — Building, but not maintaining
• Ignoring opportunity cost — Not considering what else engineers could build
• One-vendor dependency — Critical function, single vendor, no plan B

---

title: Business Model Design impact: HIGH tags: business-model, revenue, pricing, monetization

Business Model Design

Impact: HIGH

Your business model is how you create, deliver, and capture value. Get it right and everything else gets easier. Get it wrong and you'll struggle no matter how good your product is.

Business Model Canvas

┌─────────────────┬─────────────────┬─────────────────┐
│   KEY           │   VALUE         │   CUSTOMER      │
│   PARTNERS      │   PROPOSITION   │   RELATIONSHIPS │
│                 │                 │                 │
│   Who helps us  │   What unique   │   How do we     │
│   deliver?      │   value?        │   acquire and   │
│                 │                 │   retain?       │
├─────────────────┼─────────────────┼─────────────────┤
│   KEY           │                 │   CHANNELS      │
│   ACTIVITIES    │   [VALUE]       │                 │
│                 │                 │   How do we     │
│   What do we    │                 │   reach         │
│   do?           │                 │   customers?    │
├─────────────────┼─────────────────┼─────────────────┤
│   KEY           │                 │   CUSTOMER      │
│   RESOURCES     │                 │   SEGMENTS      │
│                 │                 │                 │
│   What do we    │                 │   Who do we     │
│   need?         │                 │   serve?        │
├─────────────────┴─────────────────┼─────────────────┤
│        COST STRUCTURE             │ REVENUE STREAMS │
│                                   │                 │
│   What are our major costs?       │ How do we make  │
│                                   │ money?          │
└───────────────────────────────────┴─────────────────┘

SaaS Business Models

Revenue Model Spectrum

Fixed Recurring ─────────────────────────────── Variable/Usage
       │                                               │
   Subscription                                    Usage-Based
   Per-seat                                        Per-transaction
   Platform fee                                    Consumption
       │                                               │
   Predictable                                     Scalable
   Easy to plan                                    Aligns with value
   May limit growth                                Hard to forecast

Choosing Your Revenue Model

Freemium Strategy

When freemium works:

• Large TAM (need volume)
• Low marginal cost per user
• Network effects present
• Clear upgrade trigger

Freemium conversion funnel:

Free Users:          100,000
Active (monthly):    30,000   (30%)
Engaged (weekly):    10,000   (10%)
Power Users:         3,000    (3%)
Paid Converts:       1,500    (1.5%)

Free vs Paid Feature Splits:

Unit Economics

Key Metrics:

The Golden Ratio:

LTV : CAC > 3:1
(If LTV is $3,000, CAC should be < $1,000)

Pricing Architecture

Build pricing that scales:

            ENTERPRISE
           ┌──────────┐
           │ Custom   │  ← High-touch, negotiated
           │ pricing  │
           └────┬─────┘
         BUSINESS
        ┌────────────┐
        │ $XXX/month │  ← Self-serve, annual option
        └────┬───────┘
       PRO/TEAM
      ┌──────────────┐
      │ $XX/month    │  ← Entry point for paid
      └────┬─────────┘
     FREE/STARTER
    ┌────────────────┐
    │ $0             │  ← Lead generation
    └────────────────┘

Value-Based Pricing Framework

Price = Value Delivered × Willingness to Pay

Example:

Customer problem cost:     $100,000/year (lost productivity)
Your solution value:       $60,000/year saved (60%)
Price at 15% of value:     $9,000/year

Monetization Timing

Business Model Innovation Examples

Disruption Patterns:

Anti-Patterns

• Monetizing too early — Charging before value is proven
• Monetizing too late — Free forever, can't convert
• Complex pricing — Customers can't understand/estimate
• Value misalignment — Charging for things customers don't value
• One-size-fits-all — Same price for SMB and Enterprise
• Per-seat when value isn't per-person — Analytics tools charging per seat
• Ignoring unit economics — Growing at negative margins
• Pricing by cost — Instead of by value delivered
• Never changing pricing — Markets and value evolve

---

title: Monetization Strategy impact: HIGH tags: monetization, pricing, revenue, strategy

Monetization Strategy

Impact: HIGH

Monetization is where product value becomes business value. The best monetization strategies align with how customers perceive and receive value.

The Monetization Ladder

   ┌─────────────────────────────────────────────────────────┐
   │  ENTERPRISE CONTRACTS                                   │
   │  Custom pricing, annual, negotiated                     │
   │  $50K+ ACV                                              │
   └─────────────────────┬───────────────────────────────────┘
                         │
   ┌─────────────────────▼───────────────────────────────────┐
   │  PREMIUM TIERS                                          │
   │  Advanced features, higher limits                       │
   │  $5K-50K ACV                                            │
   └─────────────────────┬───────────────────────────────────┘
                         │
   ┌─────────────────────▼───────────────────────────────────┐
   │  PAID PLANS                                             │
   │  Core value, self-serve                                 │
   │  $500-5K ACV                                            │
   └─────────────────────┬───────────────────────────────────┘
                         │
   ┌─────────────────────▼───────────────────────────────────┐
   │  FREE / FREEMIUM                                        │
   │  Acquisition, activation, virality                      │
   │  $0                                                     │
   └─────────────────────────────────────────────────────────┘

Pricing Strategies

1. Value-Based Pricing Price based on value delivered to customer.

Best for: Products with measurable ROI
Example:  Security product saves $500K/year in breach costs
          → Price at $50K/year (10% of value)

2. Competitor-Based Pricing Price relative to alternatives.

Best for: Entering established markets
Example:  Competitors charge $100/seat
          → Price at $80/seat (value position) or
          → Price at $150/seat (premium position)

3. Cost-Plus Pricing Price based on costs plus margin.

Best for: Commoditized products, low differentiation
Example:  Cost $10 to serve, price at $15 (50% margin)
Warning:  Ignores value, often leaves money on table

Pricing Metric Selection

Choose a metric that:

• Scales with customer value
• Is easy to understand
• Customers can predict their bill
• Grows as customers grow

Price Localization

Adjust pricing by market:

Expansion Revenue Strategies

Net Revenue Retention > 100% through:

Monetization Timing Framework

Pricing Page Best Practices

Good Pricing Page:

✓ 3-4 tiers maximum
✓ Most popular tier highlighted
✓ Clear feature comparison
✓ Annual discount visible
✓ Enterprise "contact us" option
✓ Free trial or money-back guarantee
✓ Social proof (logos, testimonials)

Example Tier Structure:

Pricing Experiments

Test pricing safely:

Discounting Strategy

When to discount:

• Annual vs monthly (10-20% discount)
• Startup/nonprofit tiers
• Strategic accounts
• Competitive win-backs

When NOT to discount:

• To close every deal (trains buyers)
• Below profitable unit economics
• Without getting something in return

Healthy discount framework:

First negotiation:    10% for annual
Second ask:           Logo rights / case study
Third ask:            Longer contract term
Hard line:            No further discount

Revenue Diversification

Multiple revenue streams reduce risk:

Pricing Communication

Raising prices? Communicate well:

1. Give advance notice (60-90 days)
2. Explain the why (value added)
3. Grandfather existing contracts
4. Offer annual lock-in at old price
5. Highlight new features/value

Anti-Patterns

• Race to bottom — Competing only on price
• Complex pricing — 10+ tiers, confusing metrics
• Hidden fees — Surprise charges at billing time
• No free trial — Barrier to trying product
• Discounting to everyone — Trains customers to negotiate
• Annual-only — Friction for new customers
• Never raising prices — Leaving money on table
• Charging for wrong thing — Pricing metric misaligned with value
• Same price forever — Ignoring market changes

---

title: Building Competitive Moats impact: HIGH tags: moats, competitive, defensibility, strategy, network-effects

Building Competitive Moats

Impact: HIGH

A moat is what keeps competitors at bay. Without a moat, success attracts copycats. With a strong moat, your competitive advantage compounds over time.

The Moat Framework

                    MOAT STRENGTH
           Weak ─────────────────── Strong
            │                          │
    Features│                          │Network Effects
    UX      │                          │Data Moat
    Price   │                          │Switching Costs
            │                          │Scale Economics
            │                          │Brand
            │                          │Regulatory
            │                          │
   Easy to  │                          │Hard to
   copy     │                          │replicate

Moat Types Ranked

Network Effects Deep Dive

Types of Network Effects:

Network Effect Strength Test:

Strong: Product is nearly useless without network (WhatsApp)
Medium: Product is useful, better with network (Slack)
Weak: Product is mostly standalone (Notion)
None: No network benefit (Superhuman)

Building Network Effects

The Cold Start Problem:

Phase 1: Solve chicken-and-egg
         → Target atomic network (smallest viable)
         → Subsidize one side (free for users)
         → Bring supply to demand (go to where they are)

Phase 2: Achieve network effects
         → Look for engagement tipping point
         → Cross-network connections
         → Viral mechanics

Phase 3: Defend the moat
         → Multi-tenanting prevention
         → Deepen switching costs
         → Expand network value

Switching Costs Strategies

Types of Switching Costs:

Switching Cost Checklist:

□ Data gets more valuable with use
□ Users invest significant learning time
□ Product integrates with 3+ other tools
□ Workflows are customized to product
□ Data export is incomplete or painful
□ Re-implementation cost is high

Data Moat Building

Data becomes a moat when:

• You have data competitors can't get
• Data makes your product better
• More usage = more data = better product
• First-mover advantage compounds

Data Flywheel:

     ┌──────────────────┐
     │                  │
     ▼                  │
More Users ─────► More Data
     │                  │
     │                  │
     ▼                  │
Better Product ◄────────┘

Data Moat Examples:

Scale Economies

When scale creates advantage:

• Fixed costs spread across more users
• Negotiating power with suppliers
• R&D investment amortization
• Infrastructure efficiency

SaaS Scale Examples:

Infrastructure: More users = lower cost per user
Development:    Same R&D serves 1M users as 1K
Support:        Self-serve scales better
Distribution:   Brand awareness compounds

Brand as Moat

Brand moat characteristics:

• Trust built over years
• Association with quality/category
• Word of mouth amplification
• Premium pricing power

Building Brand Moat:

Phase 1: Product excellence → Word of mouth
Phase 2: Category association → "The X for Y"
Phase 3: Trust → Enterprise sales enabled
Phase 4: Premium → Pricing power, resilience

Moat Assessment Framework

For your product, score each moat (1-5):

Moat Building by Stage

Moat Erosion Warning Signs

Watch for these threats:

□ New technology disrupts your advantage
□ Competitor offers free switching/migration
□ Data becomes commoditized
□ Regulation changes market structure
□ Open source alternative emerges
□ Network unbundles (users leave for smaller network)

Multi-Moat Strategy

Strongest companies have multiple moats:

Example: Salesforce

1. Switching costs (data, customization)
2. Network effects (AppExchange ecosystem)
3. Scale (R&D, infrastructure)
4. Brand (category definition)

Each moat reinforces the others.

Moat Investment Prioritization

Where to invest in moat building:

Anti-Patterns

• Moat before PMF — Building defensibility before value
• Feature = moat — Features are copied in months
• Fake network effects — "Social features" that add no value
• Switching cost through friction — Punishing users vs rewarding loyalty
• Data hoarding — Collecting data without using it
• Moat complacency — Assuming moat is permanent
• Single moat dependency — All eggs in one defensive basket
• Ignoring disruption — Not seeing technology shifts eroding moat

---

title: Competitive Positioning and Differentiation impact: HIGH tags: competitive, positioning, differentiation, moats, strategy

Competitive Positioning and Differentiation

Impact: HIGH

Positioning isn't about being better — it's about being different. The goal is to make competition irrelevant by owning a unique space in customer minds.

The Positioning Spectrum

UNDIFFERENTIATED          DIFFERENTIATED            CATEGORY CREATOR
      │                         │                         │
      ▼                         ▼                         ▼
"We're like X                "We're the X             "We invented
 but cheaper"                 for Y segment"            the X category"
      │                         │                         │
  Compete on                Compete on               Compete with
  price (bad)               fit (better)             yourself (best)

Positioning Strategies

Competitive Positioning Map

Plot your position relative to competitors:

                  Premium Pricing
                        │
                        │
            ┌───────────┼───────────┐
            │           │           │
            │    You?   │  Incumbent│
            │           │           │
Niche ──────┼───────────┼───────────┼────── Broad
            │           │           │
            │  Startup  │  Open     │
            │  Competitor│  Source  │
            └───────────┼───────────┘
                        │
                  Value Pricing

Common Position Pairs:

• Premium vs Value
• Niche vs Broad
• Simple vs Feature-rich
• Self-serve vs High-touch
• Modern vs Established

Differentiation Types

Building Competitive Moats

Network Effects:

Type: Direct, Indirect, Data
Example: Slack — more users = more value
Building: Focus on multiplayer features first

Switching Costs:

Type: Data lock-in, workflow dependency, training
Example: Salesforce — years of data and customization
Building: Deep integrations, custom workflows, exports hard

Economies of Scale:

Type: Infrastructure, R&D, distribution
Example: AWS — cheaper at scale than anyone
Building: Volume-based pricing, infrastructure investment

Data Advantages:

Type: Proprietary data, user-generated, training data
Example: Google — search data improves results
Building: Collect unique data, make product better with usage

Competitive Analysis Framework

For each competitor, analyze:

Competitive Response Strategies

Positioning Statement Template

For [target customer] who [situation], [product] is the [category] that [key benefit]. Unlike [primary competitor], [product] [key differentiator].

Good Example:

For mid-market engineering teams who struggle with slow
deployment cycles, Velocity is the CI/CD platform that
cuts build times by 80%. Unlike Jenkins, Velocity requires
zero configuration and scales automatically.

Bad Example:

For everyone who uses computers, SuperApp is the
productivity platform that does everything. Unlike
other tools, we have more features.

Competitive Positioning Canvas

Win/Loss Analysis

Track and analyze every competitive deal:

Won Deals Analysis:
- What did customers value most?
- Where did we beat competition?
- What was the deciding factor?

Lost Deals Analysis:
- Why did we lose?
- What would have changed the outcome?
- Was it fit, feature, or price?

Positioning Evolution by Stage

Early Stage (Pre-PMF):

• Position as niche dominator
• Own a specific segment deeply
• Don't compete with leaders head-on

Growth Stage (Post-PMF):

• Expand positioning incrementally
• Add adjacent segments
• Build category credibility

Scale Stage:

• Position as category leader
• Define the category in your terms
• Acquire to fill gaps

Anti-Patterns

• Feature parity obsession — Chasing competitors' features
• Positioning by negation — "We're not Salesforce"
• Broad positioning — Trying to be everything to everyone
• Price-based positioning — Race to the bottom
• Technology positioning — "Built on Kubernetes" (no one cares)
• Buzzword positioning — "AI-powered enterprise solution"
• Ignoring incumbents — Pretending competition doesn't exist
• Repositioning constantly — Confuses market and team

---

title: Product-Market Fit Assessment impact: CRITICAL tags: market, pmf, product-market-fit, validation, growth

Product-Market Fit Assessment

Impact: CRITICAL

Product-market fit is when the market pulls the product from you. Before PMF, nothing else matters. After PMF, everything accelerates.

The PMF Spectrum

Level 0: Problem Fit
"We've found a problem worth solving"
Signals: User research confirms pain, willingness to pay indicated

Level 1: Solution Fit
"Our solution addresses the problem"
Signals: Users complete core workflow, positive feedback

Level 2: Product-Market Fit
"Customers are pulling the product from us"
Signals: Organic growth, retention, word of mouth

Level 3: Scale Fit
"We have a repeatable growth engine"
Signals: Unit economics work, channels are predictable

Level 4: Moat Fit
"We have defensible competitive advantage"
Signals: High switching costs, network effects, brand

PMF Measurement Framework

The Sean Ellis Test: "How would you feel if you could no longer use [product]?"

Quantitative PMF Indicators

Qualitative PMF Signals

You have PMF when:

□ Users complain when the product is down
□ Users recommend without being asked
□ Users hack the product to do more than intended
□ Users ask for features, not refunds
□ You can't keep up with demand
□ Competitors start copying you
□ Users integrate you into their daily workflow
□ Churn rate declining each cohort

You don't have PMF when:

□ Growth only from sales/marketing push
□ High churn across all cohorts
□ Users say "nice" but don't return
□ Engagement drops after first week
□ You're explaining why users should care
□ Need constant discounts to retain
□ Users request things that aren't core to vision

The PMF Canvas

PMF By Company Stage

Pre-Seed to Seed: Focus on Problem Fit and Solution Fit

Key activities:
- 50+ customer interviews
- 10+ users in pilot
- Qualitative validation

Seed to Series A: Focus on achieving initial PMF

Key metrics:
- 100+ paying customers
- 40%+ "very disappointed" score
- Improving retention curves

Series A to B: Focus on PMF scale and repeatability

Key metrics:
- Predictable acquisition channels
- Consistent cohort metrics
- Unit economics positive

The Superhuman PMF Engine

Step 1: Survey users
        "How disappointed would you be?"

Step 2: Segment responses
        Focus on "very disappointed" segment

Step 3: Analyze why
        What do very disappointed users love?
        What do somewhat disappointed users want?

Step 4: Build for very disappointed
        Double down on what's working

Step 5: Repeat weekly
        Track % very disappointed over time

Common PMF Mistakes

Fake PMF Warning Signs

Revenue from a few large customers:

• 1-2 customers = 80% revenue
• Custom development for each
• Not replicable

Paid-only growth:

• CAC increasing over time
• No organic word of mouth
• Turn off ads, growth stops

Founder-led sales only:

• Only founders can close deals
• Can't hire salespeople to replicate
• Process isn't documented

PMF Recovery Playbook

If you've lost PMF or never had it:

Week 1-2:  Talk to 20 churned customers
           → Why did they leave?

Week 3-4:  Talk to 20 power users
           → Why do they stay?

Week 5-6:  Find the delta
           → What's different about retained users?

Week 7-8:  Narrow ICP
           → Who are your power users?

Week 9+:   Rebuild for narrow segment
           → 100 users who love > 1,000 who like

Anti-Patterns

• Declaring PMF too early — One viral moment isn't PMF
• Moving past PMF — Scaling features before nailing core
• Surveying wrong users — Surveying prospects, not users
• Ignoring churn reasons — Focusing on acquisition, not retention
• Changing too many variables — Can't learn if changing everything
• Building for churned users — They already decided you're not for them

---

title: Market Opportunity Sizing (TAM/SAM/SOM) impact: CRITICAL tags: market, tam, sam, som, opportunity, sizing

Market Opportunity Sizing (TAM/SAM/SOM)

Impact: CRITICAL

Market sizing isn't about impressing investors with big numbers. It's about understanding where you can realistically win and how big the opportunity truly is.

The TAM/SAM/SOM Framework

┌─────────────────────────────────────────────────────────────────┐
│                            TAM                                  │
│                  Total Addressable Market                       │
│        "If we had 100% market share, how big?"                  │
│                                                                 │
│    ┌───────────────────────────────────────────────────┐       │
│    │                       SAM                          │       │
│    │            Serviceable Addressable Market          │       │
│    │       "Segment we can actually reach & serve"      │       │
│    │                                                    │       │
│    │    ┌────────────────────────────────────┐         │       │
│    │    │              SOM                    │         │       │
│    │    │      Serviceable Obtainable Market  │         │       │
│    │    │    "Realistic capture in 3-5 years" │         │       │
│    │    └────────────────────────────────────┘         │       │
│    └───────────────────────────────────────────────────┘       │
└─────────────────────────────────────────────────────────────────┘

TAM Calculation Methods

1. Top-Down (Quick, less accurate) Start with industry reports, narrow down.

Example: Project Management Software

Global software market:           $500B
× Enterprise software %:          × 20%   = $100B
× Productivity software %:        × 15%   = $15B
× Project management %:           × 25%   = $3.75B TAM

2. Bottom-Up (More work, more accurate) Build from unit economics up.

Example: Project Management Software

Companies with 50+ employees:         500,000 globally
× Avg seats per company:              × 50
= Total potential seats:              25,000,000
× Price per seat per year:            × $120
= TAM:                                $3B

3. Value-Theory (Best for new categories) Calculate based on value delivered.

Example: AI Code Assistant

Developer hours saved per week:       5 hours
× Developer hourly cost:              × $75
× Weeks per year:                     × 50
= Value per developer per year:       $18,750
× Developers globally:                × 30M
× Willingness to pay (10%):           × 10%
= TAM:                                $56B

SAM Refinement

SAM = TAM × Filters

SAM Calculation Example:

TAM:                    $3B
× Geography (NA):       × 40%    = $1.2B
× Company size:         × 25%    = $300M
× Has budget:           × 60%    = $180M SAM

SOM Reality Check

SOM answers: "What can we realistically capture in 3-5 years?"

SOM Calculation Example:

SAM:                    $180M
× Realistic share (15%): × 15%
= SOM:                  $27M in 3-5 years

Market Sizing Sanity Checks

The "So What?" Tests:

Good vs Bad Market Sizing

Good Sizing (Investor-Ready):

TAM: $15B
- Global enterprise communication tools
- Source: Gartner 2024, growing 12% CAGR

SAM: $3B
- Mid-market companies (100-1000 employees)
- North America and Europe
- Technology and professional services verticals

SOM: $150M (Year 5)
- 5% of SAM
- Based on comparable company trajectories
- Assumes $50M ARR current → $150M ARR

Bad Sizing (Red Flags):

TAM: $500B
- "If every company in the world uses us..."

SAM: $100B
- "Everyone who uses computers..."

SOM: $10B
- "We just need 2% of the market"

Market Dynamics to Consider

Growing vs Shrinking Markets:

Fragmented vs Concentrated:

Adjacent Market Expansion

            ┌─────────────────┐
            │   CORE MARKET   │
            │   (Start Here)  │
            └────────┬────────┘
                     │
         ┌──────────┴──────────┐
         │                      │
    ┌────▼────┐           ┌────▼────┐
    │ ADJACENT │           │ ADJACENT │
    │ MARKET A │           │ MARKET B │
    │ (Geo)    │           │ (Product)│
    └────┬────┘           └────┬────┘
         │                      │
         └──────────┬──────────┘
                    │
              ┌─────▼─────┐
              │  ADJACENT  │
              │  MARKET C  │
              │  (Segment) │
              └────────────┘

Expansion Types:

• Geographic: NA → Europe → APAC
• Segment: SMB → Mid-market → Enterprise
• Product: Core → Adjacent features → Platform

Investor-Ready Market Analysis

What investors want to see:

1. Bottom-up TAM with clear assumptions
2. SAM that matches your current product
3. SOM that's achievable in 3-5 years
4. Clear path from SOM → SAM (expansion story)
5. Growing market (10%+ CAGR)
6. Credible data sources cited

Anti-Patterns

• TAM theater — Using absurdly large numbers to impress
• Top-down only — "It's a $100B market, we just need 1%"
• Ignoring competition — Sizing without competitive context
• Static sizing — Not accounting for market growth/decline
• One-time sizing — Markets change; re-assess annually
• SAM = TAM — No meaningful segmentation
• SOM optimism — Assuming unrealistic market share
• Category confusion — Mixing categories to inflate numbers

---

title: Product Strategy Frameworks impact: HIGH tags: strategy, frameworks, prioritization, decision-making

Product Strategy Frameworks

Impact: HIGH

Strategy is the art of making choices. Good frameworks help you make better choices faster — and explain them to others.

The Strategy Stack

VISION      →  "Where are we going?"            (3-10 years)
                Aspirational, inspiring

STRATEGY    →  "How will we get there?"         (1-3 years)
                Trade-offs, focus areas

ROADMAP     →  "What are we building?"          (Quarters)
                Prioritized initiatives

OKRs        →  "How do we measure progress?"    (Quarterly)
                Objectives and key results

SPRINTS     →  "What are we doing this week?"   (Weeks)
                Tasks and deliverables

Strategy Definition

Good strategy has three parts:

1. Diagnosis — What's the challenge?
2. Guiding Policy — What's our approach?
3. Coherent Actions — What will we do?

Example:

Diagnosis:      Enterprise customers want to buy but our product
                lacks SOC 2 compliance and SSO.

Guiding Policy: We will become enterprise-ready in 2024 by
                prioritizing security and compliance features
                over new functionality.

Coherent Actions:
1. Achieve SOC 2 Type II by Q2
2. Ship SSO with SAML/OIDC by Q1
3. Add audit logging by Q2
4. Hire compliance lead by Q1

Prioritization Frameworks

1. RICE Scoring

RICE Score = (Reach × Impact × Confidence) / Effort

2. Value vs Effort Matrix

                    High Value
                        │
              ┌─────────┼─────────┐
              │ QUICK   │  BIG    │
              │ WINS    │  BETS   │
   Low ───────┼─────────┼─────────┼─────── High
   Effort     │ DON'T   │  TIME   │  Effort
              │ BOTHER  │  SINKS  │
              └─────────┼─────────┘
                        │
                    Low Value

3. The MoSCoW Method

Strategic Trade-off Framework

For every decision, identify what you're trading:

Good strategy makes trade-offs explicit:

"We choose depth over breadth — we will be the best at
X rather than good at X, Y, and Z."

Decision Making Framework

Type 1 vs Type 2 Decisions:

Examples:

Type 1 (Go Slow):
- Business model change
- Major platform decisions
- Entering new markets
- Pricing architecture

Type 2 (Go Fast):
- Feature prioritization
- UI/UX decisions
- Pricing levels
- Marketing experiments

Porter's Five Forces (Simplified)

Jobs to Be Done Framework

Focus on the job, not the solution:

Traditional:    "We need to add a calendar feature"

JTBD:           "When I'm scheduling a meeting, I want to
                avoid back-and-forth emails, so I can
                book meetings in one interaction"

JTBD Template: When [situation], I want to [motivation], so I can [outcome].

Strategy Validation Checklist

Before committing to a strategy:

□ Does this support our vision?
□ Is this achievable with our resources?
□ Does this address our biggest challenge?
□ Are trade-offs explicit?
□ Can we measure progress?
□ Do we have conviction? (Would we bet the company?)
□ Is the team aligned?
□ Can we explain it in one sentence?

Quarterly Strategy Review

Anti-Patterns

• Strategy as planning — Plans aren't strategy; strategy is choices
• Strategy by consensus — Trying to make everyone happy
• Too many priorities — If everything is a priority, nothing is
• Copying competitors — Reactive, not proactive
• Strategy without trade-offs — "We'll do both" isn't strategy
• Annual-only planning — Strategy needs continuous refinement
• Mistaking tactics for strategy — "Launch on ProductHunt" is a tactic
• No diagnosis — Jumping to solutions without understanding problems

---

title: Strategic Roadmap Planning impact: HIGH tags: roadmap, planning, strategy, prioritization

Strategic Roadmap Planning

Impact: HIGH

A roadmap is strategy made visible. It's not a commitment to ship specific features — it's a communication tool that shows how you'll achieve your strategy.

Roadmap Types

Roadmap Anatomy

VISION (2-5 years)
"Where we're going"
├── THEME 1: Become enterprise-ready
├── THEME 2: Expand to new verticals
└── THEME 3: Build platform ecosystem

STRATEGIC (1 year)
"Major bets for the year"
├── Q1-Q2: Security & compliance features
├── Q2-Q3: Healthcare vertical launch
└── Q3-Q4: API & integrations platform

PRODUCT (Quarters)
"What we're building"
├── Now: SSO/SAML, audit logging
├── Next: HIPAA compliance, healthcare templates
└── Later: Public API, developer portal

Theme-Based Roadmapping

Why themes over features:

• Allows flexibility in execution
• Communicates intent without commitment
• Enables customer feedback on direction
• Avoids the "feature factory" trap

Good Themes:

✓ "Enterprise-ready security"
✓ "Self-serve onboarding excellence"
✓ "Mobile-first experience"
✓ "Platform extensibility"

Bad Themes (Too Specific):

✗ "Build SSO with SAML support"
✗ "Add dark mode and 10 new integrations"
✗ "Migrate to new database"

Roadmap Pillars

Balance roadmap across dimensions:

Now/Next/Later Framework

NOW (This Quarter)
├── SSO with SAML/OIDC
├── Audit logging for compliance
└── Self-serve team management

NEXT (Next Quarter)
├── SOC 2 Type II certification
├── Role-based access controls
└── Security dashboard

LATER (Future)
├── Enterprise security suite
├── Advanced compliance features
└── Security integrations

Roadmap Inputs

Balanced input framework:

Customer Feedback Integration

How to process feature requests:

Feedback Funnel:

All Requests (1000)
      │
      ▼
Validated Requests (200)  ← "Would they pay for this?"
      │
      ▼
Strategic Fit (50)        ← "Does this align with vision?"
      │
      ▼
Prioritized (10)          ← "What's the impact/effort?"
      │
      ▼
Roadmap (5)              ← "What makes the cut?"

Stakeholder Communication

What different audiences need:

Roadmap Artifacts

External Roadmap (Customers):

Theme-based, quarter-level, no specific dates
"In Q2, we're focused on enterprise security"

Internal Roadmap (Team):

Feature-level, milestone-based, clear owners
"SSO ships March 15, owned by Platform team"

Board Roadmap:

Strategic themes, annual view, metrics
"Enterprise segment = 40% of 2024 focus"

Roadmap Review Cadence

Roadmap vs Backlog

Saying No

How to decline roadmap requests:

Good: "That's not on our roadmap for the next two quarters
       because we're focused on [strategic priority]. We'll
       revisit in Q3 when we plan the second half."

Bad:  "We can't do that."
Bad:  "Maybe someday."
Bad:  "Let me add it to the backlog." (and forget it)

Roadmap Anti-Patterns

• Date-driven roadmap — Commitments to dates, not outcomes
• Feature factory — List of features without strategic context
• Customer-driven only — Building whatever loudest customers want
• Static roadmap — Never updating as you learn
• Secret roadmap — Team doesn't know the plan
• Overcommitted roadmap — 200% of capacity planned
• No roadmap — Purely reactive, no proactive direction
• Competitor roadmap — Just copying competitor features
• Roadmap as promise — Treating themes as commitments
• Kitchen sink — Everything on roadmap, no prioritization

---

title: Product Vision and North Star Metrics impact: CRITICAL tags: vision, mission, metrics, north-star, strategy

Product Vision and North Star Metrics

Impact: CRITICAL

Vision is your destination. North star metrics tell you if you're on course. Without both, you're navigating without a compass.

The Vision Stack

PURPOSE         →  "Why do we exist?"
                    (Company level, rarely changes)

VISION          →  "What does the future look like?"
                    (3-10 years, inspiring, specific)

MISSION         →  "How do we achieve the vision?"
                    (Operational, actionable)

STRATEGY        →  "What trade-offs do we make?"
                    (1-3 years, focused)

Crafting Product Vision

Great vision characteristics:

• Specific enough to guide decisions
• Inspiring enough to motivate teams
• Ambitious enough to attract talent
• Believable enough to seem achievable

Vision Formula

For [target customers], [product name] will be the [category] that [key transformation], creating a world where [better future state].

Good vs Bad Vision Examples

North Star Metric Framework

Your north star should:

1. Reflect value delivered — Measures customer success, not business success
2. Lead to revenue — Eventually, if customers get value, you make money
3. Be actionable — Teams can influence it
4. Be measurable — Can track progress weekly/monthly

North Star by Business Type

Example: Slack's Metric Evolution

Early Stage:     Messages sent per user
                 (Measures adoption)

Growth Stage:    Daily active users
                 (Measures habit)

Scale Stage:     Messages sent in channels with 3+ active users
                 (Measures collaboration value)

Input vs Output Metrics

                    NORTH STAR (Output)
                          │
            ┌─────────────┼─────────────┐
            │             │             │
            ▼             ▼             ▼
     ┌──────────┐  ┌──────────┐  ┌──────────┐
     │  Input   │  │  Input   │  │  Input   │
     │ Metric 1 │  │ Metric 2 │  │ Metric 3 │
     │ Signups  │  │ Activatn │  │ Features │
     │          │  │ Rate     │  │ Adopted  │
     └──────────┘  └──────────┘  └──────────┘

Vision-to-Metrics Alignment

Testing Your North Star

The "So What" Test:

• If this metric doubles, does the business meaningfully improve?
• If this metric halves, are we in trouble?
• Can every team contribute to moving this?

The "Gaming" Test:

• Can this be artificially inflated without real value?
• Does optimizing for this create perverse incentives?

Anti-Patterns

Vision Anti-Patterns:

• Too vague — "Build great products" (means nothing)
• Too narrow — "Be the #1 CRM" (ceiling, not destination)
• Competitor-defined — "Beat Salesforce" (not inspiring)
• Technology-first — "Be the AI company" (how, not why)

North Star Anti-Patterns:

• Revenue as north star — Lags value delivery, not actionable
• Vanity metrics — Signups without activation, followers without engagement
• Too many metrics — If everything is a north star, nothing is
• Unchanging metrics — North star should evolve with company stage

Implementation Checklist

□ Vision can be explained in one sentence
□ Vision answers "what does success look like in 5 years?"
□ Team can recite the vision
□ North star metric identified
□ Input metrics mapped to north star
□ Every team has line of sight to north star
□ Weekly review of north star progress
□ Quarterly review of metric validity