{
  "schema_version": 1,
  "skill_name": "product-strategy",
  "evals": [
    {
      "id": "north-star-metric",
      "prompt": "We are a B2B analytics product and need a North Star metric to align the company. The team is proposing daily active users, but I worry it rewards cheap usage over delivered value. How should we define our North Star metric and how do we keep it honest?",
      "expected_output": "A North Star metric definition that starts from the core value users receive rather than the cheapest engagement signal: for a B2B analytics product, a metric such as weekly reporting frequency per workspace or number of teams with a produced report, tied to the moment a user gets value from the product. The response explains why raw DAU is risky as a North Star for a B2B product (it rewards logging in, not outcomes) and shows how to validate the chosen metric against retention and paid-plan correlation before committing. It defines the guardrail metrics that prevent gaming (if the North Star rises while activation or retention falls, the metric is wrong) and explains how the metric cascades into team-level metrics without every team inheriting the same number.",
      "assertions": [
        "The response ties the North Star to delivered value rather than cheap engagement such as DAU",
        "The proposed metric is validated against retention or paid-plan correlation before adoption",
        "The response explains why raw DAU is a risky North Star for a B2B product",
        "Guardrail metrics are defined so a rising North Star with falling health signals is caught",
        "The response cascades the metric into team-level metrics without forcing one number everywhere"
      ]
    },
    {
      "id": "competitive-positioning-analysis",
      "prompt": "A well-funded competitor just launched a cheaper version of our product. I need to understand whether this is a real threat and how to position against it, before we react by cutting price. What analysis should I run?",
      "expected_output": "A competitive analysis that separates signal from noise: an assessment of where the competitor actually wins (feature set, price, distribution, customer segment), an honest capability comparison against our product across the dimensions customers care about, and a segment analysis of which customers the cheaper offering genuinely threatens versus which are underserved by it. The response explicitly pushes back on reflexive price-cutting by analyzing whether the competitor's customers are price-driven segments we do not currently serve or core customers who would leave for features, not price. It positions the response around our defensible differentiators and the customers whose needs the competitor does not meet, and it sets up monitoring for the signs that the threat is real (share loss in our core segment, win-rate changes).",
      "assertions": [
        "The response analyzes which segments the competitor genuinely threatens versus which they underserve",
        "It compares capabilities on the dimensions customers actually care about",
        "The response pushes back on reflexive price-cutting and analyzes what would drive real defection",
        "Positioning is built around defensible differentiators, not reactive pricing",
        "The response sets up monitoring signals such as win-rate and segment share changes"
      ]
    },
    {
      "id": "tam-sam-som-sizing",
      "prompt": "We are a team-collaboration tool and need a market-size estimate for an investor deck. How do I build TAM, SAM, and SOM credibly without inventing numbers, and what should the numbers actually claim?",
      "expected_output": "A market sizing built top-down and bottom-up with the numbers reconciled: TAM from a defensible unit model (number of knowledge workers or teams in the target geographies times a credible per-seat spending benchmark), SAM narrowed by the segments the product actually serves (region, company size, category budget), and SOM grounded in what the business can actually capture within a stated horizon given go-to-market capacity and observed win rates. The response explains the source and assumption for each number, cross-checks the top-down estimate against a bottom-up calculation from customer counts and pricing, and states the sizing claims in ranges with the key assumptions exposed so the deck number is defensible rather than aspirational.",
      "assertions": [
        "The response builds TAM, SAM, and SOM with a stated unit model for each",
        "Top-down estimates are cross-checked against a bottom-up calculation",
        "SOM is grounded in go-to-market capacity and observed win rates within a stated horizon",
        "Assumptions and sources are exposed for each number",
        "The sizing is presented as ranges with defensible claims, not single aspirational figures"
      ]
    },
    {
      "id": "roadmap-prioritization-framework",
      "prompt": "Our roadmap is a collection of what the loudest customer asked for last. I want to introduce a prioritization framework across strategy, product, and engineering without turning planning into a bureaucracy. How do I choose and run one?",
      "expected_output": "A prioritization approach that picks the framework by decision type rather than applying one everywhere: strategic bets by the executive team (using a framework suited to options and trade-offs), feature-level prioritization by product using a scored model like RICE or a weighted opportunity model, and engineering sequencing by cost and dependency. The response explains how to run it without bureaucracy: a single shared backlog with the scoring inputs visible, scores treated as input to a discussion rather than a verdict, a monthly cadence where the framework output is reviewed and adjusted, and a rule that anyone can propose but the scoring inputs must be evidence-backed. It covers how the framework connects strategy to roadmap so top-level bets constrain what gets prioritized.",
      "assertions": [
        "The response matches frameworks to decision types: strategy, feature priority, and engineering sequencing",
        "The process keeps scoring inputs visible and treats scores as discussion input, not verdict",
        "The cadence is lightweight, such as a monthly review, without heavy process",
        "Proposals require evidence-backed scoring inputs",
        "Strategic bets constrain feature-level prioritization so the roadmap follows strategy"
      ]
    },
    {
      "id": "product-market-fit-assessment",
      "prompt": "We have been selling our developer tool for eight months. Usage is growing but churn is noticeable. Investors ask if we have product-market fit. How do I assess this rigorously rather than with vibes?",
      "expected_output": "A product-market-fit assessment built from evidence across the standard signals: a Sean Ellis-style survey of active users (the share who would be very disappointed without the product, with the 40% benchmark contextualized for a developer tool), retention cohort analysis showing whether usage stabilizes or decays for each acquisition cohort, the qualitative pattern of how users found and adopted the product (organic pull versus sales push), and the economic test of whether the value delivered exceeds acquisition cost per retained user. The response explains how to interpret mixed signals honestly: a product can be loved by a segment and fail on others, so fit is assessed per segment, and it prescribes what to do next based on where the evidence lands rather than declaring fit from a single metric.",
      "assertions": [
        "The response uses multiple signals: disappointment surveys, retention cohorts, organic adoption, and unit economics",
        "The 40% benchmark is contextualized for the product type rather than applied mechanically",
        "Fit is assessed per segment, allowing for mixed signals",
        "Retention cohort analysis shows whether usage stabilizes or decays",
        "The response prescribes next steps from the evidence pattern rather than declaring a verdict from one metric"
      ]
    }
  ]
}

