编辑导读：一个团队的执行力低，最主要的因素就是因为领导者的执行力低下，决策效率低，无法给团队传达明确清晰的目标。所以对于团队管理来说，掌握目标管理法是非常重要的事情。本文作者从自身经验出发，对产品目标管理的四个步骤展开了梳理分析，与大家分享。

人如果没有更层次的追求，就会在低层次中与管理者斗智斗勇。

为什么有的团队总是士气高涨，即便条件艰苦，总能在中创造价值。而有的团队条件优越，却总在细微处与管理者纠结。

老西听到过“即便不要工资，我也愿意跟着他干”，也见过因为一次打车报销而骂骂咧咧几天后离职的。

在这些年经历的几次创业团队，以及许多团队管理过程的观察，这是一个普遍的问题。

一支团队的士气、战斗力与这支团队的使命感密切相关。

如何打造一支充满使命感的团队呢？

其核心在于如何构建好一支团队的目标，而目标不是一句口号而已，目标管理是一种能力。

所谓领导，是Leader的音译，作为一个Leader，其工作的核心便是领导着团队去实现一个个目标。

所以，今天老西来聊聊，作为产品Leader，如何掌握目标管理法，去打造一支使命感的团队。

第一步：构建愿景

1963年，一个黑人在华盛顿林肯纪念堂发表的了一篇演讲，直接推动了20世纪的黑人平权运动的进程。

马丁·路德·金的《我有一个梦想》，这个故事大家一定都听过。翻开历史，我们可以看到一切伟大进程的起点，必然有一个伟大的愿景。

同样的，作为一个Leader，你是只想带着团队默默混着不出错，还是想一起“折腾”一下世界？

说起来有些中二，关于团队管理方面。我问过Leader们最多的一个问题是：你对这个团队的梦想是什么？

梦想，在企业中我们叫做愿景，是一个团队的原动力。尤其在一些初创企业中，如果作为Leader，目标只是赚钱，那么这个团队的格局最终必然会影响其发展，甚至在工作过程中行为发生变形。

所以构建团队的愿景是目标管理的第一步，也是最重要的一步，这是给团队注入原动力的过程。

当然，在谈愿景构建前各位可能会遇到类似几个问题：

• 构建愿景听着像是一个企业上的事，是不是只有CEO能做？我只是团队Leader有必要制定愿景么？
• 初创企业本身方向就容易变动，一个小企业就定愿景是不是太不务实，太装了？
• 我和团队本身就处于一个已有愿景的企业中，是否还需要构建团队愿景？

面对以上问题，其实核心就是一个：愿景不限于客观条件。

无论你是CEO也好，还是团队Leader。无论你是初创企业还是BATM等各大厂，愿景是你要和团队在将来想要实现的一个想法。尤其对于产品来说，作为产品最大的优势就是敢于做梦。或许最初你们的产品只是源于解决一个小的场景问题，但这也可以延伸出未来对社会宏观层面的影响。而这种影响便是团队坚定而强大的原动力。

那么如何去构建一个有意义，有原动力的愿景呢？首先我们看看一些伟大企业的例子。

各大企业愿景案例

在《产品总监晋升之道，游戏思维的团队管理艺术》中，我们也举过这些例子。

总结下来优秀的愿景通常具有以下三个特点：

1. 目标正向，以正向的价值观为基础
2. 足够宏大，面向社会、人类、乃至全球的问题
3. 令人振奋，使团队跃跃欲试为之努力的

愿景不是简单的几个数字，例如将企业做到1万人以上，实现多少盈利等，为什么呢？

因为人们内心里是不会单纯为了金钱而卖命，但正向的价值感就不一样了。所以，好的愿景是让人们每做一件事都是充满了价值感回馈的。

同时，愿景要足够宏大，如果太容易实现，那么团队所显示出的格局便太小了。成员们的自豪感就会非常低，甚至不愿意对人说出这个愿景。

