A Modest Proposal for PM and TPM

从2010年毕业, 经历过 investment banking, bitcoin 和 两个创业项目 (目前在做第三个). 对互联网行业的热爱和创业的热情是我始终没有消退的. 回顾过去几年的经历, 自己经历过 CEO, PM, TPM, HR, Architect 等等各种角色, 以下是我想和大家分享的我对一个 senior product manager / technical program manager 的部分认知和期待.

战略影响力和解决冲突能力

影响 stakeholders 并与他们创建共识

• 很多同学会专注在"影响"和"创建共识"这两个方面, 但是很多时候, 搞清楚谁是stakeholders, 在项目中他们关心和在乎的是什么, 往往是最重要的第一步. 当你搞清楚谁是 stakeholders 以后, 下一步就是创建共识和对齐目标: 时间表, 目标, 工作计划, 和合作规则. 这一步能让团队很快速的在一些简单的事情上面达成一致, kickoff 接下来的合作.
• 当其中有初次合作的参与者, 你可以通过围绕几个技术和具体问题开展一些实际的讨论和研究来建立彼此的信任和尊重. ENG会更加认可切实际和可行的方案, 所以清楚的和他们展示和沟通你的计划很重要.
• 作为一个PM, 一个很重要的职责就是引导 stakeholders 的考虑, 确保项目的最终的 deliverable 是可行的并且能被团队认可的. 一个 full-consensus 的执行方案 / deliverables 很多时候是一个是不现实的, 所以制定一个 near-consensus 的方案并且得到团队的 buy-in 尤其重要.

合作沟通

• 直率 (不是莽撞) 很重要 (不要装逼和掩饰无知, 聪明的团队一眼就能看出那些), 然后做到以下三点: 清楚理解各个参与团队的优先级, 信息透明, 有同理心.
• 建立信任极其重要 (建立不是给予, 别的参与者没有必要信任你, 尤其对没有以往合作经历的. 切记, 建立, 建立, 建立), 尤其在一个比较扁平的组织中 (like us). 自命不凡和 ego-driven 是一定会被淘汰的.
• 如果你想影响技术层面的决定, 主动积极的去聆听和展示你清晰理解可能会遇到, 或者正在发生的问题和 deliverables.
• 冲突是不可避免的, 甚至可以说冲突是直率沟通的副产品. 当你在沟通和解决冲突的过程中, 保持直率和自省自我的认知或者能力不足之处是建立信任的重要因素之一. 保持一个信任和相互尊重的环境是高效合作的前提.

如何解决冲突

• 冲突往往是同一团队的成员之间 (较少见), 或者不同团队之间, 对于要在一定时间或者限制条件下完成 deliverables 而产生的执行环节的取舍不清晰导致的. 与不同团队沟通时, 从他们的角度出发, 和他们沟通执行计划和决策过程, 并且解释其他参与团队的难处和视角, 帮助大家建立同理心和自我认知.
• 一个好的 PM 会在执行过程中确保 stakeholders 能够复审沟通和更改先前制定的方案. 因为一个 real world 场景就是执行过程中还有很多不确定和突发情况, 变通和敏捷在创业公司尤其重要.

团队管理能力

打造一个一流的团队

• 清楚了解你的弱点 (屏蔽和逃避自己的弱点是人的天性), 然后找到可以补足你那些弱点的人.
  例子: 产品团队一个成员, 帮助我监测关键业务数据, 产品团队每天日程和工作安排, 做ad-hoc的市场和竞对研究. 这些在我没有帮助做的不好的方面, 她的 strength 能够补足我的 weakness.
• 对我来说, soft-skill 对于 manager 来说是非常重要的, 拥有好奇又思维缜密的大脑, 不怯大 scope 和复杂项目的性格, 能够持续不断的帮助团队对齐公司的 goal, 会不停的问 "how can we do better?".
  例子: 工程团队的一个成员, 会不停的问非常细致和重要的问题, 确保项目的 scope 理解清楚, 并且在执行过程中持续会展示完成的 prototype 和沟通工作进度, 愿意花时间沉淀自己学习到的工程知识和标准 (写文档), 并且和团队其他成员分享和传授.
