顶级公司的产品方法论
站在巨人的肩膀上，不是为了模仿，而是为了理解背后的逻辑，然后在 RentHub 的场景里灵活应用。
1. YC：做人们真正想要的东西
Y Combinator 是全球最成功的创业加速器，Airbnb、Dropbox、Stripe、DoorDash 等等家喻户晓的公司都从这里走出来。YC 的产品哲学高度务实，没有花哨理论。
1.1 核心原则
1.1.1 Make something people want（做人们真正想要的东西）
这是 YC 的基本信条，听起来简单，却是最容易被忽视的原则。很多团队做的是“我们觉得有人会想要的东西”，而不是“有证据证明有人非常需要的东西”。
区别在哪里？证据。
- 有人愿意为此付钱 → 强证据
- 有人愿意放弃现有方案来用你的产品 → 强证 据
- 有人在访谈中说“这很有用” → 弱证据（人们总是礼貌的）
- 你自己觉得这个功能很有用 → 几乎不算证据
1.1.2 Talk to users（和用户对话）
Paul Graham 说，大多数创始人在公司早期花太少时间和用户交流。理想状态是：每周至少 5 次用户对话，持续到你真正理解用户为止。
什么是“真正理解”？当你能预测用户下一步会说什么时，说明你够了解了。
1.1.3 Do things that don't scale（做不可扩展的事）
这是 YC 最反直觉的建议之一。早期产品不该追求自动化和规模，而应该手动、亲力亲为地服务每一个用户。
Airbnb 的创始人早期用大量手动、不可扩展的方式服务早期用户（例如上门帮助完善上架展示）；Stripe 的创始人直接帮用户在他们的机器上现场部署代码。
这不是没效率，这是在用笨方法收集最真实的产品反馈，同时建立最忠实的早期用户群。
对 RentHub 的启示：当一个功能刚上线时，不要期望用户自己摸索，亲自带用户走一遍流程，观察他们卡在哪里，这比任何 A/B 测试都有价值。
1.1.4 Launch fast（快速上线）
“If you're not embarrassed by the first version of your product, you've launched too late.”
如果你对第一版产品不感到尴尬，那你上线太晚了。
— Reid Hoffman (LinkedIn 创始人，也是 YC 的朋友)
完美是速度的敌人。尽快把东西放到真实用户面前，比在内部讨论“要不要再打磨一下”更有价值。真实的反馈是最好的设计文档。
1.1.5 Build for 100 users, not 100 million
YC 的一个关键建议：早期，找到 100 个真正爱你产品的用户，比找到 100 万个“还好”的用户更重要。
强度比广度更重要。一个用户每天用你的产品，远比一百个用户注册了从不打开更有价值。
1.2 YC 方法论在 RentHub 的应用
| YC 原则 | RentHub 场景应用 |
|---|---|
| Talk to users | 新功能设计前，直接联系 3-5 个有租赁需求的商家，了解他们的日常流程 |
| Do things that don't scale | 新上线的功能，亲自帮首批用户操作一遍，收集真实卡点 |
| Launch fast | 先做 MVP，哪怕手动处理部分流程，也要快速验证需求 |
| 100 real fans | 先让现有活跃用户极度满意，再考虑扩大用户规模 |
2. Apple：简单是最终的复杂
Apple 的产品哲学来自 Steve Jobs，但在乔布斯离开和回归的几十年里，它被反复验证、强化，最终成为一种文化基因。
2.1 核心原则
2.1.1 Simplicity（简单）
“Simple can be harder than complex: you have to work hard to get your thinking clean to make it simple. But it's worth it in the end because once you get there, you can move mountains.”
简单可能比复杂更难：你需要努力工作，才能把思维理清，做到简单。但最终这是值得的，因为一旦做到了，你可以移山。
— Steve Jobs
Apple 的简单不是“功能少”，而是在众多选项中，做出最艰难的取舍，只保留最重要的。
iPhone 第一代去掉了键盘，这在当时是疯狂的决定。但 Jobs 坚信：触摸屏更简单，键盘是多余的摩擦。
对开发者的启示：当你在一个页面里塞入越来越多的功能时，停下来问：这里最重要的一件事是什么？其他的是否都可以去掉或隐藏？
2.1.2 Details matter（细节决定成败）
“Design is not just what it looks like and feels like. Design is how it works.”
设计不只是看起来和摸起来如何，设计是它如何运作。
— Steve Jobs
Apple 的工程师曾为一个圆角的弧度讨论数周，为一个动画的时间曲线争论数天。这不是在浪费时间，这是在打磨用户感受得到，但说不出来的那种“好”。
对开发者的启示：
- 加载动画有没有？还是白屏等待？
- 错误提示是“操作失败”还是“支付失败，请检查余额后重试”？
- 按钮点击有没有反馈？还是点了半天不知道有没有触发？
这些细节加在一起，决定用户觉得这是一个“好用的 App”还是“差不多能用的工具”。
2.1.3 Say no to most things（对大多数事说不）
Jobs 回到 Apple 后的第一件事，是把产品线从几十个削减到 4 个。他说：
“I'm as proud of the things we haven't done as the things I have done. Innovation is saying no to 1,000 things.”
我对我们没做的事情和做过的事情一样自豪。创新就是对一千件事说不。
对 RentHub 的启示： 每次产品迭代，不只问“要加什么”，也问“要去掉什么”。功能堆积是一条慢慢死去的路。
2.1.4 The whole experience matters（整体体验才是产品）
Apple Store 的体验、包装的触感、开箱时的仪式感——这些都是产品的一部分。用户不只在评价功能，他们在评价整个体验。
对 RentHub：用户的整体体验包括——找到小程序、注册、第一次发布上架物品、第一笔租赁款项结算到账，以及任何一次遇到问题时的处理体验。每一个环节都是产品的一部分。
3. Google：数据与用户研究的结合
Google 的产品方法论建立在大规模数据和严格的用户研究上，但有一条价值观贯穿始终：
“Focus on the user and all else will follow.”（专注用户，其余皆随之而来）
3.1 Design Sprint（设计冲刺）
这是 Google Ventures 推广的一套 5 天产品设计框架，用于快速验证想法。核心是：在真正开发之前，用原型和真实用户测试来验证假设。
简化版流程（适合 RentHub 小团队）：
| 阶段 | 核心问题 | 产出 |
|---|---|---|
| 理解（Day 1） | 我们要解决什么问题？谁的问题？ | 用户地图、核心痛点列表 |
| 发散（Day 2） | 有哪些可能的解法？ | 草图方案 3-5 个 |
| 决策（Day 3） | 哪个方案最有可能成功？ | 一个要验证的方案 |
| 原型（Day 4） | 做一个“够真”的原型 | 可点击的 Figma 原型 |
| 测试（Day 5） | 真实用户能用吗？有什么问题？ | 用户测试录像/笔记 |
关键点：不是所有功能都值得走完整个 Sprint，但在大功能开发前，至少做 Day 1-3：把问题想清楚，再动手。
3.2 North Star Metric（北极星指标）
Google 的产品团队对每个产品都有一个核心指标，一切决策都围绕它。这个指标必须：
- 直接反映用户价值（不只是商业价值）
- 可以量化、可以追踪
- 整个团队都认同它是最重要的
RentHub 可能的北极星指标候选：
| 指标 | 含义 |
|---|---|
| 月活跃商户数 | 有多少商户在真实使用平台上架与管理订单 |
| 租赁订单按期结算完成率 | 有多少订单在平台上走完全部约定结算节点 |
| 合约到期续约率 | 商户与租户在合约结束后是否继续通过平台成交 |
选哪个取决于当前阶段目标，但无论选哪个，让整个团队都知道我们在优化什么。
3.3 OKR（目标与关键结果）
Google 用 OKR 对齐团队目标，让每个人知道自己的工作和大目标的关系。
一个示范性的产品 OKR：
Objective（目标）：
让商户觉得 RentHub 是管理上架物品与租赁订单不可缺少的工具
Key Results（关键结果）：
KR1：月活跃商户数从 X 提升到 Y（量化）
KR2：核心支付/结算链路使用率达到 Z%（采用率）
KR3：NPS（净推荐值）达到 +40（用户满意度）
OKR 的核心价值：它让开发者知道一个功能做出来是为了什么，而不只是执行任务单。
4. Jobs To Be Done（待完成的任务）理论
这是哈佛教授 Clayton Christensen 提出的框架，被 Apple、Intercom、Basecamp 等广泛采用。
核心思想：用户“雇佣”产品来完成一件事。
人们买的不是 1/4 英寸的钻头，他们买的是 1/4 英寸的孔。 更准确地说，他们买的是“把画挂在墙上之后，家看起来更美好的感觉”。
问题不是“用户想要什么功能？”而是“用户在什么情况下会'雇佣'我们的产品？他们想要完成什么任务？”
RentHub 的 JTBD 分析：
| 用户 | 情境 | 雇佣的任务 | 可替代方案 |
|---|---|---|---|
| 商户 | 账期/结算日到了，不确定租户是否已付款 | 快速确认各笔订单的支付与到账状态 | 逐一微信追问 |
| 商户 | 合同即将到期，不知道租户是否续租 | 了解续约意向，减少设备闲置 | 打电话问 |
| 租户 | 需要支付本期租赁费用，不确定渠道与账户 | 快速、可追溯地完成支付 | 私下转账 |
| 租户 | 提交售后/争议工单后，不知道是否有人处理 | 看到处理进度与反馈 | 打电话、发微信 |
这个分析告诉我们：平台的竞争对手不是另一个 App，是微信和电话。用户之所以要用 RentHub，是因为它比这些“现有解法”更便捷、更有保障。
5. 综合应用：做一个功能时怎么用这些框架
下次开发一个新功能，按这个顺序思考：
- JTBD：用户在什么情境下会用这个功能？他们想完成什么任务？现在他们怎么做的？
- YC：有没有真实用户告诉过我们这是个痛点？我们愿意先手动服务几个用户来验证吗？
- Apple：这个功能的最简形式是什么？能不能砍掉 50% 的复杂度，同时保留 90% 的价值？
- Google：这个功能上线后，哪个指标会变化？变化多少算成功？