除此之外，团队Leader可以通过一些提问的方式，来帮助我们和团队真正统一愿景，可以尝试把团队找来坐下，一起回答以下问题：

• 你为什么要在这家企业/团队 工作？你喜欢这家企业/团队 的什么特点？
• 10年后，你希望这家企业/团队看起来是什么样子呢？ 你希望这家企业到时缔造出怎样的成就呢？
• 如果这家企业/团队不存在了，这个世界/企业会有什么损失？
• 如果我们为之工作30年后，将来我们可以告诉子孙们，我们都做了些什么？
• 我们的产品能给这个世界解决什么问题？
• 通过系列的问题，挖掘团队中对愿景认知的差异性，从而建立统一。

当我们遇到战略分歧、重大优先级分歧、什么该做什么不该做的矛盾时，因为有了愿景的统一，便可以解决这些问题。

所以很多时候愿景，才是团队的真正核心竞争力。

愿景能够在解决我们为何努力，朝什么方向努力，如何去做正确的事，不该去做什么的问题。

对于初创团队来说，如果你的愿景方向足够的长远伟大且正确的话，那么比起其他竞争对手，已经决胜于刀鞘之内了。

第二步：构建里程碑

有了愿景，是否就足够支持团队有效的发展？当然是不够的。

愿景是团队的原动力，是团队要走的方向，而如何带领团队一步一步实现这个愿景，就是作为Leader的能力了。

所以如何构建好里程碑，就是一个优秀Leader的核心素质要求了。

关于构建里程碑，其最核心的一个字就是“拆”，这点对于产品Leader来说，其实相对友好很多。作为产品本身就需要擅长拆解一个个需求，把需求变成一个个功能形成版本，最终解决用户的需求。这个过程其实和我们说的拆解里程碑是非常相似的。

首先，关于里程碑的定义。一般团队都会默认里程碑等同于时间计划，然后围绕的时间进行拆解愿景。事实上这是片面的，里程碑其实有多种维度，最常见的维度有以下三个：

1. 时间维度，例：季度、月度、周
2. 数据维度，例：用户量、满意度
3. 生产维度，例：版本计划、研发方向

在这三个维度中，时间维度好理解，例如大的方向1-3年，3-5年的的大战略目标，中等里程碑年中/全年目标，最普遍的是我们常说的季度规划，月规划。基本上能称之为里程碑目标的时间颗粒单位通常不低于月。

数据维度，更多其实是从运营、产品规划角度，举个简单的例子，一个产品用户量在DAU在5万时，和5千万时，团队所要解决的问题就完全不一样，那么这对团队来说就是一个用户量的里程碑目标，当达到每一个里程碑时，对团队来说是一个激励，同时也是对下一阶段的新开始。

生产维度，这是一个产品和团队能力的里程碑，不是所有的产品和团队都是生来就是最好的状态，这是一个持续打磨迭代的过程，而有过程便是有里程碑的。

从产品来说，在生产维度的里程碑可以是一份产品路线图，把团队希望的产品最终实现的目标，按照研发进度及时间的迭代计划。如下图

产品路线图

当然，团队不只是互联网，在一些传统行业是一样的，像”通讯行业的从1G到5G，生产行业的流水线生产效率，无人驾驶中的智能驾驶等级”等等。

以上只是构建里程碑时的几个维度，看似简单的拆解，而真实情况下，对团队管理者最难的往往就是里程碑构建，愿景我们可以大胆的想象，而里程碑确实要实实在在根据团队情况，行业情况，企业内跨组织评估等等，是需要多维度衡量决策后的一个结果。

因为需要关联愿景，同时又要直接执行，需可实际的看到结果，所以在优秀的里程碑需要具有三个属性：

1. 逻辑性
2. 强结构
3. 可行性

在初创/小型团队中，我们可以按照这三点去检查我们的里程碑是否健康，大多情况下，团队能力评估上容易出现问题，所以需要特别注意的是可行性。

