极客时间已完结课程限时免费阅读

25 | 三分靠策略 七分靠执行

25 | 三分靠策略 七分靠执行-极客时间

25 | 三分靠策略 七分靠执行

2018-06-16 曲晓音 来自北京
《硅谷产品实战36讲》
课程介绍

讲述：丁婵

时长10:09大小5.02M

在产品增长系列文章里，我给你分享了很多制定产品策略、制定增长指标的经验，但仅是制定了这些策略和指标还远远不够， 最重要、最关键的是执行。
在硅谷，很多著名的风险投资人，衡量一个公司是否值得下一轮投资的标准，更多的是看团队执行的能力，即在有限的时间内到底能取得多大的进展，而不只是看创始人如何口若悬河，或者团队背景多么高大上。
可以说，一个团队的成功，三分靠策略，七分靠执行。所以，对于一个成功的产品团队，高效的执行力是关键。那么， 作为产品经理，怎么才能打造一个高执行能力的产品团队呢？

要在团队中培养结果导向、责任分明的团队文化

很多团队的策略听上去非常靠谱，但到具体执行时却杂乱无章：群龙无首、内部斗争不断，需要花费很多时间在内部事务上，团队效率低下，从而导致产品开发停滞不前。
其实，出现这种问题最根本的原因是，衡量团队成员工作表现的标准出了问题，给了不做事只吹牛的人太多“偷奸耍滑”的机会。
我之前合作的一个团队，有一个工程师非常擅长在大组开会时口若悬河，但是实际操作时却极其不负责任、能推就推，到头来却抢别人的功劳。
但是，他们的团队领导和产品经理并不怎么关注工程师的开发工作，这样的情况一直没有被注意到，所以这个工程师可以为所欲为。这样不仅让其他工程师非常不爽，还大大拖延了整个团队的效率。
那到底怎么才能避免这种情况呢？
作为产品经理，应该和工程经理一道，确保每个工程师、设计师的工作表现有明确的量化标准。这就要求：
每个人有自己负责的部分，并且其他人都知道是这个人负责这部分，对这部分的成绩负责；
工作效果有一个具体的衡量方式，是可量化的，有时间限制的；
这个人遇到困难，可以向他人求助，他人应该帮助这个人，如果困难解决不了，这个人有责任及时汇报给产品经理。
说白了就是，要让每个工程师和设计师觉得自己是这个部分的负责人，引导他们的主人翁意识，这样才能真正推动他们的能动性，并让他们真正在乎自己所做工作的结果。
当你发现有抢别人功劳的事情发生时，绝不能手软，要明确说明这样的行为不被允许，从而保证不会因此影响团队士气。
有了明确的量化标准和责任范围，抢功劳和碌碌而为混日子这样的行为就没有了滋生的土壤，这对提高团队的执行力非常重要。

要把控团队做决定的速度

