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