CategoryResourceRepost/极客时间专栏/邱岳的产品实战/模块二:升级你的产品能力:产品经理的数据能力与商业意识/27 | 从具体业务出发,如何利用数据辅助你的决策?.md
louzefeng d3828a7aee mod
2024-07-11 05:50:32 +00:00

104 lines
11 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<audio id="audio" title="27 | 从具体业务出发,如何利用数据辅助你的决策?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/22/ee/226b7922814c3858775b7f48bd1ae7ee.mp3"></audio>
极客时间的专栏读者你好,我是邱岳。我们继续来分享与产品经理数据能力相关的内容。
我们在前面的文章中假设了一个场景,想要通过构建自己的流量池,摆脱对搜索引擎流量的绝对依赖,在我们决策究竟是做工具还是做社区的时候,需要数据来做辅助的判断。
在上一次的分享前,我们提到在开始决策前,需要先收集横向和纵向的数据来设定目标数字。
这次我们接着上次的话题,进入到具体业务细节,来看数据如何辅助我们做出决策,以及如何追踪决策成果。
为了防止空对空,我们干脆把故事编得再具体一点,我们假设“极客时间”需要构建流量池,那么应当投入做开发者社区还是开发者工具呢?
我在这里首先要做个免责声明,一方面我并不知道极客时间的具体运营数字,另外一方面,产品方向性决策与团队能力结构,以及经验有很大关系,所以仅作为故事背景使用。好了,声明结束,我们可以继续了。
在上一季专栏中,我们曾经分享过需求价值分析的框架,就是依次去问三个问题,用户是谁,用户有什么问题,我们提供什么解决方案。在这个情境中,我们的数据分析依然会围绕这三个部分来展开。
## 1. 通过数据了解用户是谁
我们曾经提到过希望构建的流量池可以给带来“精准用户”,这对应在我们设计的情境中,指的就是希望新做的产品特性带来的用户,与极客时间当前的用户相近。
所以我们的第一个问题,就是要想办法了解群体用户的画像,将“用户是谁”这个问题数据化。我们之前从“用户画像”的角度,介绍过这个问题的解决方案,这次我们就从数据的角度看一看。
有两类数据用来描述用户,一种是可以直接获得的属性数据,另一种是需要分析的行为数据。
前一种数据可以直接来自用户提交的表单(比如性别年龄等等基本属性),也可以来自于调研,或者一些第三方数据机构提供的用户画像,总之,这样的数据内容通常只需要做汇总统计,就可以得到结论。
后一种数据需要根据用户的行为数据进行分析和推测,比如我们可以观察用户访问产品的时间段,以及订阅专栏的种类,将专栏内容的标签传递给用户。
比如用户订阅了 Python 和 AI 相关的专栏,我们可以推测他可能对机器学习算法感兴趣,比如用户订阅了多个相对简单通用的专栏,那他可能还处于初学阶段,如果他订阅了一些专业性更强的专栏,那或许他已经有一定的开发经验,等等。
这个过程跟我们在前面“流量骤降”的情境中,提到的“用行为数据做用户分类”很像,目的是在决策过程中,更好地去判断决策到底靠不靠谱。
比如,我们现在要确定社区的信息架构,有一种方法是按照语言来组织社区,那我们可以去分析不同语言用户的交叉程度。如果这时,我们发现大部分用户都是跨语言的,那或许这样的组织形式就可能给他们带来不便。
## 2. 通过数据了解用户的需求
知道用户是谁之后,再反向去考虑他们未被满足的需求是什么,从而在其中寻找机会构建我们的流量池。
理解需求的过程中,跟数据相关的也是两类,一类是通过调研、访谈和客服等各种渠道收集的用户反馈,另一种还是通过用户行为去分析和推测。
前一种不展开说了,后一种比较有趣,就是如何通过各种蛛丝马迹去推测用户需要什么。我在这里给大家介绍几个有意思的方法。
**第一个是去看搜索记录。** 大部分产品都会有搜索框,即便没有,也可以去看通过搜索引擎进来的流量上面标记的搜索词。搜索是表达用户动机的一扇非常直接的窗户。它除了可以帮助我们在构建流量池的时候探索用户需求,也可以帮助我们发现更多的机会。
我之前听说有个公司从自己产品的搜索记录里发现,有大量的工作岗位和商品的搜索,于是就做了招聘和电商产品,结果大获成功。
我之前负责某条电商产品的时候也曾经通过搜索引擎流量标记的搜索词发现有很多人在搜“xxx 多少钱”这样的东西,于是便规划了一系列跟价格相关的的工具和运营活动,成果也不错。
**第二个是从产品假设出发,去寻找逻辑上的“反对意见”。** 比如我们想建社区,需要让用户产生内容,那我们的用户是否有足够的表达欲望和行动力呢?想要回答这个问题,我们可以去找行为数据。
**这里有一个小诀窍是去找“反对意见”。** 因为一旦我们建立假设,提出问题,便有了立场和期望,在这种情况下,当我们收集数据时,就很容易倾向于收集那些能够支持我们决定的信息,从而忽略那些与我们想法相矛盾的证据。
所以当我们形成假设之后,要格式化我们的出发点,尽可能去找能够反驳假设的数据。比如刚才我提到的表达欲望,我们可能会去找用户分享、点赞或评论的频率和比例,甚至去看内容的长度和情绪倾向,并试图证明,用户并没有旺盛的分享欲望。
带着这样的出发点如果依然无法驳斥“用户具有旺盛表达欲”这样的推测时,那我们便可以认为,这一推测成立。
顺便多说一句,这种左右互搏除了发生在自己脑子里之外,也可以发生在同事之间。不要追求那种一团和气的需求讨论会,不断地挑战和质疑才是锤炼需求的最好途径。
**第三个方法是去看抽样用户的具体行为轨迹,建立猜想,再倒推回去看整体数据。** 这个过程操作起来很有趣味性,方法就是花上一天,不断去抽单个用户的行为轨迹去观察,看看他到了哪里、点了什么、停了多久、又跳去了哪里,等等。
然后像一个戏精附体一样,去把自己塞进用户的脑子里,想象他每一步的处境和心理活动——他为什么打开文章页,快速地滑了一下就退出了?他为什么在搜索结果页停留了这么久?他为什么排着给所有的评论都点了赞?
在这个过程中,可能会发现一些奇怪的行为模式,这时可以返回去整体找一下类似的行为模式是否普遍,如果类似的行为模式只是个别现象可以不用管,但如果有很多,就需要我们去进一步思考和探索原因。
## 3. 我们能提供什么解决方案
当我们从数据了解用户的需求之后,就可以开始考虑我们提供何种解决方案了。
在设计的情境中,我们可以选择做开发工具,也可以选择做社区。**这时跟数据相关的有两个问题,一是竞争现状,二是触达效率。**
竞争现状很好理解,比如我们推算用户需求,发现对于工程师来说,需要线上文档协作工具,我们不能直接开工,而应当先去研究一下是不是已经有类似的工具存在,最好能看看市场和用户数据,判断一下是否已经形成垄断了。
如果拿不到宏观数据,我们也可以在自己用户范围里做一些调研和访谈。很多人在做东西之前不研究市场,这其实是个不太好的习惯。
至于触达效率,因为我们想要做的是能够成为流量发动机的产品,所以我们希望它自己可以拥有触达能力,换句话说就是希望它可以自己能独立获取流量。那我们就需要在逻辑和数据上大概推断它自身的流量能力,通常包括自己的获客和留存。
如果大家还记得的话,这时我们需要用到的技能,就是在本季专栏开头讲到的:怎样快速验证产品创意部分的内容了。我们可以用 MVP 做一些测试,快速验证我们的假设,判断方向性的选择是否值得继续重兵投入。
## 4. 做出决定,开工干活
我们从测试中得到支撑之后就可以开始投资源做事情了。
回到我们设计的场景,我们假设从用户的注册和行为数据中,判断极客时间的用户群体主要为工作 1-3 年的一线开发工程师,他们能够稳定投入时间进行学习,而且发现他们在学习的过程中有大量的分享、评论和点赞行为,所以,我们认为他们能够产出内容,并且有分享和交流的动机。
于是我们研究了市面上现有的开发者社区,发现现有产品没有形成垄断,也不能完全满足用户需求,在做了一些小范围测试之后,我们决定在极客时间的内容产品之外,再建立一个社区。
我们希望可以从极客时间当前产品中导入启动用户和内容,并希望社区逐渐具备自行获客和留存的能力,最终反哺当前的商业产品。
根据上一次分享的内容,我们可以给它设置几个目标,比如我们希望它的留存率和新用户数能够超过当前产品。
在此之后,我们就可以定义产品开工干活了,在定义产品的过程中,我们可能依然需要不断回来反查数据,支撑我们具体的特性选择,其实一旦我们形成了良好的数据思维,应当看什么数据,以及怎样通过数据支撑决策,就会变成自然而然的习惯,决策可靠性和成功率便会逐渐提高。
## 5. 总结
今天我们分享了“用数据辅助你的产品决策”的相关内容,我假设了一个案例,以“极客时间需要做流量池”出发,通过具体的业务细节,来看数据如何辅助我们做出决策。首先,我们通过数据来了解“极客时间”的用户是谁,这里有两类数据用来描述用户,一种是可以直接获得的属性数据,另一种是需要分析的行为数据。
接下来我们通过数据去了解用户的需求,这里我介绍了三个有意思的方法,大家可以尝试一下。得到了需求之后,我们来看看自己能够提供什么样解决方案,具体是做工具还是做社区。
在我们定义产品的过程中,我们可能依然需要不断回来反查数据,支撑我们具体的特性选择。
在我们今天的虚拟案例中,你关注了哪些细节,又有哪些思考呢,你可以给我留言,我们一起讨论,感谢你的收听,我们下期再见。