上次写这个系列的第一篇文章已经是一年多前了，回汉后和新团队磨合了近一年，通过若干次实验调整和观察，有了一个基本的框架思路，顺便和大家分享下。
一. 没有统一形态的产品团队
我们团队产品设计十余人，应届生一二期居多，设计背景居多，这和我以往带的产品团队有着比较大的区别。90后对自我价值的实现相较于80后有着更加明显的主张性，知识领域相对更加系统专一，对自己喜欢认可的事物有种特别的专注和执着。对于这种团队构成，显然不能按照管理80后团队的思路来做。
分析思路
- 成员年龄是变量，但产品团队要做的事情不会变
- 产品团队要做的事是交付正确的产品，而产品的本质是：满足用户需求的确定性服务打包
- 那产品团队的两大核心任务就是：确定满足用户需求的服务 和 打包服务
- 结合团队现有人员情况，为这两大核心任务分别设定匹配的指标：准确 和 效率
行动项
- 人员从职责上分为：产品管理 和 效率提升 两大序列
- 设定各序列的关键指标：产品定义及需求准确性 和 产品管理流程中效率的提升
- 对于这两大指标（目标）的拆解（关键结果）
二. 对于准确性的理解
准确意味着产品提供的服务或者解决方案满足目标用户的既定需求，也意味着在产品研发过程中的无二义性。中国的产品经理不比国外，往往需要贯穿整个产品的始末，精力分配决定了这个准确性指标的执行结果。但从大多数事实结果来看，产品失败的最大内部因素就是错误的定义了产品，其次就是无法准确定义产品及需求导致循环的迭代内耗。
对于此，几个行之有效的建议：
- 用沟通代替独自思考
如果之前你用绝大部分时间自己思考产品，那么尝试着花7成以上的时间和不同的产品干系人去沟通。
- 用协作代替写作
无论是大量的文字抑或图表，都会让人从心底产生排斥。先抛一个砖，靠多方协作去打磨它，哪怕成不了玉也是用户想要的。
- 用本质陈述代替表面陈述
假设你在陈述一个需求，直接从结果或者产品的实现的讲，所有参与者都会围绕细节去辨识真伪；那么尝试着从原始需求开始讲起，利用归纳推论出需求的本质，再用演绎推演原始需求外的一些可能，最终映射到需求的解决方案。
- 用完整的细节代替临时性口述
少了一个细节，带来的是你对缺少该细节的一百个补充性描述，和一百个质疑的问题。这个和老说“我以为”是一个道理，我以为你了解，我以为之前你理解了，我以为这个很简单不用说...
- 用用户视角代替个人视角
任何一个需求，为它找到对应的用户角色和价值方，沟通中不要说“我认为”和“有可能”。
- 用求证代替争论
需求对应的解决方案本身也是一个不确定的内容，它需要被验证，遇到争执不下的问题产品经理要有承担责任的勇气，用求证的思路来停止抬杠的局面。
三. 对于高效的理解
无论是增长黑客、敏捷开发，还是精益创业，都依赖于高效的执行。从常规的产品或者项目来看，因为成员的目的只是为了交付一个产品或者项目，所以他很难跳脱出来从全局和长期的视角看待效率问题。对于一个团队，如果日复以往做的都是类似的事，那么效率提升是团队最重要的建设内容之一。
同样的，一个小建议：
- 像产品一样设计效率提升工具
和用户画像、体验地图、服务蓝图一样，深入分析产品工作的相关需求后，总结出行之有效的效率提升方案，然后求证式的快速迭代它（们）。
几种我们已经识别的效率工具
- 产品设计系统 + 语言 + 组件：解决一致性及沟通效率问题
- 数据运营工具：解决产品决策效率问题
- 产品看板：解决需求管理和项目管理的效率问题
- 知识库：解决产品知识更新及共享的效率问题
- 产品帮助体系：解决产品对外的问题收集、解决及迭代的效率问题
- 产品指标跟踪工具：解决产品人员量化考核的效率问题
- 产品体验决策工具：解决产品体验方案决策的效率问题
四. 我们的一些计划
- 新手从效率工具着手干起（对内），通过一个或若干工具的项目补齐自己的短板
- 老手负责产品管理（对外），把重心放在产品的定义侧，同时提升综合的管理能力
- 全部采用产品制来管理，用产品指标考核成员
网友评论