而如果你是一个中大型企业的团队Leader，那么在做构建里程碑这一步时，建议的方式走以下三步。

1. 根据情况，拆分战略目标
2. 收集资料，评估团队能力
3. 按照评估，授权组织分工

尤其但团队超过10人，作为团队Leader在做目标管理是要特别主要做好授权，这是因为个人精力是有限的，如果希望更好的专注于带领团队实现目标，团队授权是必须要开始注意的一点。

第三步：执行目标

愿景，里程碑，二者从时间角度都是跨度相对较大的一个目标，在实际产品/团队的日常管理中，通常我们还需要将目标落地，需要指标来衡量每一个结果是否达成，而这时候管理喜爱，员工痛恨的词：“KPI”就出来了。

关键绩效指标(KPI：Key Performance Indicator)是通过对组织内部流程的输入端、输出端的关键参数进行设置、取样、计算、分析，衡量流程绩效的一种目标式量化管理指标，是把企业的战略目标分解为可操作的工作目标的工具

KPI本质从一个目标衡量的指标角度是没错的，招恨的是Leader们的使用方式的错误。

通常管理的KPI使用方式是，企业定一个数字，管理在根据这个数字直接分配到每个人身上，再将KPI与员工的绩效挂钩。

而这个过程中，作为员工是被动接受一个指标，同时这个指标竟然还直接变成了评价个人工作的态度、能力的一个标准，最终还和自己的收入挂钩，请问谁会发自内心的对这个数字有好感呢？

可作为管理者，又不可能不监控执行结果，那到底该如何做呢？

首先，我们追踪的执行目标事实上是由里程碑拆分而来的，那么这个数字的关联性是优先需要保证所有人一致理解并认可的。

其次，执行目标换个角度来说就是更小的里程碑，是实现每个大里程碑的被量化后的各个关键结果。那么想要得到好的结果，只是到最后验收肯定是不够的。有好的过程，才可能产出好的结果，我们需要持续的关注在执行中的状态。

所以结合以上。我们可以试试这样管理执行目标：

1.在执行目标指定的过程中，首先保障里程碑的关联性被大家所理解

2.与员工保持充分的双向沟通，让成员感受到“这个结果的好坏，不是用来衡量人，而是衡量我们里程碑的进展。”

3.确保在制定过程中，符合SMART原则

SMART原则：

——S代表具体(Specific)，指绩效考核要切中特定的工作指标，不能笼统；

——M代表可度量(Measurable)，指绩效指标是数量化或者行为化的，验证这些绩效指标的数据或者信息是可以获得的；

——A代表可实现(Attainable)，指绩效指标在付出努力的情况下可以实现，避免设立过高或过低的目标；

