第一章：Customer Discovery——在写代码之前验证需求

80% 的独立开发者失败，不是因为代码写得烂，而是因为在市场验证之前就开始写代码了。

1.1 假设的陷阱

每个产品创意的背后都有一堆假设：

“用户有这个问题” → 假设
“用户愿意付钱解决这个问题” → 假设
“用户会用 SaaS 解决而不是 Excel/人工” → 假设
“用户愿意付 $X/月，而不是一次性付费” → 假设
“你的解法比现有方案更好” → 假设

大多数开发者先花 3 个月构建产品，然后用产品去验证这些假设。问题是：如果任何一个假设是错的，3 个月的努力就浪费了。

正确的顺序：先用 2-4 周验证所有核心假设，再决定是否值得构建。

1.2 Jobs-to-be-Done 框架

JTBD（Jobs-to-be-Done）是理解用户需求最好的框架之一。核心问题：

用户"雇用"你的产品，是为了完成什么"工作"？

传统思维：用户需要一个"PDF 转 Word 工具"
JTBD 思维：用户雇用它的工作是"把合同交给助手修改时不用买 Adobe"

传统思维：用户需要"AI 写作助手"
JTBD 思维：用户雇用它的工作是"在截稿前 2 小时写完这篇文章，让老板看到"

为什么区别重要：

当你用 JTBD 定义产品时，你的竞争对手不只是功能类似的工具，而是所有可以帮用户完成同一"工作"的方案（包括手工、外包、不做）。

这改变了你的定价逻辑：定价应该基于用户完成这个"工作"的其他方式的成本，而不是你的开发成本。

1.3 验证假设的正确方式

方法一：5 个问题客户电话

不要做问卷（人们会礼貌地说谎），要打电话（人们的真实反应藏在犹豫和措辞里）。

Rob Fitzpatrick 在《The Mom Test》中总结的规则：

不要问"你会用这个产品吗？“（人们会礼貌地说"会”）
要问"你上次是怎么处理这个问题的？"
要问"这个问题有多频繁？上次花了你多少时间/钱？"
要问"你现在用什么解决这个问题？"
要问"你愿意现在就付 $X 的预付款吗？"（最终验证）

5 个问题的具体模板：

1. "上一次你遇到[问题场景]是什么时候？当时你是怎么处理的？"
   （了解真实频率和现有解决方案）

2. "你在这件事上每月大概花多少时间或金钱？"
   （量化痛点大小）

3. "这对你的业务/工作有多重要？1-10 分"
   （评估支付意愿的上限）

4. "如果有一个工具可以[你的解法]，理想价格是多少？"
   （直接问价格，但这个答案只是参考）

5. "我正在构建这个工具，可以让你以 $X 的早鸟价预购，第一批用户享受终身折扣，你愿意现在就预付吗？"
   （真正的验证：有没有人愿意在产品不存在时就付钱）

目标：在开始构建前，找到 5 个愿意预付的客户。如果找不到，要么问题不够痛，要么解法不够好，要么目标客户找错了。

方法二：Landing Page + 预购

构建一个 Landing Page，描述产品核心功能和价值，添加"早鸟预购"按钮（接 Stripe 支付），然后用付费广告或社群发帖引流。

评判标准：

1,000 人看到 → 100 人点击 CTA → 10 人付款 = 合格
1,000 人看到 → 100 人点击 CTA → 0 人付款 = 定价有问题或 Landing Page 不够好
1,000 人看到 → 5 人点击 → = 价值主张不清晰

1.4 区分"有兴趣"和"愿意付钱"

这是最关键的认知差距：

"很有趣！我会关注进展。" = 没有验证
"我现在有这个问题，你做好了记得通知我。" = 没有验证
"我愿意付 $X 的预购款，产品做好后你扣款。" = 有效验证

预购是最强的验证信号，因为它包含了：

用户确认问题真实存在
用户认可你的解法有价值
用户愿意承担等待风险（你可能做不出来）
用户对价格没有异议

Stripe 预购实现

# 用 Stripe Payment Links 做最简单的预购
# 不需要写任何代码，直接在 Stripe Dashboard 创建

# 或者在 Landing Page 中集成：
import stripe

stripe.api_key = "sk_live_xxx"

def create_preorder_checkout(
    product_name: str,
    price_usd: int,
    early_bird_note: str
) -> str:
    """创建预购 Checkout Session，返回支付 URL"""
    
    session = stripe.checkout.Session.create(
        payment_method_types=["card"],
        line_items=[{
            "price_data": {
                "currency": "usd",
                "product_data": {
                    "name": f"{product_name} - Early Bird",
                    "description": early_bird_note,
                },
                "unit_amount": price_usd * 100,  # 单位是分
            },
            "quantity": 1,
        }],
        mode="payment",
        success_url="https://yoursite.com/thank-you",
        cancel_url="https://yoursite.com/",
        metadata={"type": "preorder", "product": product_name},
    )
    
    return session.url

1.5 快速验证的时间框架

第 1 周：
  - 写下你的 3 个核心假设
  - 找到目标客户聚集的 3 个社群
  - 发布"我在构建 X，有遇到 Y 问题的人吗？"的帖子
  - 争取 5-10 个愿意接受电话的人

第 2 周：
  - 完成 10 个客户访谈
  - 分析反馈：问题是否真实？频率够高？愿意付多少？
  - 决策：继续还是 Pivot

第 3 周（如果决定继续）：
  - 构建 Landing Page（1 天，用 Framer/Webflow）
  - 实现预购功能（半天，Stripe Payment Links）
  - 在社群推广，目标：5 个预购

第 4 周：
  - 如果有 5 个预购 → 开始构建 MVP
  - 如果没有 → 分析原因，调整方向或放弃

1.6 常见的错误验证

错误一：只问"你会用吗"
正确：展示方案，观察他们的实际反应（“告诉我你在什么情况下会用这个”）

错误二：验证朋友和同事
他们会出于礼貌说好话。真正的目标客户是陌生人，尤其是已经有这个问题的陌生人。

错误三：构建"完整产品"再验证
MVP 原则：只构建验证核心假设所需的最少功能。如果核心功能是"AI 分析合同"，那 MVP 不需要有团队账号、历史记录、API 接口。

错误四：以为"免费用户多"意味着验证成功
免费用户的价值是零，直到有人愿意付钱。一个 5 个付费用户的产品比一个 500 个免费用户的产品更经过验证。

小结

Customer Discovery 不是一次性的工作，而是持续的习惯。最好的产品团队（无论是一个人还是 100 个人）都在持续和用户对话。

两个核心原则：

先验证，再构建：每一天开发时间都是赌注，客户访谈是降低风险的保险
付钱是唯一真实的验证：所有言语都是假设，只有付款行为是数据

下一章，定价——这是独立开发者最容易犯错、同时提升空间最大的地方。