# Competitive Analysis & Positioning

## Competitive Analysis Framework

### The Competitive Landscape Map

Plot competitors on two axes that matter most to your market:

| Axis | Description | Example axes |
|------|-------------|-------------|
| **X-axis** | Feature depth vs breadth | Specialized ↔ General purpose |
| **Y-axis** | Price/positioning | Premium ↔ Budget |
| **Bubble size** | Market share or revenue | Indicates scale |

### Porter's Five Forces

| Force | Questions | Implication |
|-------|-----------|-------------|
| **Threat of new entrants** | How high are barriers to entry? (Capital, distribution, regulatory, network effects) | Low barriers → constant competition on price |
| **Bargaining power of suppliers** | Are key inputs concentrated? Can suppliers forward-integrate? | High power → margin pressure |
| **Bargaining power of buyers** | How easy is switching? Are buyers price-sensitive? | High power → need to differentiate |
| **Threat of substitutes** | What adjacent solutions solve the same need differently? | Many substitutes → price ceiling |
| **Industry rivalry** | How intense is current competition? | Intense → zero-sum market share battles |

### Blue Ocean vs Red Ocean

| Dimension | Red Ocean (Competing) | Blue Ocean (Creating) |
|-----------|----------------------|----------------------|
| Market | Compete in existing market space | Create uncontested market space |
| Demand | Beat the competition | Make competition irrelevant |
| Strategy | Exploit existing demand | Create and capture new demand |
| Tradeoffs | Value-cost tradeoff | Pursues differentiation and low cost simultaneously |
| System | Align whole system with differentiation or low cost | Align whole system in pursuit of differentiation and low cost |

## Positioning Methodology (April Dunford's Framework)

Positioning is not your tagline — it's the context you create for your product in the market. It defines *who* your product is for, *what* it does, and *why* that matters.

### The 10-Step Positioning Process

1. **Understand the customers who love you** — Who are your best-fit customers? What do they all have in common?
2. **Identify your competitive alternatives** — What do customers use *instead* of your product? (Could be a competitor, a manual process, or doing nothing)
3. **Determine your unique capabilities** — What can you do that alternatives can't? Be specific.
4. **Identify the value of those capabilities** — What outcome do those capabilities unlock for the customer?
5. **Find your best market** — Which customer segment cares most about this value? This is your beachhead.
6. **Map the market alternatives** — How are customers currently solving this? Position yourself *relative* to them.
7. **Create a positioning concept** — One sentence that captures who you are, what you do, and why it matters.
8. **Build your positioning validation** — Test it with customers. Do they recognize themselves? Do they believe the claims?
9. **Craft your message** — Now write the tagline, value prop, and supporting narrative.
10. **Operationalize** — Embed positioning in product, sales, marketing, and support.

