框架感的思考 --《10条产品力原则》

https://mp.weixin.qq.com/s/0pMfWuYshuLh0GWsRpyiHQ

《与 167 位增长经理共事后的经验总结：10 条产品力原则》

1. 脑海中始终有一张不断被完善的产品架构图。

原文：往大框架里填充各类小产品；我们往往只负责框架下的某个小产品，但一定要把这个小产品放在整个业务板块里，认清它的目标和功效。把握了产品节奏，才能与业务部门有效沟通，合理安排工作的优先级。

思考：初到一个新公司，先看整个大部门的框架

2. 一份靠谱的 Roadmap

原文：迭代能否顺利完成，往往取决于产品经理的思考深度。在产品路径之外，会叠加运营增长的规划。忽略了运营增长，就可能出现功能上线后没人用的尴尬情况，另外还需要规划产品的数据目标，用户达到多少的时候，开始迭代

思考：不要着急的铺展很多新的业务，即便YY了很多可能给用户带来帮助的东西，如果理解起来很困难，结果也并没有被消费起来，那就会变得很尴尬，口碑在这个环节尤为重要，即工作中的群众基础。心急吃不了热豆腐。

3. 大结局前的反向思维能力

在整个团队都认为某个项目都不错的时候，需要一个人站出来反向思考，用各种角度挑战规划的合理性，往往能避免很多无用功

思考：这一部分暂时理解不了

4. 就算只剩一位工程师也要活下来的求生欲

很多初创公司的融资规模都不支持充足的技术资源，这就要求增长负责人思考每天的人力是否都花在了最好的功能上

思考：不忘初心，回到团队的基础目标，核心目标，不断拷问自己，这个是必须的吗？

5. 上天入地的换位思考能力

考验自己是否真正理解了需求：如果业务方去生孩子了，我是否能胜任她的工作？比如，一款市场投放产品，你能否帮助市场监控投放数据，衡量投放的ROI？简单来说，就是站在业务角度，使用自己的产品。

思考：在接需求的时候，排除掉噪音，他的最核心的需求是什么？延展需求是什么？每项的任务是什么？需要投入的人工是多少？这项他准备怎么用？能带来什么价值？我有没有更好的办法去做？怎么来衡量我做出的东西，的确被应用上了？如果没有被用，是不是可以撤销？

6.ROI 极高的设计生产力

7. 让人舒服的递进式沟通能力

很多时候，在沟通开始前，产品经理其实没必要把功能细节想透。沟通的第一步通常只是发布信号，比如我想做积分换钱功能。不同部门的人听到这个意见之后，会站在不同的角度去思考这一功能的利弊。进过两天的思考，双方再沟通功能细节，效率会有明显提升。

在研发过程中，常出现产品和业务沟通中断的情况。其实保持进度的更新是很有必要的。比如研发进度已经到 30% 了，运营端的内容资源是否也开始准备了？大家信息保持同步，才能更好实现整体项目落地。

思考：我们的产品和业务方，对研发的冲突在于，强势占位，先沟通，且画出原型，强迫研发接受，在被怼了之后，失落。效率低，浪费时间。

这里要同理在自己接需求的时候拷问一番，避免人力资源的浪费

9.Answer First

而依照 B 模式，总结表现结果，尤其是数据表现不好的结果，往往比较困难。但这样的回答，才是我们真正需要的。如果没办法直接回答一个问题，那所有围绕这个问题的讨论都是浪费时间。

反思：夸人和总结，用数据说话