砍需求的核心是：开发如何理解产品的需求，并根据自己的理解给出产品建议。
快糙猛
对于中小型项目来说，做事更讲究快糙猛，原因：
- 适合小团队
- BUG 影响到小范围的用户
- 相对来说投入产品比很高
对于大型项目则不行：
- 产品做的事情有时候是基于对数据的判断，但大多数时候是基于直觉
- 用户量多的时候会影响到较大范围的用户
- 规模效应，BUG 会导致大量负面评价
一切都是收益和损失的权衡
Case 生命周期
cumd
创造需求 - 补充/修改需求 - 砍需求
create 创造需求
- 最离谱的错误，没有需求创造需求
- 要钉子还是要洞还是要锤子（用最简单的方案解决问题）
- 提需求还是提解决方案（用户需求和解决方案要分清楚，用户需求是高于解决方案的，如果你一开始就把两者混为一团，你就很难再提出更好的解决方案）
- 我什么都要（猜测用户意图）
- 在错误的地方做过度设计（在一个用户量很少的场景去做提高转化量的工作毫无意义，因为数据太少所以导致数据波动大，这时候还不如想办法提高用户量）
update/modify 补充/修改需求
- 容易忽视数据逻辑
- 猜测用户意图
猜测意图其实是一种常规方式，不是说这个完全不对，而是要学会根据数据反馈来证实自己的猜测，如果数据反馈证实你的猜测是错误的，你会因为 case 需要优化，这个就没完没了了
改需求跟炒股一样，要有止损线。
delete 砍需求
向所有做减法的产品经理致敬
发生以上问题的时候我们如何发现
反复问一个问题，问自己、问产品、问运营、问市场、问客服
用户要的不是功能，是要解决他们的问题，一定要先跳出产品功能
反复问这四个问题：
- 是谁的问题（是用户的问题吗？还是市场的问题，运营的问题，客服的问题，他们的问题跟用户的问题是一个问题吗？）
- 这个问题是不是真实存在的问题（有没有数据/用户调研，是不是预设立场）
- 是不是只解决这一个问题（coding 有个原则，一个方法只做一件事，产品 case 同理）
- 解决这个问题有没有更快更好的方案（要准确区分出需求和解决方案）
Case 发布后
- 产品和技术都应该对需求研发和执行过程中的问题做 review
- 研发关注优化 代码逻辑/效率优化 底层数据结构优化
- 产品关注数据 （实际上研发比产品更了解这个需求上线后会发生什么，研发也应该关注数据）
总结一下，尝试新需求的时候，最小化的去做事情，而不是又大又全