### The Positioning Diagnostic

When positioning is wrong, you see symptoms:

| Symptom | Likely root cause |
|---------|-------------------|
| "I don't understand what you do" | Value proposition is unclear or too generic |
| "How are you different from X?" | Insufficient differentiation |
| "Who is this for?" | Market definition is too broad |
| "It sounds like [competitor]" | You're positioning against the wrong alternative |
| "That's interesting, but we're not interested" | The market segment doesn't need what you uniquely do |

### The Positioning Statement Template

```
For [target customer segment]
who [current alternative for solving the problem],
[product name] is a [category/new category]
that provides [key capability].
Unlike [alternative],
[product name] [key differentiation].
```

## Differentiation Strategies

### Types of Differentiation

| Type | Description | Example |
|------|-------------|---------|
| **Product** | Features, performance, design | Apple's UX polish |
| **Price** | Cost leadership or premium | Walmart (low cost) vs Patagonia (premium) |
| **Experience** | Service, onboarding, support | Zappos' customer service |
| **Distribution** | Channels, availability | Coca-Cola's shelf presence |
| **Brand** | Trust, identity, status | Nike's brand equity |
| **Ecosystem** | Integration, network effects | Salesforce AppExchange |

### The Differentiation Test

For each claimed differentiator, ask:

1. **Relevant** — Does the customer care about this?
2. **Credible** — Can we prove it? (Data, case studies, benchmarks)
3. **Unique** — Can competitors credibly claim the same thing?
4. **Durable** — How long before competitors catch up?

If any answer is "no," it's not a real differentiator.

## Competitive Response Playbook

### When a Competitor Launches Against You

| Situation | Response |
|-----------|----------|
| They match your core feature | Don't panic. Move upmarket or deepen your differentiator. Feature parity without context is not a threat. |
| They undercut on price | If you can't compete on price, don't. Compete on value, switching costs, or service. |
| They copy your positioning | If your positioning is well-connected to actual product experience, copying the positioning reveals their weakness. Let them be seen as an imitator. |
| They enter your beachhead segment | Double down on your best customers. Often, the new entrant's initial users are your weakest users who would churn anyway. |

### Defensive Moves

- **Strengthen switching costs** — Integrations, data portability, workflows users can't easily recreate
- **Raise barriers** — Patents, network effects, exclusive partnerships, brand equity
- **Segment retreat** — Cede low-value segments to competitors; reinforce defensible high-value segments
- **Platform lock-in** — Make your product more valuable as more of the customer's workflow lives in it

### Offensive Moves

- **Flanking** — Attack competitors' weaker segments
- **Encirclement** — Surround a competitor with a broader platform play
- **Guerrilla** — Targeted price cuts, feature releases timed to competitor launches, comparison marketing
- **Disruption** — Change the basis of competition entirely (new business model, technology, or channel)

# Market Analysis

## TAM / SAM / SOM — Deep Dive

### TAM (Total Addressable Market)

The total revenue opportunity if your product achieved 100% market share in a defined market.

**Top-down method:**
```
TAM = Number of potential customers × Average revenue per customer
```

Sources: Industry analyst reports (Gartner, Forrester, IDC), government statistics (NAICS codes), trade associations, public company filings (10-Ks).

**Bottom-up method:**
```
TAM = Price × number of units the entire market buys
```

More credible than top-down because it's grounded in transactional reality.

**Pitfall:** TAM inflation. If you define your market as "every company that uses software," the TAM is meaningless. Narrow to the specific use case your product addresses.

### SAM (Serviceable Addressable Market)

The portion of TAM your product and distribution channels can realistically reach.

**Filters:**
- Geographic — "We only sell in the US and EU"
- Channel — "We sell via Shopify App Store, not enterprise sales"
- Product fit — "Our product requires a modern tech stack"
- Segment — "SMBs only (under 500 employees)"

```
SAM = TAM × (% of market reachable via our channels)
```

### SOM (Serviceable Obtainable Market)

The portion of SAM you can realistically capture given your team, capital, and competitive position — typically over a 12-36 month horizon.

**Bottom-up (most credible):**
```
SOM = Sales capacity × Average deal size × (1 - churn rate) × Time
```

- Sales capacity: Number of reps × deals per rep per month
- Marketing capacity: CAC × budget → number of new customers
- Time horizon: Usually 12-24 months for startup fundraising, 36 months for strategic planning