很多科技公司的文化是希望每个人都有主人翁意识，所以做决定的时候也希望能得到大家的一致同意。 这么做的好处是，团队的每个人都觉得自己受到了尊重，激发大家的积极性，增加团队的士气；而潜在风险就是，要花太多的时间做决定， 增加了执行成本，延长了产品开发时间。
但是，并不是每个决定都需要每个人一起做出。所以，什么样的决定要快很准地做出，而什么样的决定要积极听取大家的意见，就需要产品经理来把控了。
每一个决定都有一个对应的可争论时间，时间长短由这个决定的重要程度决定。最重要的决定可以多花一点时间，积极听取团队成员的意见，让他们每个人都参与讨论，三思而后行。而不太重要的决定，可争论的时间要尽量短，目的是快速得出结论，马上开始执行。
给你举一个简单的例子，我们之前做了一个帮助网红赚钱的产品，需要对这个产品的具体问题进行讨论，然后做出产品决定。你可以先思考一下，在这个产品中，什么决定是最重要的，而什么样的决定是可以快速做出的。
对于什么样的网红有资格使用这个产品的决定，会关系到产品的发展模式、网红的运营模式等，所以非常重要。对此，负责网红关系运营的同事们、法律和支付部门的同事都参加了讨论， 我们花了几周的时间才制定出了策略。虽然这个决定花了很多时间，但让每个部门的同事都有参与讨论的机会非常重要。
但是，涉及到这个产品的某一个小细节，比如新用户体验的第一步和第二步的顺序应该是什么，如果大家喋喋不休，无法取得统一意见，而工程师在等着这个决定进行下一步的开发时，就需要产品经理出面解决了。
当时，我对大家说：“这个决定并不是最重要的，不应该花这么多时间讨论，我们可以先按照原来的顺序，后期根据用户反馈，我们还有修改的余地”。
我这么一说，既让大家意识到时间不多了，我们得赶快开始，又给持不同意见的人留了面子，这样大家就可以很愉快地推进产品进度了。
这个道理非常简单，但是我见过很多被无关紧要的决定浪费大量时间的情况。某个领导突然对某个小细节有意见了，或者两个设计师对某个按钮的样式不能统一意见、开始针锋相对了，在不值得的决定上浪费了太多时间，是我见过的执行能力差的团队的通病。
作为产品经理， 确保产品的执行效率是首要责任，而把控团队做决定的速度是最重要的一环。敢于对团队成员说“这个决定我们讨论的可以了”，并且能够说服他们赶快行动，是衡量一个产品经理能力水平的一根准绳。

明确产品功能的优先级

每个设计师和工程师都有做不完的任务， 写不完的文档和代码，以及加不完的班。所以，指望大家能把所有的工作都做完，不切实际。
我刚入行时，发现一些工程师总是慢吞吞的，他们总加班但产品开发工作就是做不完。后来我发现，他们的时间全花在改一些无关紧要的 Bug 上了，而重要的产品开发工作却被扔在了一遍，拖慢了产品开发进度。
首先，你必须意识到，不能假设工程师和你对优先级的把控是一样的， 在优先级的问题上一定要重复重复再重复， 明确明确再明确。
在这里，我跟你分享一个好方法：明确告诉你的团队成员，哪部分工作是优先级较低的。 你可以向团队成员说明产品优先级时，顺道说说哪些工作确定不是优先级高的；你还可以在路线图（roadmap）上说明哪部分是明确不做的。这样做，可以让工程师排除不重要的工作，减少浪费时间的情况。
优先级高的内容毕竟有限，但很多时候工程师有非常非常多的任务需要处理，经常一投入到代码中就忘记了产品优先级、指标，或者别的组的人一催，就忘记了什么工作是最重要的。
所以，如果你能清楚的告诉工程师什么内容是不重要的， 这些内容出现的时候可以忽略， 别的组的人催的时候可以拒绝，就可以帮工程师减少很多分散精力的工作。
其次，你需要注意的另外一个问题是，产品的优先级要每周至少沟通一次，这可以强化团队成员的优先级意识，让他们更好地规划自己的时间。
我的团队每周都有一个工程师优先级会议， 会把所有的产品功能一个一个地捋一遍，明确优先级，如果有突发情况需要修改优先级也会在这个时候告诉大家。这样的优先级会议，我一般选在周一召开，以方便工程师和设计师合理分配他们一周的时间。
最后，只有团队成员都了解了其他人的优先级，才能更顺利、有效率地合作。
比如，工程师 A 和 B 都需要我做代码评审，如果我们都知道工程师 A 这部分的内容优先级更高，对产品更重要，我就可以先帮工程师 A 评审，而工程师 B 对此也不会有怨言。
因此，清晰沟通了产品优先级，团队的合作和执行就成功了一半。

总结

今天，我跟你分享了高效执行对产品团队的重要性，并跟你分享了三个提高团队执行力的方法，希望你可以把这些方法用到日常工作中。
第一，作为产品经理要在团队中培养结果导向、责任分明的团队文化，杜绝抢功劳的情况，让每个工程师明确自己的任务是什么、责任是什么，以及对团队的贡献是什么。
第二，要把控每个产品决定值得花费的时间，对于在不重要的决定时花太多时间的情况，要适时果断地给出方向， 让大家先执行，避免浪费太多的时间。
第三，要定期召开优先级会议，让每个成员明确自己的优先级，了解他人的优先级，不只是告诉大家什么工作重要、值得做，更要明确什么内容不重要、不值得做。

