理解不同角色的博弈
需求侧一定希望需求越灵活越好，他们随时的变动都能得到及时的响应和调整；
开发侧一定希望需求越固定越好，当期需求范围锁定，任何变动都应当被记入下个周期、启动新的迭代。
所以，开发喜欢用TAPD、JIRA，因为上了系统，灵活度就降低了；
而业务方喜欢用Excel、Word，因为自由度更高，动动手指就能产生变更。
产品经理作为一个桥梁，理解不同角色背后的立场，才能更好地协调利益的冲突。
新产品推广：要让用户自己喊出痛点
我们要怎么做，才能更顺利把新产品推广起来？
答案就是借力。要借助用户本身的力量。要给他们“制造”痛点，让他们痛到一定程度，就会主动喊出来，要解决。
Case1 写作工具
数字化转型过程中，旧写作工具已经无法适用，需要用新工具替代。常规做法是，产品部牵头，接着调研、选型，最后决策、落地。但是实际推行过程会有极大的阻力，因为用户迁移需要成本，过程中很难接受新的工具，肯定会积压一堆抱怨，这对产品部其他的项目、可持续发展都不利。那我们做了什么？
我们做了一个好用的知识库，素材放在新写作工具上，但我们不干涉写作过程中原工具的使用。让他们先把知识库用起来，形成依赖，后面进一步会提出新需求：能不能不要让我切换平台，直接用这个新工具来写作、发给客户？这时候，我们再去调整B、C端的写作工具，就会更加畅通。
这就是一种产品顶层策略设计。做产品并不是常规的调研、评估、出方案、画图、推进开发、收集反馈，这种模式也不是不行，但是会有很多问题，阻力大、抱怨多、没有用户等等。
Case2 知识库
公司一直想要做知识库。但是自上而下的需求，本身项目开展过程会有很多挑战：1是其他员工不清楚，也没有意识到战略重要性，有很大沟通成本，或者有很多活跃的个人想法，过程中会有不小阻力；2是本身公司在用一些第三方知识库工具，积累了一定用户量，迁移存在成本，3是产品落地后缺少天使用户，我们很难派活给别的部门作为内容生产部门，产品用不起来，直接影响产品部的业绩。
于是我们通过观察、沟通，去“找需求”，寻找我们的天使用户。这个用户的特点是必须有很强的痛点，需要我们这个知识库去解决，这样确保我们开发出来后他一定会用起来。基于这样小小的切入点，开发出一个MVP，后面再扩大功能、逐步迭代，把知识库做庞大起来。
经过业务洞察，提炼有两个比较好的切入点：
1、客服部的语音库：据了解，客服部目前在数据报表系统上搭了一个简单的语音案例库demo，部门内已经展开使用，并且留下了很多点评等数据；
2、文案写作的素材库：企业已经积攒了一定量的历史文案素材，那么后面就能基于此搭建系统，把知识库集成在写作工具中。
助力业务提效：不需要一味考虑将人数压下来
当我们的项目目标是为企业降本增效，很多时候我们的思路会局限于如何提升业务效率、从而降低团队人数，把人力成本压缩。
但实际上，项目初显成绩之时，人数未必会下降。
比如，将传统工作流程进行流水线式精细化拆解，原本由A岗位的人完成的任务，进行颗粒度细化，把部分非核心任务转移到B岗位上，然后我们重点提升核心任务的效率。那么，从结果上体现，A岗位的人数是下降了，但是反而会增加B岗位的人数，因为将A的成本转嫁到了B上。
此外，还可能有短期人数稍微增加的情况：比如智能客服上线后，客服的人数被压下来了；但我们还要考虑怎么让用户满意度提升，于是再思考怎么主动引进质检标准，前期还会增加一点质检人力。
别一不小心做了一个“自己都讨厌”的产品
之前遇到过一个情况：整个项目组差点一不小心做了一个“连自己都讨厌”的产品。
背景是，项目组在研发智能客服产品。当时和公司内部一个孵化业务合作，人家正值考核收入业绩的关键时期，所以态度很强势，不断引导我们这边语料团队编写的方向。
当时语料团队就花了很多心思在考虑如何引导客户付费上。后来我们产品介入，及时喊停。
因为，我们需要重新思考业务场景，不要偏离了初心。
我们的定位是一个帮助解答香港身份领域疑问的机器人，而不是销售机器人；我们的目标不是引流和带来收入，而是良好的用户体验和树立专家形象。我们应该更关注用户体验感受和粘性，而非动不动引导付费，否则体验很差。
我们自己组的目标是机器人对用户有用，而不是卖多少钱；用户过来了，我们的机器人能不能解决80%的问题，吸引留存，这才是我们要关注的点。
售前、售后……业务场景不一样，产品规划和策略完全不一样，我们前期就要想清楚；售后相对是更聚焦的，而营销是一个开口，挑战就会很大。
平时接电话，当一听到是机器人，我们基本都会挂掉；销售来推销，我们总觉得反感，更何况是机器人来推销！
我们怎么能做着做着，做成了一个连自己都讨厌的产品？
当时及时组会对齐了，把这个方向给扳过来了。
跨业务合作，要把其他部门当成客户
创新项目的孵化，往往比较被动，最后产品做着做着，就容易变成了配合业务……
比如智能客服里的“转人工”，就是一个业务问题。人工客服部门合作起来，就会开始提他们立场的需求，和原本智能客服的方向偏差个十万八千里……
正确的做法应该是，把业务想象成客户，我们立足于产品价值本身，带着解决方案过来，带着我们的专业性，背后要保障自己的话语权。
而且，有一点也很重要：我们尽可能在公司内找到积极的、强需求的“客户”，打出标杆“客户”案例，再吸引其他部门主动靠近我们合作。
产品设计一定要回归业务
以知识库为例。在给某家商务资讯企业做数字化转型的过程中，需要搭建一个知识库。
项目过程中，团队会逐渐往知识库不断庞大、提升厚度的方向去靠近。
但实际上，是不是建立一个越庞大的知识资产库越好呢？
比如，当知识库里企业的数量超过了一定规模，变得过于庞大，就会产生新的问题：1、企业之间存在关联关系网络；2、同个集团下的主体名称很多……然后团队又开始花很多心思去想，怎么整合这些关联关系……
但，及时刹车想想！谁来做这个繁琐的整理？而且，我们设计出来的系统，到底是给谁用？真的会被用到吗？这样的设计真的合理吗？
一切设计最终的目的，还是为核心业务去服务。不要脱离现实业务去畅想完美、追求卓越，否则都是浪费时间和人力。
