product-playbook 1.0.0

package/i18n/en/references/04a-prfaq.md

@@ -0,0 +1,112 @@
+# Phase 3: Develop — PR-FAQ (Working Backwards)
+
+## 3.1 Amazon's Working Backwards Method (PR-FAQ)
+
+Start by writing the product press release — it forces you to work backwards from the customer outcome:
+
+```
+## [Product Name] Press Release
+
+**Headline**: [What can the user achieve? One sentence.]
+**Subheadline**: [What problem does it solve, and for whom?]
+
+**Opening Paragraph (Aha Moment)**:
+[Describe the moment the user experiences the product's core value — the "Wow!" moment]
+
+**Pain Point Description**:
+[What problem are users facing today? Why aren't current solutions good enough?]
+
+**Solution Description**:
+[How does our product solve this problem? (Describe the experience — don't list features)]
+
+**Customer Quote**:
+"[A quote from a target user that represents a genuine emotional reaction]"
+
+**FAQ (The Hardest Questions)**:
+Q: [The hardest question to answer]
+A: [An honest answer]
+```
+
+> If you can't write a press release that excites people, the product direction may be flawed — go back and redefine the problem.
+
+### 📝 PR-FAQ Quality Checklist
+
+Claude must mark each item ✅ or ❌ after producing the PR-FAQ; ❌ items must include how to improve:
+- [ ] Is the headline written from the user's perspective? ("Users can now do X" vs. "We launched feature Y")
+- [ ] Can a reader understand "why this matters" within 10 seconds of reading the first paragraph?
+- [ ] Does the pain point description come from a real user scenario?
+- [ ] Does the first sentence of the solution section lead with the user's experience/scenario (not a feature verb)?
+- [ ] Does the customer quote sound like something a real person would say?
+- [ ] Does the FAQ include a pointed comparison against existing tools?
+
+**Execution Rules (Hard Gate):**
+- Must identify at least 1 "internal tension" or "area worth iterating on" — cannot mark all ✅ and call it done
+- If all items pass, additionally state "What is the most fragile assumption in this PR-FAQ?"
+- The quality bar for Amazon's PR-FAQ comes from finding problems, not confirming there are none
+- ❌ Common issues: headline reads like a product announcement instead of news, solution section turns into a feature list, FAQs are all softball questions
+
+---
+
+### ✍️ Solution Section (Body) Writing Rules
+
+**The first sentence of the solution section must NOT start with a feature description.**
+
+❌ Prohibited examples:
+- "MealPrep lets you input a menu with one click and auto-calculates ingredients"
+- "The system automatically generates a procurement list based on the menu"
+- "Click the 'Generate List' button to complete your prep planning"
+
+✅ Correct examples:
+- "Now, Chef Chen only needs 10 minutes on Friday afternoon to confirm every detail for the weekend's prep"
+- "Manager Zhang no longer has to flip through three Excel sheets to figure out whether there's enough inventory"
+
+**Formula**: Lead with the user's experience / specific scenario → then say "This is possible because [product mechanism]" to introduce the feature.
+
+---
+
+### ❓ FAQ Sharp-Question Standard
+
+**At least 1 FAQ must be: "Why not just keep using [existing tool]?"**
+
+Answer format requirements:
+1. **First, acknowledge the strengths of the existing tool** (don't dismiss it)
+2. **Then explain the gap** (not a feature gap, but a fundamental scenario gap)
+
+❌ Prohibited answer pattern: "Existing tools lack features — ours is more powerful"
+✅ Correct answer pattern:
+> "Excel can absolutely track numbers, and chefs already know how to use it. The issue is that every weekend the calculations need to be rebuilt — re-entered, re-converted — and the hour it takes isn't because anyone's bad at spreadsheets, it's because the problem really is that complex. MealPrep doesn't save you Excel skills — it saves you the mental burden of starting from scratch every single time."
+
+**Example (fictional product — Mortgage Calculator App):**
+
+```
+## MortgageSnap Helps First-Time Buyers Understand What They Can Afford in 3 Minutes
+
+**Subheadline**: No bank visits, no waiting for rate quotes — figure out your monthly payments with your partner, even at midnight
+
+**Opening Paragraph (Aha Moment)**:
+After scrolling through Zillow late at night, Alex spots a house he loves but has no idea if he can
+actually afford it. He opens MortgageSnap, screenshots the listing page, and the app automatically
+extracts the price and square footage. Within 30 seconds, it shows monthly payments across three
+loan scenarios. He shares the results with his wife, and for the first time, they're looking at the
+same numbers together.
+
+**Pain Point Description**:
+First-time homebuyers comparing mortgage options have to manually enter terms across multiple bank
+websites and wait for responses. When you want to run the numbers late at night, there's no
+convenient tool — so people end up hacking together an Excel sheet or just giving up.
+
+**Solution Description**:
+MortgageSnap lets you snap any property listing, automatically extracts key data, instantly compares
+options across lenders, and generates a shareable report so your family can discuss together.
+
+**Customer Quote**:
+"I finally don't have to wait for the bank to call back at midnight. Three minutes and I can tell
+my wife exactly how much we'd pay each month."
+
+**FAQ**:
+Q: There are already tons of mortgage calculators out there — what's different?
+A: Existing calculators require you to input interest rates, loan terms, and other parameters, but
+most first-time buyers don't even know those numbers. MortgageSnap's difference is that it
+automatically pulls in real offers from various lenders — all you need to provide is the price and
+your down payment.
+```

package/i18n/en/references/04b-solutions.md

@@ -0,0 +1,269 @@
+# Stage 3: Develop — Solution Design & Prioritization
+
+## 3.2 Parallel Prototyping Principle
+
+Develop multiple parallel approaches simultaneously — don't design a single solution and rush to execute:
+
+```
+| HMW Question | Solution A (Conservative/Incremental) | Solution B (Balanced) | Solution C (Bold/Disruptive) |
+|---|---|---|---|
+| [HMW1] | | | |
+```
+
+Three solution quality gates:
+- Is Solution A clearly better than the current approach?
+- Does Solution C actually solve the core JTBD?
+- Are the three solutions genuinely different, or just variations of the same idea?
+
+## 3.3 Shreyas Doshi's Pre-mortem
+
+**Applicable: Medium/high completeness / audience is engineers/internal planning**
+
+Before committing to a solution, assume it has already failed:
+
+```
+Assume: We chose Solution X and declared failure after [time period]. Why did it fail?
+
+| Failure Reason | Likelihood (High/Med/Low) | Preventability (High/Med/Low) | Preventive Measure |
+|----------------|--------------------------|-------------------------------|-------------------|
+| | | | |
+```
+
+**Security failure scenarios** (must consider at least one, especially for products handling user data):
+
+```
+| Security Risk | Likelihood | Preventability | Preventive Measure |
+|---------------|-----------|----------------|-------------------|
+| User data breach (database intrusion, unauthorized API access) | | | |
+| Mass account takeover (brute force, credential stuffing) | | | |
+| API abuse (no rate limiting, mass scraping) | | | |
+| XSS / CSRF attacks harming users | | | |
+| Accidental exposure of sensitive data (secrets in version control, passwords in logs) | | | |
+```
+
+> If the product doesn't involve user authentication or sensitive data, mark as "Not applicable" and explain why.
+
+## 3.4 Gibson Biddle's GEM Prioritization Model (Netflix)
+
+```
+| Feature | G (Growth) | E (Engagement) | M (Monetization) | Overall Priority |
+|---------|-----------|----------------|------------------|-----------------|
+| | | | | |
+```
+
+**Impact / Effort Matrix:**
+
+```
+| Feature / Solution | Impact (High/Med/Low) | Effort Required (High/Med/Low) | Quadrant |
+|---|---|---|---|
+| | | | Quick Win / Strategic / Fill-in / Avoid |
+```
+
+## 3.5 RICE Quantitative Prioritization
+
+**Applicable: High completeness / audience is data scientists/executives**
+
+```
+RICE Score = (Reach × Impact × Confidence) / Effort
+
+| Feature | Reach (users impacted/mo) | Impact (0.25/0.5/1/2/3) | Confidence (%) | Effort (person-months) | RICE Score |
+|---------|--------------------------|------------------------|----------------|----------------------|------------|
+| | | | | | |
+```
+
+**Impact Scale Definitions:**
+| Score | Level | Criteria |
+|-------|-------|----------|
+| 3 | Massive | Fundamentally changes the user experience; directly solves the core JTBD |
+| 2 | High | Significantly improves user experience; clear positive impact on the North Star Metric |
+| 1 | Medium | Noticeable improvement; helpful for some users or some scenarios |
+| 0.5 | Low | Minor improvement; nice-to-have |
+| 0.25 | Minimal | Barely noticeable difference; maintenance-level work |
+
+**Confidence Judgment Reference:**
+- 100%: Supported by quantitative data (A/B tests, user data)
+- 80%: Supported by qualitative data (user interviews, competitive validation)
+- 50%: Reasonable hypothesis but unvalidated
+- 20%: Pure intuition or guesswork
+
+> "Don't prioritize features — prioritize problems. Features are solutions, and they only matter after you've confirmed the priority of the problems." — Shreyas Doshi
+
+## 3.6 User Story Table
+
+**Applicable: Audience is engineers**
+
+```
+| # | User Story | Acceptance Criteria | Priority |
+|---|---|---|---|
+| US1 | As a [Persona], I want to [action], so that [value] | | |
+```
+
+---
+
+## 📄 PRD Output Format (Used when the audience is engineers)
+
+When the user says "produce a PRD" or "produce a document for engineers," consolidate all relevant preceding steps and produce the following complete format:
+
+```
+# [Product Name] Product Requirements Document
+
+**Version**: v[X.X]　**Date**: [Date]　**Author**: [PM Name]
+**Status**: Draft / Under Review / Approved
+
+---
+
+## 1. Background & Objectives
+
+**Problem Statement**: [Transformed from HMW question — one paragraph explaining what problem is solved for whom]
+**Target Persona**: [Which Persona]
+**Core JTBD**: [Target Customer] + wants to [Job] + in the context of [Job Context]
+**Success Metrics**: [North Star Metric + Hero Metric]
+
+---
+
+## 2. Solution Overview (from PR-FAQ)
+
+**Product One-liner**: [PR-FAQ headline]
+**Aha Moment**: When the user completes [action], they experience the core value
+**Product Positioning**: [April Dunford positioning summary, if completed]
+
+---
+
+## 3. Feature Scope
+
+### MVP Must-Haves
+| Feature | Description | Priority | Notes |
+|---------|------------|----------|-------|
+| | | P0 | |
+
+### V2 Additions
+| Feature | Description | Priority | Notes |
+|---------|------------|----------|-------|
+| | | P1 | |
+
+### Explicitly Not Doing (Not Doing List)
+| Not Doing | Reason |
+|-----------|--------|
+| | |
+
+---
+
+## 4. User Stories
+
+| # | As a... | I want to... | So that... | Acceptance Criteria | Priority |
+|---|---------|-------------|------------|---------------------|----------|
+| US-001 | [Persona] | [Action] | [Value] | - [ ] Condition 1 | P0 |
+
+---
+
+## 5. Feature Specifications
+
+> For each P0 feature, document the following:
+
+### [Feature Name]
+- **Description**: [What this feature does]
+- **Trigger Condition**: [When it's triggered]
+- **Happy Path**: [Step 1 → 2 → 3]
+- **Edge Cases**: [Error scenarios, boundary conditions]
+- **Acceptance Criteria**:
+  - [ ] [Specific testable condition]
+  - [ ] [Specific testable condition]
+
+---
+
+## 6. Technical Considerations
+
+**Known Technical Constraints**: [Constraints engineers need to know]
+**Dependencies**: [Third-party services, APIs, prerequisites from other features]
+**Performance Requirements**: [Load times, concurrency, etc., if applicable]
+**Security Requirements**: [Data protection, permissions, etc., if applicable]
+
+---
+
+## 7. Risks & Assumptions (from Pre-mortem)
+
+| Risk | Likelihood | Impact | Preventive Measure |
+|------|-----------|--------|-------------------|
+| | High/Med/Low | High/Med/Low | |
+
+**Core Assumptions**: [Assumptions that need validation — if proven wrong, the direction needs reassessment]
+
+---
+
+## 8. Milestones & Timeline
+
+| Milestone | Target Date | Includes |
+|-----------|------------|----------|
+| Alpha | | [Minimum testable version] |
+| Beta | | [Limited user testing] |
+| Launch | | [Official release] |
+
+---
+
+## 9. Open Questions
+
+| Question | Owner | Expected Resolution Date |
+|----------|-------|------------------------|
+| | | |
+```
+
+---
+
+## 🗂️ Development Artifacts (Triggered on demand)
+
+### Flowchart (Mermaid syntax)
+
+When the user says "produce a flowchart," generate a Mermaid flowchart based on User Stories and feature specs:
+
+```mermaid
+flowchart TD
+    A[User enters] --> B{Logged in?}
+    B -- Yes --> C[Show main screen]
+    B -- No --> D[Redirect to login]
+    C --> E[Complete core action]
+    E --> F[Reach Aha Moment]
+```
+
+Include: Main user flow / Key decision branches / Error scenarios
+
+### DB Schema (Mermaid ERD syntax)
+
+When the user says "produce a DB schema," generate a Mermaid erDiagram based on the MVP feature scope:
+
+```mermaid
+erDiagram
+    USER {
+        int id PK
+        string name
+        string email
+        datetime created_at
+    }
+    PRODUCT {
+        int id PK
+        string name
+        int owner_id FK
+    }
+    USER ||--o{ PRODUCT : "owns"
+```
+
+Include: Main entities / Relationships / Key fields (FKs, index recommendations)
+
+### UI Wireframe (HTML wireframe)
+
+When the user says "produce a UI wireframe," output a low-fidelity wireframe in HTML + inline CSS, including:
+- Core pages (determine page count based on User Stories)
+- Grayscale color scheme, no brand colors
+- Annotate each element's functional purpose
+- Annotate where the Aha Moment occurs
+
+---
+
+## 📎 File Integration Tips for This Stage
+
+| Uploaded Content | Integrate Into | Integration Action |
+|-----------------|----------------|-------------------|
+| Existing PRD / requirements doc | 3.7 MVP | Extract existing feature list as reference for MVP boundary decisions |
+| Technical architecture doc | 3.5 RICE (Effort) | Use real technical complexity to assess Effort scores |
+| Design mockups / wireframes | 3.2 Parallel Prototyping + UI Wireframe | Use as visual reference for solutions; identify existing vs. new design needs |
+| Engineering estimation doc | 3.5 RICE + 3.7 MVP | Replace assumed Effort with real estimates; adjust MVP scope |
+| Past version postmortems | 3.3 Pre-mortem | Supplement risk list with historical failure lessons |

package/i18n/en/references/04c-mvp.md

@@ -0,0 +1,21 @@
+# Stage 3: Develop — MVP Scope Definition
+
+## 3.7 MVP Scope Definition
+
+MVP decision criteria: **Can it validate the core hypothesis? Can it let target users fully experience the Primary JTBD?**
+
+```
+| Category | MVP Must-Have | Add in V2 | Future Consideration |
+|---|---|---|---|
+| Core Features | | | |
+| User Experience | | | |
+| Technical Requirements | | | |
+```
+
+**Not Doing List (Equally important):**
+
+```
+| Not Doing | Reason |
+|-----------|--------|
+| | |
+```

package/i18n/en/references/05a-northstar-aha.md

@@ -0,0 +1,93 @@
+# Phase 4: Deliver — North Star + Aha Moment
+
+## 4.1 Marty Cagan's Empowered Teams Principles
+
+**Applicable when: high completeness / deliverable audience is leadership or cross-functional teams**
+
+> 4.1 Empowered Teams is only shown when the deliverable audience is leadership or cross-functional teams; otherwise skip.
+
+```
+| Dimension | Feature Team (Avoid) | Empowered Team (Goal) |
+|-----------|---------------------|----------------------|
+| Assigned | Feature list (Output) | Problem to solve (Outcome) |
+| Success defined as | Delivering features on time | Achieving user and business metrics |
+| PM's role | Requirements gatherer and project manager | Problem explorer and solution validator |
+| Engineers' role | Execute specs | Participate in problem exploration and solution design |
+```
+
+> "True product discovery is done **together** with engineers and designers, not by the PM alone handing off completed work." — Marty Cagan
+
+**Lenny's Three PM Responsibilities:**
+- **Shape**: Synthesize user insights, data, and market intelligence to decide what to build
+- **Ship**: Ensure a high-quality product launches on time, with no surprises
+- **Synchronize**: Keep all stakeholders aligned on vision, strategy, goals, and roadmap
+
+## 4.2 Success Metrics Framework (North Star + Three-Layer Signals)
+
+A North Star metric must satisfy:
+- Reflects the real value users receive (not a vanity metric)
+- Can grow continuously (doesn't hit a natural ceiling)
+- Aligns the entire team around a single objective
+
+```
+| Company | North Star Metric | Why This Metric |
+|---------|-------------------|-----------------|
+| Airbnb | Nights booked | Represents value delivered to both hosts and guests |
+| Spotify | Monthly listening hours | Represents users genuinely using and enjoying music |
+| Facebook | DAU / MAU ratio | Represents habitual return visits |
+| Slack | Messages sent per week | Represents teams genuinely collaborating |
+| Salesforce | Active customer ACV (Annual Contract Value) | Represents customers continuously deriving business value (B2B) |
+```
+
+**Your North Star Metric:**
+```
+North Star Metric: [A single number representing the core value created for users and the product]
+Definition: [Precise calculation method]
+Why this metric: [Explain why it represents real user value, not just a business outcome]
+```
+
+### 📝 North Star Quality Checklist
+- ✅ Does it reflect the value users receive? (Not revenue, not DAU)
+- ✅ Can it grow continuously? (Doesn't hit a natural ceiling)
+- ✅ Does everyone on the team know what to do when they see this metric?
+- ✅ Can it be gamed? (If yes, guardrail metrics are needed)
+- ✅ B2B products: Does it reflect value at the organizational level, not just individual users?
+- ❌ Common issues: using revenue as the North Star (revenue is an outcome, not a driver), metric is too composite to act on
+
+**Three-Layer Signal System (must be achieved in order):**
+
+```
+| Layer | Metric Type | Definition | B2C Target | B2B Target |
+|---|---|---|---|---|
+| Layer 1 (Prerequisite) | Core Action Success Rate | Did the user complete the product's core action? | 30–40%+ | 60–80%+ (users are more motivated) |
+| Layer 2 (Value Proxy) | D14 / D28 Retention Rate | Do users keep coming back? | Consumer products 15–20%+ | Logo retention 90%+; Net Revenue Retention 100%+ |
+| Layer 3 (Passion Signal) | Sean Ellis Score | "If you could no longer use this product, how disappointed would you be?" | 40%+ answer "very disappointed" | 40%+ answer "very disappointed" |
+| Guardrail Metrics | Prevent over-optimization | Ensure other important dimensions aren't harmed | Depends on context | Depends on context |
+```
+
+Note: Layer 1 is the prerequisite for Layer 2. If the core action success rate is very low, retention data is meaningless because users never had the chance to experience the product's value.
+
+## 4.4 Aha Moment Design
+
+```
+Aha Moment Definition:
+When a user completes [specific behavior], they have experienced this product's core value.
+Goal: Get users to this moment within [X minutes / X steps] of entering the product.
+
+Aha Moment Reach Rate: [target %]
+Current Barriers: [What prevents users from reaching the Aha Moment faster?]
+Improvement Plan: [How to remove the barriers?]
+```
+
+**Examples:**
+| Product | Aha Moment | Time Target |
+|---------|-----------|-------------|
+| Slack | Team sends its 2,000th message | First two weeks |
+| Dropbox | First file synced to a second device | Within 10 minutes of first use |
+| Zoom | First one-click join with smooth video | First use |
+
+### 📝 Aha Moment Quality Checklist
+- ✅ Is it a specific, trackable behavior? (Not "feels like the product is useful")
+- ✅ Is it directly tied to the JTBD's functional job?
+- ✅ Is the time target reasonable? (B2C should be within first use; B2B may be within the trial period)
+- ✅ Can onboarding be designed to help users reach it faster?

package/i18n/en/references/05b-pmf-gtm.md

@@ -0,0 +1,102 @@
+# Stage 4: Deliver — PMF + GTM + Business Model
+
+## 4.3 Todd Jackson's (First Round Capital) Four-Level PMF Framework
+
+```
+| Level | Name | Characteristics | Your Task | Typical Company Stage |
+|-------|------|----------------|-----------|----------------------|
+| Level 1 | Nascent PMF | Found 3-5 customers willing to pay for the solution | Deeply serve these early users, find a repeatable pattern | Pre-seed / Seed |
+| Level 2 | Developing PMF | Word-of-mouth starting, but growth is still unstable | Find a scalable acquisition channel, improve retention | Seed / Series A |
+| Level 3 | Strong PMF | "Fish are jumping into the boat" — referrals become the main growth driver | Build scalable demand channels, improve efficiency metrics | Series A / B |
+| Level 4 | Extreme PMF | Metrics are robust, company exceeds 100 people, considering TAM expansion | Enter new markets or launch new products | Series C+ |
+```
+
+**Four P's (Key questions for finding PMF at Level 1-2):**
+1. Problem: Is the problem you're solving truly urgent and important enough?
+2. Promise: What promise does your product make to users? Do they believe it?
+3. Product: Does your product actually deliver on that promise?
+4. Pitch: How do you get target users to discover and believe in your product?
+
+## 4.7 GTM Strategy (Go-to-Market)
+
+**Applicable: Full mode / high completeness / audience is executives/sales/marketing**
+
+Once the product is built, how do you get target users to know about it and start using it?
+
+### Acquisition Channel Selection
+
+```
+| Channel Type | Best For | Typical Methods | Key Metrics |
+|-------------|----------|----------------|-------------|
+| Product-Led Growth (PLG) | Products where users can self-serve to experience value | Free trial, Freemium, viral invite | Signup conversion, activation rate, invite rate |
+| Content & Community | Target users share common information needs or community | Blog, SEO, community building, KOL | Traffic, content conversion rate, community engagement |
+| Paid Acquisition | Need fast validation or clear ROI | SEM, social ads, retargeting | CAC, ROAS, LTV/CAC |
+| Sales-Led | B2B high ACV, requires demo and negotiation | SDR, AE, Demo, enterprise contracts | Pipeline, close rate, ACV |
+| Partnerships | Target users concentrated on specific platforms or ecosystems | API integration, revenue sharing, co-marketing | Partner channel conversion rate, partner count |
+```
+
+### First 100 Users Acquisition Plan
+
+```
+Target user profile: [From Persona]
+Where to find them: [Online/offline places where they gather]
+What hook to attract them: [From PR-FAQ's Aha Moment]
+How to get them to try: [Methods to lower the barrier]
+Initial target: [X users trying the product within Y days]
+```
+
+### Launch Strategy
+
+| Strategy | Description | Best For |
+|----------|------------|----------|
+| Closed Beta | Manually invite 10-50 people, collect deep feedback | PMF Level 1, product still being refined |
+| Open Beta | Public but labeled Beta, managing expectations | PMF Level 1-2, need more data |
+| Soft Launch | Low-key launch in a specific market or channel | Need real-world testing without full exposure |
+| Full Launch | Full-channel official release | PMF Level 2-3, product is stable |
+
+## 4.8 Business Model & Pricing
+
+**Applicable: Full mode / high completeness / audience is executives/sales**
+
+### Revenue Model Selection
+
+```
+| Model | How It Works | Best For | Key Metrics |
+|-------|-------------|----------|-------------|
+| Freemium | Free basic tier + paid premium | Products with large user base, free tier demonstrates value | Free-to-paid conversion rate (target 2-5%) |
+| Subscription | Monthly/annual subscription | Tools or services that provide ongoing value | MRR/ARR, churn rate |
+| Usage-based | Pay for what you use | APIs, cloud services, transaction platforms | Average spend per user, usage growth rate |
+| One-time purchase | Buy outright | Tool software, courses | Average order value, repurchase rate |
+| Transaction fee | Percentage per transaction | Platforms, marketplaces | GMV, take rate |
+| Per-seat | Charge per user | B2B collaboration tools | Average seats per account, expansion rate |
+```
+
+### Value-Based Pricing Alignment
+
+```
+Core pricing questions:
+1. How much does your product save or earn for users? (Value anchor)
+2. How much do users currently pay for alternatives? (Competitive reference)
+3. Is your pricing proportional to the value users receive? (Fairness perception)
+
+Pricing strategy:
+  - Model choice: [Freemium / Subscription / Usage-based / ...]
+  - Price range: [Based on value anchor and competitive reference]
+  - What the free tier includes: [Enough to reach the Aha Moment, but not enough for advanced needs]
+  - Paid trigger point: [What usage behavior or volume triggers an upgrade?]
+
+⚠️ Common pricing mistakes:
+  - Pricing too low (signals "not worth much")
+  - Free tier too generous (no upgrade motivation)
+  - Price-value misalignment (feature-based pricing vs. value-based pricing)
+  - B2B without annual contract discounts (missing out on cash flow stability)
+```
+
+---
+
+## 📎 File Integration Tips for This Stage
+
+| Uploaded Content | Integrate Into | Integration Action |
+|-----------------|----------------|-------------------|
+| Financial data / revenue reports | 4.8 Business Model | Replace assumptions with real revenue structure, evaluate pricing reasonability |
+| Marketing channel data | 4.7 GTM | Use real CAC, conversion rates, and other data to evaluate channel selection |