## Product-Market Fit Assessment

### The PMF Pyramid

```
        ┌─────────────┐
        │  Retention  │  ← Core indicator of PMF
        ├─────────────┤
        │  Activation │  ← Do users get value in the first session?
        ├─────────────┤
        │ Acquisition │  ← Can you reach users efficiently?
        ├─────────────┤
        │  Product    │  ← Does the product solve a real need?
        └─────────────┘
```

PMF is layered. You can't have retention without activation, or activation without acquisition, or acquisition without a product-market need.

### PMF Signals

| Signal | What to look for | Red flag |
|--------|------------------|----------|
| **Organic growth** | W-o-M referrals, inbound requests | Zero organic — all paid |
| **Retention** | Flattening retention curve at 30-60-90 days | Continuous downward slope |
| **Usage depth** | Power users who use >5x per week | Everyone uses sporadically |
| **Paying willingness** | High conversion from free to paid | Users love it but won't pay |
| **Churn reason** | "Couldn't get value" (bad PMF) vs "went out of business" (sales problem) | "Didn't see the need anymore" |
| **NPS at scale** | >40 with high response rate | Low response rate or <10 NPS |

### When PMF Is Strong vs Weak

| Strong PMF | Weak PMF |
|------------|----------|
| Users who hit the "aha moment" stay for months | Users try, plateau, and leave |
| 40%+ would be "very disappointed" if you disappeared | <20% would be disappointed |
| Net revenue retention >100% (existing customers spend more over time) | Net revenue retention <80% |
| Hard to scale because demand overwhelms capacity | Hard to scale because nobody cares |
| Sales-led growth works because users bring the product to their org | Sales-led growth fails because there's no bottom-up pull |

## Market Entry Strategy

### Beachhead Selection

Choose your first market segment using these criteria:

| Criterion | Weight | Question |
|-----------|--------|----------|
| **Need** | High | Does this segment urgently need what you build? |
| **Access** | High | Can you reach them cost-effectively? |
| **Competition** | Medium | Is the segment underserved by incumbents? |
| **Budget** | High | Do they have money to spend? |
| **Reference value** | Medium | Will winning here help you win adjacent segments? |
| **Scale** | Low | Is the segment large enough to matter? |

**The beachhead test:** Pick a segment where you can achieve market leadership with a focused offering. If you can't own this segment, pick a narrower one.

### Land-and-Expand

| Phase | Goal | Strategy |
|-------|------|----------|
| **Land** | Get one foot in the door | Solve a specific, painful problem for one team/department |
| **Prove** | Demonstrate measurable ROI | Track adoption, usage, and outcomes rigorously |
| **Expand** | Grow within the account | Add users, teams, use cases, integrations |
| **Entrench** | Become infrastructure | Embed in workflows, data, and processes |

### Platform Entry Strategy

When entering as a platform (not a point solution):

1. **Start with a killer app** — The platform needs one iconic use case that drives adoption
2. **Then open the API** — Once users are on the platform, let them extend it
3. **Then build an ecosystem** — Third-party developers extend reach
4. **Then move up the stack** — Add higher-value capabilities on top of the platform

## Product Lifecycle Management

### The PLC Stages

| Stage | Revenue | Profit | Cash flow | Team focus |
|-------|---------|--------|-----------|------------|
| **Introduction** | Low, growing slowly | Negative | Heavy burn | Product-market fit |
| **Growth** | Rapid growth | Breakeven → positive | Moderate burn → cash-flow-positive | Scale |
| **Maturity** | Slowing growth | Peak | Strong generator | Efficiency, segmentation |
| **Decline** | Declining | Declining | Decreasing | Harvest or pivot |

### Lifecycle Decisions

| Decision point | Introduction | Growth | Maturity | Decline |
|----------------|-------------|--------|----------|---------|
| **Investment** | Heavy (finding PMF) | Heavy (scaling) | Selective (segments) | Minimal (harvesting) |
| **Pricing** | Skim or penetrate | Maintain or optimize | Defend or bundle | Cut |
| **Distribution** | Direct, selective | Broaden channels | Optimize channels | Reduce |
| **Competition** | Few early entrants | More entrants | Many competitors | Consolidation |
| **Product** | Core features | Expand horizontally | Segment-specific variants | Reduce SKUs |

### The S-Curve

Products follow S-curves: slow adoption → rapid growth → plateau. The strategic challenge is to invest in the **next S-curve** while the current one still generates cash. This is the Innovator's Dilemma:

