可行性
可行性：团队能不能把它做出来，并且稳定、可持续地交付？
可行性不是“技术上能不能实现”这么简单
可行性的常见误解
很多人理解“可行性”时，只会问：这个功能技术上能不能做？但这只是最低层的问题。
真正的可行性至少包括五层：
| 层次 | 要问的问题 |
|---|---|
| 技术可行性 | 现有技术能不能实现？ |
| 成本可行性 | 要投入多少人力、时间、算力、资金？ |
| 性能可行性 | 能不能支撑真实规模的用户和数据？ |
| 运营可行性 | 上线后能不能维护、客服、审核、监控？ |
| 商业可行性 | 做出来后是否符合公司的商业目标？ |
| 一个方案技术上能做，不代表它值得做； | |
| 一个 Demo 能跑，不代表它能产品化； | |
| 一个功能能上线，不代表它能长期维护。 |
产品经理为什么必须理解可行性？
产品经理不需要亲自写代码，但必须理解技术约束。
1. 提出空想型需求
比如：
“我们做一个完全自动判断用户意图的系统。”
“我们让 AI 自动处理所有客服问题。”
“我们把所有数据打通，实时生成决策建议。”
这些听起来很美，但背后可能涉及数据质量、权限、准确率、延迟、成本、风控等问题。
如果产品经理不了解这些约束，就很容易把愿景误当方案。
2. 错过更好的技术机会
可行性不只是限制，也可能带来机会。
书里也提到，开发人员可以帮助产品经理完善产品定义，比如让开发人员参与早期产品探索，讨论哪些新技术可以解决当前问题。
很多好产品不是产品经理闭门想出来的，而是产品、设计、技术一起碰撞出来的。
技术人员可能会说：
“这个不用做完整系统，先用规则引擎就够了。”
“这个如果换一种数据结构，体验可以快很多。”
“这个模型不适合实时生成，但可以预生成。”
“这个需求真正难的不是生成，而是审核和回滚。”
3. 让开发阶段变成灾难
如果产品经理在前期不验证可行性，到了开发阶段才发现做不了，就会出现：
返工；
砍需求；
延期；
团队互相指责；
上线质量差；
产品体验被迫缩水。
[!QUOTE] 如果产品经理在前期不验证可行性，到了开发阶段才发现做不了，就会出现： 返工；
砍需求；
延期；
团队互相指责；
上线质量差；
产品体验被迫缩水。
三、可行性的核心不是保守，而是现实
不是说“技术难就别做”。
而是说，产品经理要知道：
哪里难；
为什么难；
有多难；
能不能绕过去；
能不能分阶段做；
能不能先验证核心假设。
优秀的产品经理不是只会说“我要这个功能”，而是能和技术团队一起找到： 在当前资源下，最小但有效的产品方案。