本文由作者 我是仔仔侠 于社区发布

你看着他，他也看着你

这是前段时间拍的小区里的流浪猫，一个窝在车底乘凉，一个在骄阳下嬉戏，偶尔间的一个对视，被不经意间记录下来。

其实，这个和今天想讲的并没有直接关系。但是 随着工作、生活阅历的增加，我愈发会觉得自己做的每一件事，都在无形的影响着别人，也在被别人影响着。处理各种关系并作出决策，是做产品管理工作后最大的挑战和收获。

接下来，我以自身真实经历，来阐述下不同场景下我是如何思考、判断和处理各种管理问题的。你也许会在上图中找到自己的影子…

加入新团队

一个人加入新的团队，兴奋和期待是主旋律，同时也会掺杂点收敛。另一面，团队成员也是如此。

新的团队，我遇到过如下几种情况：

①完全全新的一块业务，需要从0开始组建团队。

②初期团队已经耕耘了一段时间，需要加速和强化团队建设。

③带着已有团队转战到另一块战场，需要快速适应并切入该市场。

这几种情况是不是和产品所处的各个阶段很像？从0到1的立足，从1到100的复制，从1泛化到A。 虽然不同阶段的处理方式不同，但都需要先了解事物的情况。

我一般会从几个方面来了解新业务：

1. 公司情况

最能反映公司实际情况的，就是公司的组织架构。

举几个例子：公司一级部门中的非职能部门往往体现了公司的现金牛业务和重点发展业务；你所在的部门中是否包含关键的职能角色，决定了你的考核方式；

如果能搜集到近几年的组织架构图变化，就能清晰的看出各块业务的发展；从天眼查等外部系统对你所在公司的投资关系进行梳理，可以进一步分析公司的资本运作情况和泛业务链条。

2. 团队情况

最能反映团队实际情况的，就是团队成员结构。

包括成员的年龄结构、司龄结构、职能结构等等。不同公司在用人策略上的偏重会从大面上影响团队结构，团队里的关键人员会从微观上影响。

所以我一般的做法会在加入后先和HR混熟，再通过一段时间的观察来理解和判断团队关键人员的战斗力和潜力。一般情况下，我不会通过一两次的对话来做判断，这种的偏差性是极大的。

3. 产品情况

最能反映产品实际情况的，就是产品市场商业化过程的速度比。

产品研发设计耗时 / 产品生产制造耗时 / 产品市场推广耗时 / 产品市场进入耗时 / 产品市场深化耗时，产品耗时的占比说明了产品各个环节存在的问题。

尽管很多时候暴露出来的问题并不是由所在部门负责的，但是了解产品的全周期可以更好的帮助你在过程中进行决策，也是搞产品的必修课。

说实话，对于产品情况的把握，是我犯错最多的部分，也是无法避免的部分，因为去了解新的业务所给的“观察期”一定是不足的。

你会发现，当接手一个新业务、加入一个新公司，给你的“观察期”越长，这块的业务越复杂。而“观察期”结束后，手上的牌一定是“烂牌”多于好牌，挖个坑等你来生活的只怕你还没睡醒吧。

从哪开始?

之前，我自己包括我观察过的很多别的领导，在渡过“观察期”后，就开始了以自我为中心的工作方式。自己想做的事，自己的工作习惯，自己的沟通方式。越是大刀阔斧干的快，越是完蛋的快。

这种和做产品时以产品为中心是一样的错误，工作也许做的很漂亮，但没鸟用。

A great vision is the short, clear description of what value the company will deliver to its customers both now and in the future.  

大概从16年左右，我在加入新团队启动业务时，都会尝试先去同步和对齐公司在这件事情上的愿景。如果自己对于公司的愿景不认同，基本就直接走人了；但凡开始启动，那么从自身角度，对这个愿景一定是认同的。

但有一个重要的点，一定要提一下：

认同愿景的同时，要忽略那些远离自己能力之外的困难和不足，假设组织里的同事同样优秀，能解决掉这些问题。积极点说这叫信任，消极点说这是让自己轻装上阵，做好持久战的准备。

构建新团队Sprint，开始

