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