- By the time the current S-curve plateaus, the next one is already growing
- Incumbents underinvest in the next S-curve because the current one is profitable
- New entrants ride the next S-curve up and displace incumbents

**Strategic response:** Run parallel innovation tracks — one optimized for the current curve (extract value), one for the next curve (explore).

# Product Strategy & Vision

## North Star Framework

The North Star is the single, leading metric that captures the value your product delivers to customers. It aligns the entire organization around outcome over output.

### Criteria for a Good North Star

| Criterion | Description | Example (Spotify) |
|-----------|-------------|-------------------|
| **Leading indicator** | Predicts long-term business outcomes | Time spent listening → predicts retention |
| **Customer-centric** | Reflects value delivered, not internal activity | Not "features shipped" |
| **Actionable** | Teams can directly influence it | Not "brand awareness" |
| **Measurable** | Can be instrumented and tracked | DAU/MAU, sessions, engagement depth |

### North Star Anti-Patterns

- **Revenue masquerading as a North Star** — Revenue is a lagging indicator. The North Star should be a leading indicator that *drives* revenue.
- **Composite metrics** — A score that combines 5 sub-metrics into one number isn't actionable. No team knows how to move it.
- **Vanity metrics** — Total registered users, not active users. Downloads, not engagement.
- **Annual planning cycle** — The North Star doesn't change quarterly. If you're reevaluating it every planning cycle, you don't have a North Star.

### Formulating a North Star

```text
[Product/Feature] helps [customer segment] achieve [core outcome] by [core capability].
We measure success by [North Star metric].
```

Example (Airbnb):
> Airbnb helps travelers belong anywhere by connecting them with local hosts.
> We measure success by **nights booked**.

## Product Principles

Product principles are decision-making heuristics that encode your product philosophy. They don't tell teams *what* to build — they tell them *how to decide* what to build.

### Anatomy of a Good Principle

| Component | Description | Example |
|-----------|-------------|---------|
| **Name** | Memorable label | "Default to Open" |
| **One-liner** | The rule itself | "Share data by default; only restrict when there's a clear privacy or security reason." |
| **Tradeoff** | What you're willing to sacrifice | "This may mean competitors see our usage patterns. That's acceptable because it builds trust faster." |
| **Boundaries** | When the principle doesn't apply | "Not applicable to PII or billing data." |

### Example Product Principles

- **Solve for the 80%** — Build the path most users take; power users get their edge cases through APIs and extensibility. *Tradeoff: power users may feel underserved.*
- **Progress, not perfection** — Ship the 80% solution this quarter rather than polishing to 95% for two quarters. *Tradeoff: early versions will have rough edges.*
- **Platform over point solution** — Build capabilities that multiple features can leverage, not single-use features. *Tradeoff: slower initial delivery.*
- **Default to simplicity** — When a decision adds complexity without a measurable improvement in the primary metric, reject it. *Tradeoff: some elegant-but-complex solutions won't ship.*

## Roadmap Prioritization

### RICE Scoring

The RICE framework scores feature proposals across four dimensions:

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

- **Reach**: How many users per unit time this affects
- **Impact**: How much it matters to those users (0.25× to 3× multiplier)
- **Confidence**: How sure you are about estimates (20%–100%)
- **Effort**: Total team-weeks required

See `rice-framework.md` in the product-methodology skill for the full treatment.

### Kano Model

Categorizes features by their relationship to customer satisfaction:

| Category | Description | Example | Saturation risk |
|----------|-------------|---------|-----------------|
| **Threshold** (Must-be) | Expected; absence causes dissatisfaction | Login, payment processing | None — required to compete |
| **Performance** (One-dimensional) | More is better; directly correlates with satisfaction | Battery life, page load speed | Yes — diminishing returns |
| **Delight** (Attractive) | Unexpected; absence doesn't hurt, presence delights | Confetti animation on first purchase | Yes — becomes threshold over time |
| **Indifferent** | No impact on satisfaction | Unused settings options | N/A |
| **Reverse** | More is worse | Excessive notifications | N/A |

**Strategic implication:** Don't invest in delighters at the expense of threshold features. Threshold features are table stakes — you can't win on them, but you can lose without them. Invest in performance features for competitive differentiation, and sprinkle delighters as surprise-and-delight moments.

### Opportunity Solution Trees (OST)

A framework for connecting customer needs to build decisions without jumping to solutions:

```
Opportunity (customer need)
├── Solution option A
│   └── Assumption to test
├── Solution option B
│   └── Assumption to test
└── Solution option C
    └── Assumption to test
```

