为什么你疯狂加班，还是没啥产出？
最近越来越发现一个问题——“感觉团队的产品小伙伴都不太会工作”。主要表现在效果和工作时长完全成反比。天天加班到晚上10点，然后产出的结果……。（PS：偶尔摸鱼是肯定的，也没有怎么偷懒）其实就是工作方法的问题。其中需要记住一点：工作方法肯定能影响到工作能力。
我做事的方式是刚入职场时，向几位腾讯的大佬请教后，自己边工作边整理的。（PS：方法肯定是对你有效的……）
一、产出一定有结果和目标
小伙伴A在周会上汇报工作时，从业务侧需求的沟通到需求的二次澄清，从立项到项目上线。最后在目标和结果产生的表现时，说——没有达到预期。问接下来是否有对应的解决方案时，说——暂时没有思考到。
后来才发现这并不是个例。而是大部分产品经理在工作时都会遇到的问题。没有结果的产出，过程再华丽只能作为复盘会的反思。
但是反思过后呢？一定要伴随着结果和目标。John一般是这么做的：
在梳理产品的过程中，这版本迭代需要在什么时间达到怎样的目标？
- 如果是业务侧活动类型（短期）的需求，需要同步业务侧制定运营计划（计划一定要伴随方案和目标），根据运营计划做产品迭代（用一次性解决方案还是做成可配置的常规解决方案？）
- 如果是产品规划（长期）需求，提前想好这个模块的迭代计划（通过产品路线图展示出来），和其他模块是否有衔接点？以及如何协同？
如下图所示：
如果不能达到目标，解决方案是怎么样？
未尝胜先思败。想好后路很重要，版本的每次迭代都有三个deadline：需求澄清最后期限，产品评审最后期限和产品上线最后期限。
当业务侧提出活动类型需求，产品经理要和业务方沟通清楚没有达到目标的补救方案是什么？（PS：如果没有，让业务方梳理清楚了再沟通）；如果是产品规划需求，尤其是在需求澄清最后限期没有思考清楚，那就给版本做减法，快速评审（评审如果都搞不定，那……）并跟进项目直至上线。
如下图所示：
二、方向永远比执行重要
小伙伴B做事非常快，往往今天开完版本沟通会，两天后原型就已经梳理大半了。在版本确认会上，对自己所梳理的方案和结论自信满满。
然鹅，实际上在沟通过程中，其他小伙伴都有更好的解决方案和想法。久而久之，感觉自己真真正正的变成了“执行机器”。
John这儿强调的重点：执行都是搬砖的活（花一定的时间就行），而方向对了，搬砖都是很顺利的。
John一般是这么做的：
在版本沟通会上，把涉及到这版本的功能清单梳理清楚，同时也要把和模块有协同的模块梳理清楚，梳理清楚等待版本确认会上沟通……
比如在电商产品做积分商城时，除了把获取积分和消耗积分的点列出来，还要考虑积分的期限和积分后续是否可以抵扣现金（防止通货膨胀），其中消耗积分有没有兑换中心？兑换的流程是怎么样的？可不可以退货？等等。
如果没有想到对应的解决方案，咱去看看竞品，试着去拆一拆，他们是怎么做的？分成了几个版本？把竞品的功能清单和流程梳理出来。一起讨论讨论是否能被我们借鉴。
在准备方案的过程中，一定要反问几个问题：
- 还有没有其他更好的方案？（最好的办法是找运营模拟下用户流程）
- 这个方案还需要补充什么？（试着把业务路径和用户路径梳理出来）
- 在这个方案中，每个环节有几条出口？我该怎么引导用户一步步走下去？（大致的功能流程图梳理清晰）
- 让业务方的小伙伴模拟后，提出他们的问题。（业务侧这一点时间还是有的，尽情的可以去打扰他们，哈哈哈）
通过一张图整理下：
只要梳理清楚了，把这套方案拿到需求确认会上，我相信起码会给其他小伙伴一些感想。后续再去梳理细节点，这岂不是很清晰？
三、受众永远是第一位的
针对于产品本身来说，首先考虑的是用户的利益。（当然是在用户合法得到的基础上）但是产品经理在工作过程中，这儿的用户就变成了受众，受众可以是你的用户、同事、老板。因为产品经理会接收到来自各方的需求，但是和各方的沟通不能用同一种沟通方式：
- 面对你的用户：你应该以保障他们利益优先，教他们一步步如何操作，给他们参与感和获得感；
- 面对你的同事：先聆听并问清楚后，再梳理出自己的建议，因为找你沟通肯定是和你有关系的；
- 面对你的老板：拿出有效的数据来佐证自己的方案和框架，不必过多的强调细节，当然到达的结果一定要可行并且有条理。
因为我感受很深的是小伙伴C拿着需求池和老板碰接下来的规划。导致老板以为产品规划的方向发生了偏差。
John这边一般是这么做的：
- 这次结果产出的受众是谁？
- TA最重要紧急的是什么？
- 我拟定的方案能否满足TA？
- 我的方案的可行性有多大？执行难度大不大？
通过这四步面对不同的受众应该拿出不同的方案。面对用户展示的是产品经理的细节梳理能力；面对同事展示的是产品经理的产品梳理能力；面对老板展示的是产品经理的产品规划能力。
四、团队协作才能高效工作
小伙伴D能力比较强，所有的事情都想着一手承担，总觉得UI设计没有达标，运营方案不够落地。导致项目组的小伙伴都对他有想法，渐渐的感觉他被孤立了一样。（这是我们之前团队的小伙伴）
John这儿也想强调一点：无论能力多强的人，也是需要团队协作的，因为有更重要的事情在等你。何况你能力并没有这么强！
专业的事情一定要交给专业的人去做。和专业的人配合时，你一定要明白：
- 你能比UI设计师更懂设计规范和设计趋势么？
- 你能比技术更清楚如何实现这个功能么？
- 你能比运营更明白运营策略么？
如果不能，你只是提出意见方，可以和他们沟通并说出你的建议和理由。John一般是这么梳理的：
- 这个模块，可能需要涉及到和哪些人协同？（心里可以圈定人选，然后找到对应协同职能的负责人，和他们说清楚模块规划，接着就是要人了）
- 需要准备哪些资料给到协同人？（把对应的资料梳理，用落地的方案整理出来）
- 接下来就是做实时的对接。（敲定时间节点并以会议的形式沟通）
当你成为某个项目负责人后，你就知道团队协作有多重要。但是前期是要用项目成员的语言去沟通，有效的建议很重要，通过权力干预往往会适得其反。（现在你是我老大，也许下一次我就翻身做主人了。）
五、凡事有交代，件件有着落，事事有回音
不知道你们有没有这样的感受，开会时都讲的好好的（PS：尤其是开大会的时候），然后会后还是各回各家。
这种情况下超级可怕，实际上会导致会后沟通成本超级高，并且与会人没有安全感。是谁的工作范围，就应该优先去解决。交代了的事情就需要去落实，完成后应该给予交代人反馈。
这个是所有职场人需要执行的。否则，你给予别人的安全感会越来越少。
以上只是John简单的总结分享，当然落地更重要。与其我们不断要求别人，首先更应该规范自己的工作。
作者：John，产品狗一枚，微信公众号：产品狗聚集地。
本文作者 @John
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
