运营如何与产品协作
虽然我在这本手册一直强调产品运营不分家，但这并不妨碍运营和产品岗位 “相爱相杀”，这是互联网企业的传统文化。作为产品经理，日常工作中经常听到运营的各种灵魂拷问：
- 大哥，啥时候能上线？给个具体的时间呗。苦苦哀求.jpg
- 你看 XX 家的那个产品，我们直接抄一份吧，什么？这么简单也做不了？！//震怒脸
- 做的什么玩意，把我的需求干哪来了，我想要的不是这样呜呜... ╯︿╰ 大哭
相反，运营也经常听到产品经理的 “逆天” 言论：
- 做这件事能带来什么好处，效益是什么。（运营 OS：做就做呗，哪来那么多废话）
- 排期估计要到年底，你的需求不重要，慢慢等吧。（运营 OS：不是哥们，什么叫不重要？？）
*以上均为演绎，非互联网企业现实 [狗头]
产品经理和产品运营是密不可分的两个角色，但在多数情况下，产品和运营的交往并不密切，因为通常还有业务方介入。这导致两者并不能用彼此的思维去思考问题，导致重复、无效沟通情况的经常发生。
那对于产品运营来说，是否有好的方法去和产品沟通，赋能业务发展呢？
Let‘s 学习 ~
运营应该如何提出需求
除了自身职能，运营和产品关联的场景包括需求、建议和推广：
- 运营需要根据市场需求向产品经理提出功能建议。在部分领域，这一职能通常被业务方所取代，业务聚焦于客户运营，而运营集中于活动、推广；
- 功能上线后，运营会根据用户的使用数据和反馈提出优化建议；
- 运营需要密切关注功能上线后的用户引导和推广策略，策划活动，这些都需要经过产研团队实现。
想清楚
在向产品经理提出一个需求前，先试着从以下几个角度思考一下，初步判断一下进行产品优化的必要性：
| 状态 | 说明 |
|---|---|
| 需求为谁而提？ | 需求是谁提的，对象需要这个需求的原因是什么？是否具备代表性？进而确定对象的规模和可能影响的范围。 |
| 需求对象的路径是什么？ | 描述清楚需求发生的场景，场景之问是在什么条件下触发的，触发之后希望给触发场景的对象反馈什么？ |
| 产品 / 功能需解决什么问题？ | 比方说用户体验、用户获取、商业增长、成本降低、内部消耗等等。 |
| 现在的状态是什么？ | 描述清楚这个需求现在的状态是什么？已有还是没有，已有 状态下那些是需求已经满足，那些没有满足，没有状态下是否有你认为是否有其他参考为什么？ |
| 期望什么时间上线？ | 需描述清楚希望上线的时间，什么原因导致需要在这个时间段上线，是否已经准备好这个时间上线的相关物料或运营策略。 |
| 需求的目标/价值是？ | 首先描述清楚需求的目标是什么？产品到需求模块的业务边界是什么？ 如何描述清楚对我们能产生什么价值，对用户能产生什么价值？ |
| ... | ... |
还记得我们在 什么是产品思维中提到的观点吗？产品需求并非越做多越好，在产品和开发资源有限的前提下，在需求层面就需要考虑好大部分细节。
对于运营来说，这些思考看起来非常多，甚至有些思考好像不是自己应该考虑的？回到我早期做运营的时候，我可能只顾把需求甩给产品，至于为什么做？价值和目的，懒得想。但在做产品之后，做需求需要有更多正当性理由，需要从岗位角度，去思考必要性，该不该做？
于是，产品经理会有充分的理由把锅甩回去。如果运营并没有明确这些细节，那么产品经理就需要反问运营 What、Why、How、When，倒逼运营去完善这些内容。如果一开始没有明确，在需求阶段之前就会产生大量沟通成本。
示例1：用户提出增加 BI 看板功能
从运营角度来看，在后台增加一个数据看板功能似乎并非难事，从经验来说，运营大多需要使用神策数据、Growing IO ，让产品和开发照葫芦画瓢，在后台做一个看板似乎不是难事。
但从产研角度来看，客户群体是否有强烈需求，做哪些数据看板，如何规划人力和排期等等问题都是需要考虑的。不能因为 1~2 个客户的一句话就去做一个需求，结果使用人数寥寥，整体的支出成本会非常高。
另外运营还可以思考，能否通过以定期查询、导出的方式提供数据报表，这样开发只需要写一个自动化脚本，运营只需要转发给客户。流程不繁琐，成本也可以接受，一举多得。
示例2：运营提出一个临时紧急需求
这两年，券商和期商的活动非常多，有 616、818 福利节，还有为引流促开户新设的模拟交易、实盘交易大赛，层出不穷。作为产品运营，会经常接收到临时性的需求，老板老总们催的急，上线时间紧张，鸭梨山大。
从运营层面传导给产品的压力同样巨大，产研团队有既定的 Roadmap 和版本进度，频繁插入临时且紧急的需求，影响整体版本进度，同样也不好向上级交差。那么运营在向产品提出需求的时候，就必须写好详细的说明文档，内容要清晰，时间要具体。尽可能减少模糊性用语。产品一看文档，内容清晰，论证有力，在需求层面就比较好过关。
在这一层面，要求运营在提出需求之前要充分思考，想清楚需求为何做，怎么做等细节。如果遇到无法判断的情况，也可以和产品经理进行简短的交流，从产品经理的视角获取反馈。
说明白
在经过想清楚这个阶段后，可以和产品经理面对面进行交流，把需求整个表达清楚，预占产品排期。为了高效沟通，可以和产品经理前先梳理一下 “想清楚” 的总结，提升表达需求的有效性。
说明白这个环节之所以重要，原因在于运营的实现思路和研发的思路并不完全一致。运营的思路可能是 A to B，这件事就解决了。但在研发角度上看，A to B 中间还需要经历 toX、toY、toZ ... 才能真正到达 B。有些需求表面上看起来简单，但背地里复杂程度极高的比比皆是。
这个时候，需要运营思考可能的流程会经历哪些环节，尽可能详细地描述，讲明白自己的思路。在 C 端，运营需要讲明白交互行为可能就满足基础要求了。
示例1：企业会员专区的产品需求
背景
作为一个新增的业务模块，企业会员是今年 InfoQ 为满足企业在中国开发者群体中的品牌曝光需求而推出的一款矩阵化资源包，作为一款标准化的 ToB 售卖产品，需要设计制作网站专区让入驻的企业得到更好的曝光，对应也需要新增后台管理的相关设计，便于对入驻企业在相应资源位的上线进行管理。
实现能力
- 预期企业会员会员专区包含以下模块：官网首页展现、入驻企业列表页展现、企业会员专属企业主页
- 预期企业会员后台管理可实现以下功能：上线企业会员响应资源位、标识企业类型、地区、入驻时间、所在地
优势
对企业会员和入驻企业会员企业的曝光将会降低市场对企业会员的认知难度，在实现对入驻企业管理的同时，有助于该产品的售卖和推广。
预期时间和功能迭代
期望能够在 5 月份完成上线，先实现对入驻企业的管理，让他们拥有自己企业会员专属的个人主页，并希望在 6 月完成相应细节的优化，进一步在网站上曝光此品牌，我们将在网站整体上线企业会员会员专区后，以此作为一个事件进行营销，进一步推广企业会员，获取销售线索。
虽然内容简单，但是清晰地说明了整个需求的来龙去脉，以及后续的迭代动作。产品能够在第一时间理解运营的思路，通过后续讨论， 能够对需求有更清晰的理解。
示例2：临时活动页面的 H5 需求
背景
近期即将召开美联储利率会议引发了大量关注，运营层面需要设计一个 H5 页面以满足用户需求，迎合当下市场热点。这一需求旨在为用户提供实时的利率会议追踪及相关解读内容，同时需要设计后台管理系统，便于实时更新会议动态和分析。
实现能力
- 预期H5页面包含以下模块：会议实时追踪、专家解读区、历史利率数据对比区、用户评论区。
- 预期后台管理功能包括：实时数据更新、专家解读发布、历史数据导入与对比、用户评论审核功能
优势
通过提供美联储利率会议的实时追踪与分析，能够迅速吸引用户关注，提升平台的权威性和用户粘性，同时有助于增强用户对金融类内容的依赖，增加平台的日 活和留存，助力后续的相关产品推广。
预期时间和功能迭代
期望能够在本周完成 H5 页面的紧急上线，先实现基础的实时追踪和专家解读功能，内容由运营部门提供。上线后逐步优化细节，例如增加历史数据对比和用户互动功能。后续将在其他渠道进行推广。
完善说明文档后，运营还可以绘制几张原型草图以供产品参考，了解大致的实现样式。这样也能避免在后续与设计部门对接时反复打回，拖慢开发进度。
*在最开始当运营的时候，我没有用过 Axure、墨刀这类原型工具，就在纸上咔咔画了很多产品原型草图。But，还是建议掌握基础的原型绘制工具，这样会减少非常多和产品、设计沟通的成本。
需求提出后，运营应该做什么？
做到位
产品需求的提出，只是运营去交付目标的一个开始，哪些事情要在产品上线前可以做，产品上线后又要做什么，只有往这个方向上持续思考，不断尝试，产品正式上线后才能最大化的发挥产品价值。
具体的流程可以参考 Scrum，最常见的互联网产品研发流程，这里从运营的视角，去看看需求来到产研阶段的过程：
| 阶段 | 说明 |
|---|---|
| 产品需求确认 | 产品经理在拿到产品需求后，会结合与业务方的沟通，反馈产品原型给到运营，由运营、运营负责人对产品的需求进行确认。 |
| 确定产品排期 | 确认好需求实现后，产品会对整个产品的优先级进行排序，结合研发当前的项目交付情况，进行最终的排期，运营需在这个阶段跟进产品处理需求的进度，拿到相对准确的产品上线时间。 |
| 运营物料准备 | 不同的产品需求，经过排期上线的时间也不同，根据时间的长短，可以匹配产品上线的需要，筹备相关物料，如果上线时间间隔特别长，也会需要调整运营策略，度过这段过渡期。 |
| 产品上线验收 | 产品正式上线前，需要提出需求的运营对整个产品进行验收，看看产品上线的方方面面是不是自己想要的样子，一定在这个阶段多试、多问、少妥协，一旦产品正式上线，想要再优化自己原本希望它有的功能，就又要进行排期了，就十分难受。 |
| 持续关注结果 | 产品正式上线后，需要对当初自己提出的产品需求负责，通过这个产品拿到当初想要拿到的结果。 |
为什么要重视需求
有很多产品经理天生就对运营有滤镜，认为运营不懂产品也不懂技术，嫌麻烦的时候还可以甩一句万金油发言：“做不了，如果做这个要延期” 。技术岗的产品运营一听到这句话，也只能乖乖回去跟领导汇报，流下不争气的眼泪。呜呜...
我认为运营是要比产品和研发更加重视自己的需求的，就像上面提到的需要持续关注结果，做到哪了？遇到什么问题了？能否如期上线？不管做什么事，自己先重视，研部门才不会懈怠，觉得你的需求无关紧要。
结盟，搬救兵
产品、研发如果不合作，有可能是你们的 KPI 不一致，也可能是对方认为你的需求没有价值。这个时候你的需求上级催得很急，你该怎么办？
有几种做法，首先是让双方的 KPI 尽可能达成一致。假设运营的需求是为了蹭当下热点的，那是否可以结合产品的注册、留存指标去做一些新的设计？或者铺设一个广告位或弹窗，以满足业务方的 KPI，尽可能让双方有统一的奋斗目标。
如果没有，还可以搬救兵，让小老板或者大老板去协调双方负责人，建立公式。但基本上紧急的需求，双方负责人心里多少都有点数，很少会出现自下而上的压力传导。除非是真忙到没边了。
想清楚、说明白、做到位。
做一个能 “震慑” 产研团队的优秀运营！