**Key rules:**
1. Start with an **opportunity** (something the customer needs to achieve), not a solution.
2. Branch into **possible solutions** — multiple options for each opportunity.
3. Each solution has **testable assumptions** — what must be true for it to work.
4. Test the riskiest assumption first. If it fails, move to the next solution.

**Pitfall:** Teams jump to a single solution because it's obvious. OST forces you to consider alternatives before committing.

## Product-Market Fit (PMF)

### Sean Ellis Test

Ask active users: "How would you feel if you could no longer use [product]?"

| Response | Interpretation |
|----------|---------------|
| **Very disappointed** | Core engaged users — 40%+ indicates PMF |
| **Somewhat disappointed** | Users who find value but aren't hooked |
| **Not disappointed** | Low value — no PMF |
| **N/A — no longer use** | Churned |

**Threshold:** If ≥40% answer "Very disappointed," you have product-market fit.

### Retention Curves

Plot % of users retained over time from their signup date:

- **Flattening curve** → PMF hit. Users who get the value stay.
- **Downward slope** → No PMF. Users try the product and leave.
- **Flattening then dropping** → Weak PMF for a specific segment. Find the cohort that sticks and focus on it.

**Segmentation tip:** Don't look at aggregate retention. Segment by acquisition channel, user persona, feature adoption, and behavior. The right cohort tells you where PMF exists; the wrong cohort hides it.

## Market Sizing: TAM / SAM / SOM

| Term | Definition | Question it answers |
|------|------------|---------------------|
| **TAM** (Total Addressable Market) | Total revenue opportunity if 100% market share | "How big is the pie?" |
| **SAM** (Serviceable Addressable Market) | Segment of TAM your product/service can reach | "How much of the pie can we actually serve?" |
| **SOM** (Serviceable Obtainable Market) | Share of SAM you can realistically capture | "How much will we actually eat?" |

### Top-Down Approach

Start with industry analyst data and apply filters:

```
TAM = Global market revenue for category X
SAM = TAM × % accessible via our distribution channels
SOM = SAM × % we can capture given our team/capital/competitive position
```

**Pitfall:** Top-down tends to overestimate. Analysts define markets broadly; your actual reach is narrower.

### Bottom-Up Approach

Start with your unit economics and scale up:

```
SOM = (Sales capacity × conversion rate × average deal size) × time horizon
SAM = SOM × (theoretical max sales capacity / current capacity)
TAM = Bottom-up SAM × (your price / average category price)
```

**Bottom-up is more credible** because it's grounded in operational reality.

## Platform Strategy

### API-First Design

Build the API before the UI. This forces contract clarity, enables multiple clients (web, mobile, partner API), and creates a foundation for ecosystem growth.

**Key decisions:**
- REST vs GraphQL vs gRPC — each has different tradeoffs for discoverability, performance, and client complexity
- Versioning strategy — URL-based (`/v1/`), header-based, or contract-based (GraphQL)
- Authentication — API keys (simple), OAuth2 (scoped), JWTs (stateless)

### Marketplace Strategy

Two-sided network effects create defensible moats:

| Phase | Supply side | Demand side | Mechanics |
|-------|-------------|-------------|-----------|
| **Cold start** | Recruit supply manually | Seed demand through marketing | Both sides need value before the other exists — hardest phase |
| **Growth** | Supply grows with demand | Demand grows with supply | Each new supply unit attracts demand, and vice versa |
| **Moat** | High switching costs | Deep inventory | Competitors can't replicate the liquidity |

### Ecosystem Strategy

- **Platform extensibility** — APIs, plugins, webhooks, embeddable widgets
- **Developer experience** — Documentation, SDKs, sandbox environments, SLAs
- **Governance** — What third parties can/cannot build, revenue share, certification
- **Control points** — Where you retain control vs open up

## Product Lifecycle Management

| Stage | Characteristics | Strategy | Metrics |
|-------|----------------|----------|---------|
| **Introduction** | Low revenue, high investment | Build awareness, find PMF | Activation rate, early retention |
| **Growth** | Rapid revenue growth | Scale acquisition, expand features | Net revenue retention, market share |
| **Maturity** | Slowing growth, stable revenue | Extract profits, segment positioning | Profit margin, customer lifetime value |
| **Decline** | Revenue declining | Harvest or pivot | Cash flow, cost of maintenance |

**Key insight:** The worst product strategy mistake is treating a mature product like a growth product (over-investing) or a growth product like a mature product (under-investing for short-term profit).