• 对于可以 self-unblock (自己移除 blocker) 的人, 我是极度的尊重和认可的. 在执行过程中遇到问题, 可以独立作出决策, 并且给予有用的贡献给技术, 产品和运营团队.

如何维护一个良好的团队氛围

• 信息透明. 沟通过程中直率清晰, 不要报喜不报忧, 大家是尊重一个能够直率面对困难的 manager 的.
• 大方向对齐. 在执行过程中会有很多噪音和突发事件, 时序不断的提醒和明确公司的战略大方向和执行优先级会让团队更有目标感和一致性.
• Ask your developers. PM 经常犯的一个错误就是默认 ENG 团队不能理解业务和产品. Maybe 管理产品不是 engineer 的热情所在, 但我坚信 everyone is a user. 工程师是完全有理解核心业务和产品概念的, 带他们一起参与产品和业务战略讨论会给你带来意想不到的惊喜.
• 周期性的 one-to-one 是和你团队建立信任和认同感的重要一环. 确保在 one-to-one 的过程中打造一个信任和尊重的环境, 让 one-to-one 的同事可以放心的提出 manager 或者其他管理团队做的不好的地方.
• 在 one-to-one 的时候做个聆听者, 让团队成员做 75% 以上的信息输出.

如何帮助团队成长和搭建人才梯队

• Jamie Dimon (CEO and Chairman of J.P. Morgan) 说过 - "Make a safe and respectful environment, people will shine." 对于不满足于 status quo (现状) 的团队成员, 认真培养和赋能, 信任和帮助他们成长, 会是个相互都非常满足的过程.
• 根据每个人的经验, 喜好和能力, 与他们协作制定一个成长计划. 在成长目标上 push 他们去超越自我设置的边界. 让他们从自己的舒适区域走出来, 扩展自己的责任和 ownership 边际.
• Make everyone heard. 在重要的业务 / 产品 / 技术决策上, 确保每个人都愿意和有机会提出自己的想法, 让好的 idea 冒泡冒上来.
• 帮助团队成员和适合他们的 mentor 配对, 一个相互尊重, 相互欣赏的 mentor-apprentice 关系是对个人成长, 工作效率和工作积极性有极大帮助的. 后续持续观察和获取反馈, 确保 mentor 和 apprentice 能够持续学习和成长.

团队管理上的自我认知和自省

不断的问自己以下几个问题

• 你团队的成员会怎么评价你?
• 你如何和行业外的人形容你的工作?
  • 例子: 作为一个 PM, 我的工作是帮助工程团队 ship 用户喜爱的产品并且能完成商业目标. 简至回答团队的问题, 繁至帮助做出正确技术选型或者帮助优化业务和财务目标. 抽象的来说, 我的工作是负责团队的效率和效力, 引导 stakeholders 进行建设性和有行动结论的沟通, 预见和减少可行性风险, 需求风险和商业风险.
• 你怎样评估你的成就?
  • 和 IC (individual contributor) 不同的是, manager 更重要的是要为团队的结果负责, 对于一个 PM 来说, 一 周 ship 的 user story 和修复的产品 bug 数量是一个很好的衡量标准.
  • 团队信息透明度和流动性, 团队是否因为信息不透明, 目标模糊导致执行风险.
  • 风险预见能力, 能够在执行过程中帮助团队减少重复犯错和执行风险.
  • 持续调整自我评估框架: 我在项目中的贡献什么? 我是否在持续降低团队获取信息难度并提高信息流动性? 我是否经常会安排时间让团队可以给我提问, 给予团队需要的帮助, 帮助大家对齐目标, 明确大家的执行项会怎样 impact 公司的业务大目标?
• 我是否在给团队提供一个信任和尊重的环境?
• 团队是否感受到被赋能在工作和创造价值?
• 团队是否在不断的成长和挑战自己的非舒适区域?