思考题

你的团队在执行上遇到的最大问题是什么？
欢迎你给我留言。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 6

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
24 | 产品增长的代价，如何权衡取舍？
下一篇
26 | 为什么加班很久但是没成果？产品开发流程有问题
unpreview
 写留言

精选留言(17)

  • luna
    2018-07-30
    我觉得我的执行的路上最大的问题就是上司对一些无关紧要的细节干涉太多浪费太多工作资源
    12
  • 麒少爷
    2018-07-03
    衡量一个产品经理成熟的标志我觉得是三件事 1、任务优先级的安排（主要指产品功能范畴） 2、学会取舍（开始考虑成本） 3、收益评估（能够自主独立评估一件事的收益） 这三件事是我认为平时我们应该自己去做，但很多时候都放手听从别人指挥了
    12
  • 向哲
    2019-10-01
    需求变更，有时候很难说服老板，会在产品开发一半，加入新的需求，除了对需求进行管理之外，还需要加强和老板的沟通，了解老板变更需求的原因，对症下药。
    5
  • ヾ(◍°∇°◍)ﾉﾞ
    2018-07-11
    你之前说要靠影响力而不是管理，但是这里好像说了一定要很好的做好把控和量化。这里是不是你随着级别的变高，责任变大后，不得不做的一些改变？
    5
  • 山瑟薇
    2018-06-20
    谢谢分享很多共鸣的地方，还有几个问题： 1.权责明确后如果出现那种 同级别产品同事说这不是我主要负责的不配合怎么办？因为很多工作是有交叉点 2.如果出现同一个开发 再做两个不同PM负责的功能，每个人都说自己的功能是最重要的怎么办 这个时候强调的优先级怎么定 现实是谁催的急做谁的 但是往往忘了哪个最重要
    2
  • 行
    2019-07-14
    感觉这篇儿写的是项目经理的工作
    共 1 条评论
    2
  • nezumi
    2018-06-25
    请问老师 pm什么情况下需要做代码评审呢

    作者回复: 我们pm不做代码评审

    1
  • PP
    2020-12-24
    缺乏主动性和相互合作性，各自忙碌。
  • Sinvi
    2020-12-15
    天天改一堆无关紧要的东西，却忽略了更重要的产品开发。
    1
  • Eden Ma
    2020-12-06
    产品还要做代码评审的吗？ 是评审技术方案对需求的影响吗？
  • 毕达哥瓦斯
    2020-11-16
    人太多，信息同步上花的时间
  • 彩色包
    2020-03-29
    执行的重要性
  • Mild
    2020-03-10
    1.老板对细节的干涉： 2.一开发多条产品线，不同产品经理的，产品经理需协商排优先级； 3.执行环节有问题不及时沟通；
  • Raymond吕
    2020-01-06
    执行上问题最大的是遇到问题不及时沟通，拖到不能再拖，或直到开会才将问题暴露出来。 人更倾向于不报忧，万一解决了呢？万一没往坏的方向发展呢？具有“万一”思维的工程师就会在执行过程中比较被动，导致执行出现偏差。
  • 瑞虎
    2019-01-16
    耽误进度问题是，需求争论不休，耽误了不少时间
  • Leio
    2018-10-20
    产品团队分了好多职能，路线图定完，但设计团队在执行时不同目标的产出时间不一样，开发又根据策划案的产出来排开发，这样就会出现不重要的案子先开发，重要的案子连影都没有，周期一长，这种情况就越严重，优先级就比较难起作用，整体看，执行力就形同虚设，怎么破解？
  • SuperSnow
    2018-09-23
    代码评审你们公司谁来评审，产品经理还是项目经理?