——R代表相关性(Relevant），指绩效指标是与工作的其它目标是相关联的；绩效指标是与本职工作相关联的；

——T代表有时限(Time-bound)，注重完成绩效指标的特定期限。

4.过程中保持执行目标的状态可视化，即可完成的概率/信心度/风险 等

以上是构建目标过程中的前三步的框架，我相信读到这里各位也许有部分还只是理解了原理，但是有没有更直接的例子，告诉我怎么样才能写出一个准确的目标呢？

这里老西整理了一个构建目标的通用公式：

目标公式

例如：2020年10月30日之前，优化11款产品性能，确保产品奔溃率低于0.01%。

这个例子中 “2020年10月30日”是时间，“优化”是一个动作，“11款产品的性能提升”是任务，指标是奔溃率，目标是奔溃率低于0.01%

这是一般情况下，我们构建目标时的公式，对于一个大企业的愿景，通常还需要更加艺术化的调整。但整体而言，对于一般团队的目标构建，这个公式是足够帮助大家梳理目标了。

第四步：持续反馈

即便理论、公式再熟悉，在各位不同的业务场景中，也必然经常会遇到以下问题：

• 目标总是在变化
• 成员参与度不足
• 目标拆分不合理

而这些问题的出现大多不是目标本身，而是在目标执行过程中缺失了反馈，所以在完成前三步的目标构建后，最重要的是我们如何保证对这个目标的持续反馈。

反馈：在系统与环境相互作用过程中，系统的输出成为输入的部分，反过来作用于系统本身，从而影响系统的输出。

持续反馈从定义上是在过程中将产出变成一种改进，翻译过来就是，我们持续在过程中观察情况，即时改进。

我们们不能寄希望于给了一个目标，团队就能给你一个结果。记住，目标从来不等于结果。

你想要一个好的结果，在目标以外，你需要更多的关注、反馈、改进、解决障碍，而不是“守株待兔”。

在持续反馈方面，可视化思维是非常有益的一种模式，在可视化管理方面，参考《项目管理过程中，如何实现可视化的价值？》

其中常用的几个工具，如图：

持续反馈的工具

这些工具是帮助Leader和团队共同参与关注目标状态，而持续反馈的本质不是一个方法，更是一种思维。

目标管理的三大误区

（1）目标，不是画饼

接触过个别CEO说：目标嘛，其实就是给团队画饼，你这饼画好了，团队就留住。

这是关于目标管理的最大误区，所以过去很多人说，“当老板不和你谈钱而谈目标的时候，就是要灌输鸡汤了。”

我相信，确实不少人经历过“画饼”与“被画饼“”，那么目标和“画饼”区别是什么呢？

所谓“画饼”：是说的人希望听的人信，而自己未必相信。

作为管理者如果只是单纯为了让员工相信某些目标、承诺的话，那其实没有什么学习目标管理的必要。

因为骗人，不需要什么技巧，但谎言终会被揭穿，而真正的相信，则是可以看见未来的。

所以，目标管理的第一点是：作为管理者，提出的目标首先是自己要坚信这是准确的方向，并且视其为动力。

（2）目标，不是一个人的事

企业本质是一个由一群有共同目标、使命、价值观的人形成的组织

马丁·路德·金 的“梦想”，如果只是他一个人的梦想，那一定产生不了什么火花。

之所以能够推动一场革命，是因为这个梦想也是其他无数人的梦想。

同样的，如果在企业、团队管理中，如果你的目标只是你自己的，那么对团队来说基本是零作用。

像“打造一个商业帝国”，“一年内扩大团队规模”，“完成几轮融资”等等这种就是比较典型的初创团队中CEO常说的目标。

这种目标，事实上更多对合伙人团队、股东或许有激励作用。但对一般的团队成员，效果微乎其微。尤其是当这个目标成为了管理者在职业发展、在收入方面相关时，是有很大的反作用风险。

（3）目标，不是简单的数字

所以，过去的KPI绩效管理里中，员工一听到就苦不堪言。通常一通KPI绩效管理的发展下来，最后往往成了员工和上层在对一个个数字中做斗智斗勇。

正如我们在游戏设计中，单纯的数字是没有价值的。同样，在团队管理中单纯数字对人而言，也是没有任何激励作用。

所以，在构建任何一个目标时，它都不能是简单的数字，如果有数字，那背后一定要关联着一定意义。

总结

总的来说，目标管理的四步是：构建愿景→构建里程碑→执行目标→持续反馈

• 对于愿景，我们要做大一些，要背负上除金钱以外的社会价值。
• 对于里程碑，我们要谨慎一些，要多维度的评估让团队能够持续向前。
• 对于执行目标，我们要准确一些，要让团队脚踏实地一步步的实现目标。

简化的来说：愿景是为什么做，里程碑是怎么做，执行目标是做什么，持续反馈是做的如何。

而为什么要做产品目标管理，是因为人们真正内心追求价值的驱动力远大于金钱，在目标驱动下的团队，将在无形中建立起这支团队的使命感，一支拥有使命感的团队本身就是我们产品管理者的价值所在。

作者：老西（西特张），微信公众号：倒卖梦想的西特

本文由@西特张 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于CC0协议