愿景是用来对准目标的，策略才是用来指导执行的。

在加入团队时关注的几个点：公司、团队、产品，在启动时也要放在一起考虑。我会依据愿景，设计出一个短期内需要被验证的策略，分别在公司、团队和产品三个维度进行考量。为了好理解，我称为新团队Sprint。

为了更好理解，我拿一个真实案例来说明。

我加入D公司负责组织新业务时，该业务已经有了基础的团队和产品，并运行了不到一年。通过“观察期”的沟通，D公司希望加速这块业务发展，并作为公司级未来三大战略之一。

我从公司、团队及产品维度总结出来几条与产品愿景相违背的问题：

• 部门中没有HR、市场等关键职能，业务还处于被验证的环节

• 团队结构偏年轻化，职能结构划分很细，基层人员成长有限

• 产品线多、工作繁杂，单位效率没有加速度

• 产品工作缺失运营思维，与市场存在比较大的脱节

经过了一年的试运行，公司期望有更快的发展，但暴露出的问题无法证实在接下来的几年里能加速。所以，新团队Sprint的目标定为对产品业务加速度提升的验证。我们借助下一个产品版本的定义进行实践。

新团队Sprint目标，加速

在工作中保持一定的速度，相对简单。做好计划，按计划执行，就能有相对可控的收益，速度是有保障的。但加速度，往往涉及对原有习惯、规则的破坏，是比较难的。

我把过程中出现的问题按照提升加速度为目标进行了拆解，包括但不限于：

• 混合产品和设计职责，挑选合适的全职产品经理，应对将来更多的新产品

• 把市场侧问题引入到产品侧，包括产品的营销、服务等，加速形成完整且统一的产品链条

• 引入知识管理和数据分析工具，最大化提升团队的效率和运营意识

• …

这所做的一切，在交付新产品、产品迭代中无声无息的持续进行，而我个人用于衡量的唯一标准就是团队加速度是否在提升。

管理产品线和团队的起点，本质上和产品管理无异。大方向正确，核心指标定义正确，可度量的持续前进。当然，还有很重要的一点，就是持续给团队信心！

管理的日常

最初做一个产品的产品经理，更多的成就感来自于产品的output；而做产品线和管理产品团队，更多的成就感来自公司愿景的outcome。

在日常的管理中，我会更多的把视角放在整体收益的增加上，这会比单纯的产品管理会复杂一点，主要体现在：

• 需要综合考虑公司、团队、产品间的各种问题因素

• 决策更多涉及向上的管理

由于我还是个管理上的新兵，所以更多的谈谈平时我做的最多的管理手段及原因。

1.信心建设

我身边出现过很多优秀的管理者，他们和优秀员工之间最大的差别是：每当工作结束夜深人静独自思考时，不管多么疲惫，都会呈现出不同程度的焦虑感；而第二天又会满血复活式的投入工作。

这种状态很贴近 stay hungry ，也是对 组织信心 的一种体现。

作为管理者，对团队，乃至对上级，进行信心建设是最为必要的。我在这方面，还有很大的短板，但我会强迫自己做好向下信心建设的同时，更多的做好向上信心建设。以下简单列举一些我的事项：

• 周报：周期性对团队工作结果进行反馈和输出

• 市场情况同步：市场大捷和遭遇瓶颈都不影响信心的建设，把问题藏着掖着才是最可怕的

• 挑战性任务授权和总结：分配尽可能难的任务给成员，自己扛风险，成果给大家

• 提供与优秀团队合作的机会：我当程序员的时候最怕与市场脱节，同理

通过上下的信心建设，对齐大家对产品愿景的一致性，并形成规律性的协同方式。很多时候短期的小成功只能够提升士气，但是并不能保证在持续遇到困难时团队还拥有足够的韧劲。

2.讲故事

我在和我孩子的教育沟通过程中，最欣喜的就是看到他在说话时用词、表达逻辑、语气、肢体语言上的成长。这个综合性的展示出他在知识积累、问题思考深度、生活阅历上的成长。

而在产品管理上，讲故事也是一种综合性的表述方式，即有利于传达，也有利于学习。

