|
|
# 25 | 三分靠策略 七分靠执行
|
|
|
|
|
|
在产品增长系列文章里，我给你分享了很多制定产品策略、制定增长指标的经验，但仅是制定了这些策略和指标还远远不够， 最重要、最关键的是执行。
|
|
|
|
|
|
在硅谷，很多著名的风险投资人，衡量一个公司是否值得下一轮投资的标准，更多的是看团队执行的能力，即在有限的时间内到底能取得多大的进展，而不只是看创始人如何口若悬河，或者团队背景多么高大上。
|
|
|
|
|
|
可以说，一个团队的成功，三分靠策略，七分靠执行。所以，对于一个成功的产品团队，高效的执行力是关键。那么， 作为产品经理，怎么才能打造一个高执行能力的产品团队呢？
|
|
|
|
|
|
## 要在团队中培养结果导向、责任分明的团队文化
|
|
|
|
|
|
很多团队的策略听上去非常靠谱，但到具体执行时却杂乱无章：群龙无首、内部斗争不断，需要花费很多时间在内部事务上，团队效率低下，从而导致产品开发停滞不前。
|
|
|
|
|
|
其实，**出现这种问题最根本的原因是，衡量团队成员工作表现的标准出了问题，给了不做事只吹牛的人太多“偷奸耍滑”的机会。**
|
|
|
|
|
|
我之前合作的一个团队，有一个工程师非常擅长在大组开会时口若悬河，但是实际操作时却极其不负责任、能推就推，到头来却抢别人的功劳。
|
|
|
|
|
|
但是，他们的团队领导和产品经理并不怎么关注工程师的开发工作，这样的情况一直没有被注意到，所以这个工程师可以为所欲为。这样不仅让其他工程师非常不爽，还大大拖延了整个团队的效率。
|
|
|
|
|
|
那到底怎么才能避免这种情况呢？
|
|
|
|
|
|
**作为产品经理，应该和工程经理一道，确保每个工程师、设计师的工作表现有明确的量化标准**。这就要求：
|
|
|
|
|
|
1. 每个人有自己负责的部分，并且其他人都知道是这个人负责这部分，对这部分的成绩负责；
|
|
|
2. 工作效果有一个具体的衡量方式，是可量化的，有时间限制的；
|
|
|
3. 这个人遇到困难，可以向他人求助，他人应该帮助这个人，如果困难解决不了，这个人有责任及时汇报给产品经理。
|
|
|
|
|
|
说白了就是，要让每个工程师和设计师觉得自己是这个部分的负责人，引导他们的主人翁意识，这样才能真正推动他们的能动性，并让他们真正在乎自己所做工作的结果。
|
|
|
|
|
|
当你发现有抢别人功劳的事情发生时，绝不能手软，要明确说明这样的行为不被允许，从而保证不会因此影响团队士气。
|
|
|
|
|
|
**有了明确的量化标准和责任范围，抢功劳和碌碌而为混日子这样的行为就没有了滋生的土壤，这对提高团队的执行力非常重要。**
|
|
|
|
|
|
## 要把控团队做决定的速度
|
|
|
|
|
|
很多科技公司的文化是希望每个人都有主人翁意识，所以做决定的时候也希望能得到大家的一致同意。 这么做的好处是，团队的每个人都觉得自己受到了尊重，激发大家的积极性，增加团队的士气；而潜在风险就是，要花太多的时间做决定， 增加了执行成本，延长了产品开发时间。
|
|
|
|
|
|
但是，并不是每个决定都需要每个人一起做出。所以，什么样的决定要快很准地做出，而什么样的决定要积极听取大家的意见，就需要产品经理来把控了。
|
|
|
|
|
|
每一个决定都有一个对应的可争论时间，时间长短由这个决定的重要程度决定。最重要的决定可以多花一点时间，积极听取团队成员的意见，让他们每个人都参与讨论，三思而后行。而不太重要的决定，可争论的时间要尽量短，目的是快速得出结论，马上开始执行。
|
|
|
|
|
|
给你举一个简单的例子，我们之前做了一个帮助网红赚钱的产品，需要对这个产品的具体问题进行讨论，然后做出产品决定。你可以先思考一下，在这个产品中，什么决定是最重要的，而什么样的决定是可以快速做出的。
|
|
|
|
|
|
对于什么样的网红有资格使用这个产品的决定，会关系到产品的发展模式、网红的运营模式等，所以非常重要。对此，负责网红关系运营的同事们、法律和支付部门的同事都参加了讨论， 我们花了几周的时间才制定出了策略。虽然这个决定花了很多时间，但让每个部门的同事都有参与讨论的机会非常重要。
|
|
|
|
|
|
但是，涉及到这个产品的某一个小细节，比如新用户体验的第一步和第二步的顺序应该是什么，如果大家喋喋不休，无法取得统一意见，而工程师在等着这个决定进行下一步的开发时，就需要产品经理出面解决了。
|
|
|
|
|
|
当时，我对大家说：“这个决定并不是最重要的，不应该花这么多时间讨论，我们可以先按照原来的顺序，后期根据用户反馈，我们还有修改的余地”。
|
|
|
|
|
|
我这么一说，既让大家意识到时间不多了，我们得赶快开始，又给持不同意见的人留了面子，这样大家就可以很愉快地推进产品进度了。
|
|
|
|
|
|
这个道理非常简单，但是我见过很多被无关紧要的决定浪费大量时间的情况。**某个领导突然对某个小细节有意见了，或者两个设计师对某个按钮的样式不能统一意见、开始针锋相对了，在不值得的决定上浪费了太多时间，是我见过的执行能力差的团队的通病。**
|
|
|
|
|
|
作为产品经理， 确保产品的执行效率是首要责任，而把控团队做决定的速度是最重要的一环。敢于对团队成员说“这个决定我们讨论的可以了”，并且能够说服他们赶快行动，是衡量一个产品经理能力水平的一根准绳。
|
|
|
|
|
|
## 明确产品功能的优先级
|
|
|
|
|
|
每个设计师和工程师都有做不完的任务， 写不完的文档和代码，以及加不完的班。所以，指望大家能把所有的工作都做完，不切实际。
|
|
|
|
|
|
我刚入行时，发现一些工程师总是慢吞吞的，他们总加班但产品开发工作就是做不完。后来我发现，他们的时间全花在改一些无关紧要的Bug上了，而重要的产品开发工作却被扔在了一遍，拖慢了产品开发进度。
|
|
|
|
|
|
**首先，你必须意识到，不能假设工程师和你对优先级的把控是一样的， 在优先级的问题上一定要重复重复再重复， 明确明确再明确。**
|
|
|
|
|
|
在这里，**我跟你分享一个好方法：明确告诉你的团队成员，哪部分工作是优先级较低的。** 你可以向团队成员说明产品优先级时，顺道说说哪些工作确定不是优先级高的；你还可以在路线图（roadmap）上说明哪部分是明确不做的。这样做，可以让工程师排除不重要的工作，减少浪费时间的情况。
|
|
|
|
|
|
优先级高的内容毕竟有限，但很多时候工程师有非常非常多的任务需要处理，经常一投入到代码中就忘记了产品优先级、指标，或者别的组的人一催，就忘记了什么工作是最重要的。
|
|
|
|
|
|
所以，如果你能清楚的告诉工程师什么内容是不重要的， 这些内容出现的时候可以忽略， 别的组的人催的时候可以拒绝，就可以帮工程师减少很多分散精力的工作。
|
|
|
|
|
|
**其次，你需要注意的另外一个问题是，产品的优先级要每周至少沟通一次，这可以强化团队成员的优先级意识，让他们更好地规划自己的时间。**
|
|
|
|
|
|
我的团队每周都有一个工程师优先级会议， 会把所有的产品功能一个一个地捋一遍，明确优先级，如果有突发情况需要修改优先级也会在这个时候告诉大家。这样的优先级会议，我一般选在周一召开，以方便工程师和设计师合理分配他们一周的时间。
|
|
|
|
|
|
**最后，只有团队成员都了解了其他人的优先级，才能更顺利、有效率地合作。**
|
|
|
|
|
|
比如，工程师A和B都需要我做代码评审，如果我们都知道工程师A这部分的内容优先级更高，对产品更重要，我就可以先帮工程师A评审，而工程师B对此也不会有怨言。
|
|
|
|
|
|
因此，清晰沟通了产品优先级，团队的合作和执行就成功了一半。
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
今天，我跟你分享了高效执行对产品团队的重要性，并跟你分享了三个提高团队执行力的方法，希望你可以把这些方法用到日常工作中。
|
|
|
|
|
|
第一，作为产品经理要在团队中培养结果导向、责任分明的团队文化，杜绝抢功劳的情况，让每个工程师明确自己的任务是什么、责任是什么，以及对团队的贡献是什么。
|
|
|
|
|
|
第二，要把控每个产品决定值得花费的时间，对于在不重要的决定时花太多时间的情况，要适时果断地给出方向， 让大家先执行，避免浪费太多的时间。
|
|
|
|
|
|
第三，要定期召开优先级会议，让每个成员明确自己的优先级，了解他人的优先级，不只是告诉大家什么工作重要、值得做，更要明确什么内容不重要、不值得做。
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
你的团队在执行上遇到的最大问题是什么？
|
|
|
|
|
|
欢迎你给我留言。
|
|
|
|