来自新加坡担任 Facebook 驻亚太市场产品营运顾问的分享！
好读有图 Medium: https://medium.com/p/9ae43d5dc955
开发产品后的二三事：什么是产品营运与 Ops PM 在做什么？
所以你实际的工作内容是什么？与一般的产品经理有何不同？
这是一个自从我转作产品营运后时常被追问的问题，我在网络上搜索相关资料时也发现台湾 / 中文圈对于“产品营运”的内容并不如“产品开发”常见，因而我希望透过这篇文章来回答对该领域有兴趣的人，同时希望能引出更多不同领域或经验的讨论与分享。
我目前于 Facebook 新加坡担任驻亚太市场的产品营运顾问，负责的产品是企业广告后台的使用者接口（Advertising & Business Platform User Interface）与流程体验。以下文章的内容主要基于我在 Facebook 工作的三年经验中观察与习得的，部分公司会有不同的职位定义，仅供参考。
产品营运时常由于中国的翻译，而与产品营销（Marketing）混为一谈。把产品推入市场后该如何增加市占率、宣传管道的规划…实际上都较偏向行销的功能，而非产品营运的范畴。实际上若以原文 Product Ops 去进行资料搜集的话，有许多英文资源的网站有相当清楚的定义：
“Product ops builds a foundation for product excellence by reinforcing product strategy with metrics, infrastructure, business processes, best practices, budgeting, and reporting.” ...In short, product ops serves to support the product team and help build better products.
简言之，产品营运的诞生是为了协助开发团队，确保产品在市场中的定位与维护品质稳定度，让产品能依计画获得成功。这样的功能之所以尚未被人所熟知，是因为需要有一定规模的公司才会把开发（上线前）与营运（上线后）区隔开来，让不同专业的人来负责相应的领域。
那么，产品营运团队为什么重要呢？
因为多数的产品经理面对产品策略、功能设计、工程师的资源分配与时程安排等，已经相当分身乏术，而规模较大的公司在产品上线后还有不同的用户实验、顾客服务与销售团队的沟通等任务需要被完成。产品营运 PM 就是帮助产品经理监看产品上线后发生的大小事。营运团队最重要的价值是，这群人不仅仅只是接收与执行单一专案或任务，而基于对产品与团队的了解去提供一个系统性解决方法。
“With a product ops team, the organization will have a resource that continuously works to apply operational discipline to the entire cross-functional team. In other words, product ops helps clear a path to ensure the rest of the team — product managers, developers, project managers, customer support, sales — are able to perform under the best possible circumstances.”
如同产品开发端可以分成更仔细的不同阶段，产品营运常见的负责领域有（不限于）：
1. 产品客服（Product Support）
2. 产品资料分析（Product Insight analysis）
3. 跨部门的沟通协作（Cross-functional programs management）
4. 开发流程优化（Process optimization）
在接下来的段落，我会谈及产品营运在上述面向的影响力，与我们是如何帮助产品开发团队提供一个可规模化（Scalable）的系统性解决方案让使用者更喜爱我们打造的产品。
1. 产品客服（Product Support）
这里所谓的客服，并非指产品营运成员自己坐在前线去回答来自四面八方的客户问题。而是作为产品营运团队的一员，我们会协助设计与监控产品的客服支援流程。举例而言，若用户今天想对 WhatsApp 回报问题或是建议时，回报按钮应该被放在产品的哪里？怎样的使用者流程可以让用户花最少时间来完成问题回报？若用户点击了该按钮，她/他会看到什么样的对话框，我们该如何设计才能拿到最完整的资料来解决用户的问题，以提供优秀的客服体验？
产品客服的设计不仅只是在产品中增加一个“回报”按钮而已。是否要在线下安排 Call Center 接线专员回答问题、线上能否提供即时 Chat Support 或 Email Support、在客服流程中如何能衔接后端团队以确保客服专员能用最有效率的方式去调查或处理问题，这些都是产品营运团队的功课。
常见营运指标：
- 使用者的满意度调查（Customer SATisfactions）
- 回答一个Case所需时间 （Resolution Time per case）
- 回答一个Case的成本等等（Cost Per Case）
2. 产品资料分析（Product Insight Analysis）
另一个对开发团队相当重要的资源就是产品资料分析了。由于营运团队在不同市场负责监测产品在上线后的平台稳定性，所以也比后端的纯开发团队距离实际使用者更近一些。这边所指涉的资料包含客服收到的使用者技术问题、意见回馈、Sales 意见反馈等直接来自于市场或使用者的资料。
产品营运团队的优势是，比起使用者访问更能以较低的成本与资源取得第一手用户对产品的真实回馈。图中红线处为产品营运团队放重心专注的第一阶段用户体验。（笔者制图）
当然开发团队中的资料科学家（Data Scientist）也能从产品当中拉出使用纪录（Logging）进行分析，而用户研究员（User Researcher）也会透过面试与问卷方式取得用户回馈 — — 但产品营运团队取得了第一手用户回报问题与意见的数据，这些资料有助于建构出一个更完整的使用者经验旅程（User Experience Journey）。
我们与开发团队密切合作，每半年也会被邀请去参加产品 Roadmap Planning 大会来确保这些来自使用者的声音都能被产品部门听见。
常见指标：
- 产品易用性（Product Confusion Rate）
- 产品稳定度数据（Stability Metrics / Bug Rate）
3. 跨部门的沟通协作（Cross-functional programs management）
协助产品团队进行跨部门的协作是一个相当广的范畴，会根据营运团队本身的职位切分而又有不同的差异。举例而言，当产品团队开发出新的产品功能欲进行测试时，该如何决定哪些用户可以先看见新功能、我们该如何与客户进行沟通与合作来确保测试成功、甚至到撰写测试企划等，这部分便会被归为新产品的营运（New Product Operation）。
在 Facebook 的营运团队会负责的常见项目是 Bug Management，由于我们在技术回报资料中具能见度，因此通常也是透过我们来协助工程师决定什么问题应优先被处理、与技术团队讨论如何处理（应该以 Workaround 解决还是平台一次改善）、何时处理等等，让产品经理能专注在开发端。
另一个常见的跨部门的协作则是产品与 Integrity （诚信）部门的合作来确保没有用户会滥用产品或平台来进行有害行为。产品经理本身专注在开发新的功能与增强市场能见度，但我们会协助开发团队来与 Integrity 部门审视与确保产品的基础架构是稳健的。营运团队在此面向扮演着专案经理的角色来分担产品经理的部分工作，确保开发流程顺利。
4. 开发流程优化（Process optimization）
如同一般公司营运部门，会针对整体的成本、商业问题甚至是盈利去进行分析与提出解决方案，产品营运团队就是产品团队中的营运部门，透过观察团队与对产品的认识来优化开发流程。
当我们察觉到流程中有过于重复性、形式性而不必要的项目时，营运团队会提出解决方案并且透过引入自动化（Automation）、流程优化（Process Optimization）的方式来改善整体开发成本（包含时间与人力资源）。这部分的专案范例包含：导入机器学习来自动取得用户回馈的关键字趋势、设计内部工具让工程师增加除错（Debug）的效率。
你作为产品营运 PM 的一天会做些什么呢？
阅读完以上介绍，相信读者已经对产品营运常见的几个大领域有初步的了解。实际上，我在 Facebook 的职称并不直接是产品营运 PM，但基于定义不同，在蛮多公司中其实我做的事与 PM 已经有很大部分的重叠，多数欧美网络公司中会称我们这样的人为 Product Operation Manager（Ops PM）。
由于我负责的产品已经有完整的产品客服流程，因而我主要专注的面向是分析用户体验数据与设计内部工具以提供产品团队更多价值。
往往我的通勤与早餐时间会浏览产品团队在各平台发布的资讯、Email 与别人联络我的讯息，由于与美国总部的时差所以我要花上比同事更多时间来追上不同的会议纪录、讨论内容等（通常我起床时的工作通知是至少 150 则，不包含 Email 与讯息）。快速浏览这些资讯可以帮助我更有效率地订出当天的待办清单。坐定位子后会监控数据后台确保目前没有任何产品问题，同时也会开始检查与追工程师的 Bug Ticket 进度，与回答一些销售团队对产品的问题。
下午会有较完整的时间专注在产品企划上，例如分析客服部门的资料来思考什么样的内部工具可以提供给工程师或是第一线客服专员改善效率。举例而言，若透过资料发现多数送到工程师端的客户回报其实只是简单的产品问题，那么我会针对前线客服人员设计一个更易懂好用的调查工具让他们能快速检查产品问题。又或是分析市场上的使用者资料后，提出自己的洞察与新功能企划来向产品经理提案下一季的产品蓝图（Roadmap）。
结语
产品营运是一个相对新的领域，比起产品开发或许较不为人所知，但目前越来越多规模较大的海外公司已开始在这领域有更专精的分类。上述解释了几个常见的产品营运面向，但基于不同规模的公司与定义，或许大家也会有不同的经验与认识，欢迎大家多分享！