我一般会把如下需要解决的问题编成故事：

• 传达产品愿景、策略、进展

• 讲述某个产品逻辑或领域模型

• 给市场说明产品成果，和产品说明市场需求

• 消化团队内的误解和矛盾

而更重要的，是培养团队内所有人学会讲故事。这不仅仅是对个人能力的培养，更重要的是减少团队沟通时的语言障碍。

这也是为什么我所带的团队里，通才永远优于专才的原因。不是因为专才不好，而是光专不通只会给团队带来更多的管理成本。想要专精，首先必须成为一个合格的通才，学会讲故事！

3.关注中期目标

团队做计划和执行时，会因为个人素质、做事风格等各方面因素的不同，导致产品目标不同程度偏向近期或过于长远。

我之前的所有失败产品经历告诉我，过于短视或务虚都会加速产品失败，只有不断去制定中期目标并执行才能提高成功率。

举个例子：A产品的近期目标和三个月内的backlog都和清晰，但三个月后的仍有很多不确定性，那么这三个月的计划要不要执行？B产品的长期目标和Roadmap都很明确，但是启动面临很多困难，要不要等着把疑问消除后再执行？

从个人经验来看，A在短暂获得成功后会逐渐丧失产品信心，B会一直犹豫不前然后仓促上马。或者，会有其他失败的可能性。

人是一个神奇的动物，看重短期的确定性又憧憬长期的可能性；做产品就是在不断的克服人性的弱点。

回到上面的例子，有个简单的方法可以上手：

1. 找到当前产品的状态作为起点，对准你的产品愿景。

2. 拟定几组半年期目标，只要不与愿景违背或偏离就可以入围。

3. 针对几组半年期目标，设定对应的核心指标。

4. 对每组核心指标进行 价值广度、市场深度、完成信心度和成本四个方面的评估，选择一组确定下来。

5. 坚定不移的执行半年期目标，并在过程中捕捉偏差。

这个逻辑其实和sprint很类似，做决定时要全面谨慎，执行时要坚决。最关键的，不断给自己这个心理暗示，不管外界有多少反对声音。

4.选择性介入细节

之前做执行时很多人说管理是管人，做管理时很多人又放不下事。确实很纠结！世界中大多如此，纯粹的黑白往往只能看解决不了问题，还是50度灰好。

不管事只盯人，事情会断档；只盯事不管人，人迟早流失掉。所以，从长远来看，两者失败的可能性是一样的。

从管理风格上，我会优先管人。因为团队综合战斗力无法提升，中长期失败是一定的，所以要先杜绝这种情况发生。其次，在每个产品的关键问题上，我会选择性介入，介入的时机就是团队无法再为其承担结果。

说到这，我总结了一下，工作中其实大部分内容看似有很多问题但其实无需介入。比如：

• 这个需求没做过完整的调研，到底能不能做

• 这个设计反复评审了好几次还是有问题，到底需不需要忽略

• 这个超出了我们的职责范围，到底管不管

• 这个项目资源不够，到底接不接

• …

当事人分析这些问题时，主要就是两个问题：

1. 过多的关注解决方案而忽略问题

2. 眼里的困难比动力大

当事人如果能凡事从问题域入手，更加关注价值，其实很多事答案是明摆着的。当这些事不能被自行消化时，就会变成团队的管理债务，也是我最不愿意介入的细节，即便它时不时还是会发生。

日常的管理其实并不是分享给管理者的，而是希望把这些原则和逻辑上的东西分享给所有产品经理和从业者。管理只是一种手段，产品的成功与否只要方向不是错的，大概率还是看团队成熟度。

你、或者他，只是换了一个视角

其实看到这，你可能会发现，产品管理和产品线管理（部门管理）并没有本质上的区别。

产品解决用户问题，产品线需要解决组织问题；产品实现用户价值，产品线实现组织愿景。希望各位产品经理读者，可以从我阐述的视角了解到你们的公司，你们的管理方，引发一点点思考，足以。

最后，附上一张大神产品线管理的trello截图，供大家理解参考。

------正文分割线------

点个“在看”吧