四个做产品的系统 - 问题篇 (新功能与增长)
这个是我们 APMP 中的一篇阅读材料. 接下来会有一系列的阅读材料 + case study + 产品实操. 我们 APMP 的目的是识别能够超越我们期待的产品人, 赋予最好的知识和体系, 给予最大的空间和信任, 为用户和公司产生最大的价值.
目前计划的 APMP 包括以下:
四个产品体系
- 四个做产品的系统 - 问题篇
新功能
增长 - 四个做产品的系统 - 问题篇
规模化
PMF / PCF 扩张 - 四个做产品的系统 - 应用篇
新功能
增长 - 四个做产品的系统 - 应用篇
规模化
PMF / PCF 扩张
Growth (增长)
- Acquisition (新增)
- Retention + Engagement (留存 + 促活)
- Monetization (商业化)
- Growth Models (增长模型)
Growth Constraints (增长瓶颈)
Growth Loops (增长闭环)
Retention + Engagement (留存+促活)
- Retention (留存)
定义留存
分析留存 - Activation (激活)
定义激活
评估激活
分析激活
激活策略 - Engagement (促活)
定义促活
评估促活
分析促活
促活策略 - Churn Prediction + Reactivation (流失预测 + 再促活)
Experimentation + Optimization (实验和优化)
- 实验策略
- 假设建立
- 实验的量化和科学方法
- 分析实验结果
- 结果在产品的应用
- 管理实验系统
Monetization + Pricing (商业化和定价)
- 商业化策略
定义商业化策略
评估商业化策略 - 商业化模型
分析商业化模型
识别商业化模型
商业化模型优化 - 优化策略
分析优化点
识别优化点
制定优化策略 - 落地商业化与定价变化
User Insights (用户研究)
- 设计决策模型 (design decision model)
- 用户访谈 (user interview)
- 设计研究 (design research)
- 分析和设计决策 (synthesis and decision making)
Marketing Strategy (市场策略)
- 已有市场策略评估
- 渠道评估 (channel evaluation)
- 渠道投入 (channel investment)
- 渠道规模化 (scaling channels)
下面是正文
单一系统造成的问题
在我们做拼室友的过去三年里, 我们从2018年的 initial product-market fit 至今, 碰到过以下的一些问题:
- 产品经理偏好做有趣的产品而不是重要的产品
- 很多V0, 小范围, 体验不完整的产品
- 专注 shipping 而不是业务的成功
- 因为产品维度太广导致团队不专注与成长缓慢
- 所有功能和产品的都用单一的指标去衡量 (MAU)
- 因为技术债的原因导致进度缓慢或者团队在持续救火 (我们 senior engineers 需要担任 IC 的角色)
- 团队在技术选型时专注 cool 而不是相关度
在这个过程中, 在2021年初一位字节早期的同事来到我们团队后, 大力推进了产研体系的调整, 虽然目的是好的, 但是我们发现不是简单的体系调整和盲目减少复杂度就能解决我们产品和业务这边遇到的问题. 我们意识到真正的问题存在于我们产品体系的缺失, 因为在一个非增量型的市场里面, 一个好的产品体系是业务成功的基础. 不同的产品有不同的体系, 衡量标准和战略.
我们把产品归为四类, 我们从之前的没有体系, 到后来的统一体系, 结果还是问题频频. 为什么呢?
因为我们在用单一的体系思考不同类型的产品.
前 Slack 产品总监 Fareed Mosavat说道,
"One of the most common conflicts I've seen is when product leaders try to apply a single development process, measure of success, and strategy to all product work. For instance, while some of the steps can be similar, growth and feature work are fundamentally different and a lot of energy is wasted trying to make them all fit into the same process, success metric, and approach."
"一个常见的冲突就是产品负责人会尝试使用单一的开发体系, 评估体系, 和战略体系在所有的产品上. 虽然有些步骤类似, 但是有些类型的产品是截然不同的, 比如说增长和功能产品. 如果使用单一的体系, 团队会浪费很多时间和精力去硬把各种产品归一到统一的产品体系下."
错误的体系, 错误的指标, 错误的战略
对不同的产品理解不深刻, 导致我们使用错误的体系, 错误的指标和错误的战略去思考和投入资源. 下面我们来具体看一下我们犯过的错误.
错误的体系
大多数产品经理对于这四类产品和自己负责的产品类型属于哪一类没有一个清晰的认知, 导致他们使用次优或者错误的方法 (原因是因为一成不变地看问题)思考和管理产品, 无法战略的思考自己负责的产品和如何使用不同的产品体系去解决响应的产品问题.
有比较多工作经验的 PM 趋向于相信"以前管用的, 现在也肯定能管用"这个思维. 这个是不正确的, 当组织在成长, PM 也需要跟着一起成长, 管理的产品数量, 限制条件, 变量和复杂度都会随之变大.
错误的指标
不同的产品需要不同的方法和指标去评估和判断. 不清楚理解和评判不同的问题会导致团队以错误的指标去评估业务或者产品的成功 - 比如说用 MAU 来评估任何做的产品功能.
回头看看, 这些用来评估成功的指标会让团队有意无意驱动团队优先级的设定和执行的方式. 一个常见的现象就是团队偏好开发"有趣"的功能而不是重要的功能, 因为对于评估成功的指标, 或者说驱动力, 没有很好的对齐.
久而久之, 产品经理的思维模式会变成说我的事业要进步, 我需要:
- 做新的功能或者产品
- 只专注在能产生短期现金流的产品上
- 只专注在长期有战略影响力的产品上
前 Tinder 首席产品官, 前 Facebook 产品经理 Ravi Mehta 说道,
"Companies tend to reinforce the problem of focusing on feature work at the expense of other important product work. It's exciting to talk about new features, and they shine the limelight on the PMs doing that work. Instead, companies need to recognize the value of the different types of PM work, help PMs map their skills to those roles, and reward PMs for all the work that is critical, not just the outwardly sexy work."
"公司往往会专注功能产品导致问题的放大, 因为很多其他重要的产品会被放弃. 谈论新产品确实会让产品经理兴奋, 因为这是产品经理会被放在聚光灯下. 相反的, 公司需要意识到不同产品类型的不同价值, 帮助产品经理去理解和获取做好不同种类产品所需要的技能和知识, 并且鼓励和奖励那些专注做重要产品的产品经理, 而不是那些专注做"有趣"产品的产品经理.
错误的战略
错误的体系和指标最终导致错误的战略, 让我们专注在错误的产品或者产品组合上. 比如说:
- 应该专注功能产品, 但却专注增长产品. 在产品没有成熟时就开始优化增长.
- 应该专注增长产品, 但却专注功能产品. 应该专注在让更多用户可以体验到我们产品, 但是却过度的迭代和添加功能, 导致产品 scope 过大.
前 Eventbrite 首席产品官, Pinterest 产品经理 Casey Winters 说道,
“My first year at Pinterest we built a Maps product and a Q&A product, neither of which had any material impact to the business and were later deleted. In year two, we changed the "Pin It" button to say "Save" and got a 15% increase in activation rate just from that.”
"我在 Pinterest的第一年, 我们开发了一个地图产品和一个 Q&A 产品, 但是没有一个对于公司的业务有任何实质性的帮助并且在后续的发布里删除了. 在第二年, 我们把 "Pin It" 按钮改成 "Save", 带来了15%的激活率提高." - 应该专注 PMF 扩张产品, 但却专注增长产品. 当目前的 PMF 已经饱和的时候, 快速的增长是不会发生的, 这个时候应该考虑扩张自己的 PMF 或者 PCF.
- 应该专注在规模化产品, 但却专注功能或者增长产品. 错误的基建或者技术方案导致缓慢甚至无法交付产品.
前 Eventbrite 首席产品官, Pinterest 产品经理 Casey Winters 说道,
"A pattern I often see: Features consistently get prioritized over bug fixes resulting in "bug batches" that eventually and begrudgingly need to get addressed. This happens by prioritizing feature work over quality work. Products get slower, buggier, and less dependable for the people who are actually using the product day-to-day, while the feature teams focus on building for new needs that may not exist."
"一个我经常见到的现象: 功能的优先级持续大于 bug fix 的优先级. 最后导致不得不做 feature freeze 去集中的修 bug. 这种模式导致产品的持续变慢, bug 频发, 对于每天高频使用的用户可靠性下降等, 与此同时那些新功能又感觉在解决一些不存在的问题." - 杂乱无章. 产品开发没有明确的方向和体系. 需要一边开发一边考虑需求.
前 Eventbrite 首席产品官, Pinterest 产品经理 Casey Winters 说道,
“When I started working with Eventbrite on our consumer product, we were building personalized recommendations for millions of consumers who had previously bought tickets. But we hadn't build any of the signals other companies typically use to power those recommendations, like favorites, ratings and reviews, etc.”
"当我刚刚开始在 Eventbrite 从事产品经理工作的时候, 我们在为数百万之前买过票的用户开发个性化推荐系统. 但是我们没有开发任何能够帮助推荐系统的信号类产品, 比如说收藏, 打分和评价等."
作为一个资深的产品经理, 在一个种类的产品深耕, 到横向管理多个种类的产品, 可以让你:
- 有更宽广的产品问题视野
- 在各个种类的产品间最大化 ROI
- 做一个 T 型人才
换句话说, 资深产品经理的工作就是做好(不是做)那些有可能你从来没做过的工作.
前 Instagram 增长负责人 Bangaly Kaba 说道,
"The best feedback I received as a manager was someone asked how I could walk in a room with 30% of the context and identify whats wrong and help course correct. But this is the essence of the Product Lead role. Your job is to understand what is going on, what the outcomes should be, and quickly figure out how you can help course correct."
"我收到过最好的反馈是一个问题, "我该如何只用 30% 的上下文解决所有碰到的问题并且确保方向正确." 其实这个就是一个产品负责人的该做的事情. 作为一个产品负责人, 你的工作就是清楚正在发生什么, 结果应该是什么, 然后快速的弄清楚你如何帮助团队确保执行方向正确."
但是这个不表示你的目标应该是在所有领域做到专家, 相反的, 你的目标应该是掌握相应的工具, 思维模式和提供给团队正确的意见. 虽然这三样是极度困难的组合, 但是通过仔细观察和学习, 从一个好的上级经理那里是能够获取那些技能的.
下面我们说下四类产品
- 功能产品 - 通过延展产品的功能和使用市场或群体来创造和转化产品价值 (逐步扩展PMF与下面的4类似, 但是小步快跑)
- 增长产品 - 通过加快当前市场或用户群体对产品的接受度来创造和转化产品价值
- 规模化产品 - 通过解决瓶颈让团队可以更高效的交付功能, 增长和 PMF 扩展产品
- PMF / PCF 扩展产品 - 通过扩展至其他相关的市场和相关的产品来跳跃式扩展PMF
Feature Work / 功能产品
大部分的产品经理脑中的产品其实是功能产品. 当产品达到 initial product-market fit 时, 功能产品通过延展产品的功能和使用市场或群体来创造和转化产品价值. 以下是一些我们碰到的常见核心问题
每个功能都会投射个影子
功能的交付并不是责任的边际. 一旦某个功能交付后, 后续的附带成本是必然发生的. 这些成本就是"功能影子 (feature shadow)". 以下是几类不同的功能影子:
- 维护成本 - 没有零成本的维护. 我们的经验是, 无论使用量多小, 交付的功能肯定需要持续的维护, 迭代和提供支持.
- 用户成本 - 每一个多的功能都给用户带来认知上的负责度提高. 用户的认知阻力会给不同生命周期的用户带来不同的冲击, 导致功能发现困难, 新用户上手困难等问题.
前 Eventbrite 首席产品官, Pinterest 产品经理 Casey Winters 说道,
At Pinterest, we were getting a lot of feedback that new users had a hard time understanding the product. One thing users were confused about was should they be Pinning or Liking? So, we tested removing Likes from the product, and it didn't impact retention at all. So we sunset that feature."
"在 Pinterest, 我们收到很多用户的反馈反应上手困难. 用户搞不清楚 Pin 和 Like 的区别. 所以我们试验了移除 Like 这个功能, 然后发现对于留存没有任何影响. 所以后续我们下线了该功能." - 下线成本 - 功能不是开关. 下线某个功能会有附带的用户体验影响, 时间和资源的投入. 这个也是很多公司没有下线很多应该下线的功能的原因.
前 Slack 产品总监 Fareed Mosavat说道,
"At one point we tried killing the "/me" feature in Slack. It ended up creating a ton of backlash among users and we ended up undoing the decision. One thing I learned is that there are no dark corners of your product that are easy to kill."
"在某一个时间点我们尝试下线 Slack 里的 "/me" 功能. 结果导致大量的用户抱怨, 然后我们只能把那个功能恢复. 在这件事上我学到了一旦功能上线后, 当你用户量很大的时候, 下线功能不是件容易的事情."
前 Tinder 首席产品官, 前 Facebook 产品经理 Ravi Mehta 说道,
"The people using features on the periphery of a product are often the power users—they have the cognitive capacity and the genuine need to early adopt new features. This makes killing underused features even more complicated and costly. Feature churn impacts your power users disproportionately."
"那些使用小众功能的往往是产品的重度用户, 他们有相应的认知能力和那些小众功能的需求. 这个让我们下线那些功能的工作变得尤其困难和高成本. 功能的下线对你重度用户的负面影响是不成比例严重的."
功能影子往往是被严重低估的. 有机会的话你可以研究一下各种 product roadmap, 你会看到各种功能得不到相应的工程资源和时间去迭代优化. 那些后续需要的优化和迭代会被省略因为团队的优先级已经专注在新的功能上. 你需要仔细思考产品影子这个问题, 并且预留足够的资源去解决这个问题.
当功能影子被忽略时, 问题就会接踵而来
当 product roadmap 不包括后续的迭代和优化时, 你会遇到各种各样的问题.
- 注意力分散和精力拉扯 - 团队会在新功能和迭代之间游走. 持续的上下文切换和失焦.
- 产品复杂度 - 功能影子导致产品复杂度增加, 导致工程难度上升. 如果长时间不理会, 会导致严重的业务风险.
- 用户阻力 - 新用户上手产品会越来越困难.
但你开发新功能时, 一个完整的画面是什么?
当 Apple 发布 Touch ID 时, 很多用户觉得很奇怪. 但回头看看, 从钱包到 Touch ID, 再到具有 NFC 功能, 完整的画面就显现出来了 - Apple Pay. 如果做的正确的话, 你的一系列的功能发布应该是一个很合拍的序列, 合成一个大画面, 做到 1 + 1 > 2. 如果不能回答的话, 可能你需要问你自己这个问题, "真的需要开发这个功能吗?"
序列发布对于新的用户使用场景并且需要比较大的交互习惯改变的功能尤其重要. 你不能期待用户可以立即做到很大的行为习惯改变. 人类的本能不是这样的. 你需要带他们经历一个旅途.
前 Tinder 首席产品官, 前 Facebook 产品经理 Ravi Mehta 说道,
"When people say a product was ‘ahead of its time,’ what they really mean is that the product didn't do enough to lead people through the behavioral change necessary to get value from the product."
"当人们说这个产品是"超越当前时代的", 其实真正的意思是产品没有下足够的功夫引导用户经历整个行为习惯改变旅途."
Growth Work / 增长产品
在开发功能之前, 应该问这样一个问题: "用户将如何发现并将该功能用成习惯?" 要回答这个问题, 我们就必须看一下增长产品. 记得我们上文提到的, 增长产品通过占领更多现有市场来创造和转化价值. 与新功能不同的是, 负责增长产品的团队通过产品中已经有的价值与用户连接，而不是通过创造新的价值.
自 Facebook 增长团队成立以来, 被称为“增长”的工作一直像过山车一样变化起伏. 期待导致了很多外界的误解.
增长是产品的工作
一个长期被误解的概念是"我们只负责产品, 增长我们能帮一下忙, 但是主要的工作需要运营和市场去完成."
是这样吗?
我们来看看, 增长 (growth) 有三个主要部分组成: 留存 (retention), 新增 (acquisition) 和商业化 (monetization). 这三者需要珠联璧合, 而不是各自为政. 产品需要去承载和影响这三块. 对于不同的产品, 产品都需要担任增长这个角色, 从社交产品到 SaaS 类产品. 唯一不同的是产品在什么情况下, 在什时候去驱动增长. 认为产品不负责增长的误解大部分都来自团队不清楚产品到底是怎么影响和驱动增长的.
增长不是开发更多的功能
另外一个长期被误解的概念是"如果我们需要增长, 那解决方案是开发xx功能." 有些时候新功能确实是答案, 但是大部分时候不是的.根本原因在于团队清楚如何开发新功能, 但是不清楚驱动产品增长的因素. 清楚产品内的功能在增长闭环 (growth loops)担当什么角色能够帮助产品经理更好的计划和作出功能决策.
增长不是歇斯底里的优化
当增长团队开始在科技公司中占据一席之地时. 对"更多增长=更多功能"的误解很快变成了: "要增长, 我们只需要优化." 这导致团队走上了局部最优解、dark pattern (误导用户优化转化率)、仅使用量化数据做决策, 以及糟糕的实验系统的道路.
增长始于对于产品自有的增长模式的清楚理解
很多人会说, 增长和所有人都有关. 这句话是不理解什么直接影响增长, 什么间接影响增长会说出的话.
在产品在解决增长问题时, 你需要系统的理解新增, 留存和商业化是怎么珠联璧合运作的. 那怎么系统的理解呢? 先回答这个问题: "我们的产品是如何增长的?" 要回答这个问题, 我们需要清楚的理解我们产品的增长模型.
一旦团队理解了这一点, 我们就可以开始定位系统中最严重的 constraint 是什么、是什么类型的 constraint、使用什么方法来解决这个 constraint, 然后通过实验来了解该方法是否真的能促进增长指标.
下篇聚焦剩下两类 (规模化产品和 PMF / PCF 扩张产品) 产品, 说说我们创业过程中遇到的问题.