产品生命周期和技术创新(产品内核与快速验证)

发布日期:2024-12-22 09:47:35     作者:凌晨的眼泪     手机:https://m.xinb2b.cn/sport/doy127886.html     违规举报

编辑导语:产品固然需要不断地迭代优化,以求给用户更好的产品使用体验,然而在这过程中,产品需要找准自身内核,找到自身最为核心的价值,以免偏离方向,也可以降低后续试错成本。本篇文章里,作者便结合自身经验,对产品内核和同频验证二者做了解读,一起来看一下。


回顾今年做需求,会将重心放在目的 验证上。对于目的,更“刻意”让自己去挖掘产品内核,后续关于需求的一系列展开,都尽量让自己回归到内核本身;对于验证,更“刻意”让自己去遵循性价比最高的验证方式。这两项的刻意练习,能够让自己对挖掘产品思维的底层逻辑和检验更加熟练。

一、为什么要找到产品内核

先说一个自己切身体会的场景啊,前不久业务希望产品出一个APP,用来做教育行业的前端获客。后来业务又觉得,家长买完课之后肯定要给小孩上课,那就在这个APP上会更方便,所以又想用APP来上课。因此,在业务眼里,需要做一个APP,既想满足获客营销,又想满足小孩子上课的需求,那问题来了:他们所需要的产品,真的是一类么?

简单推演了一下:

前端获客的目标用户是家长,家长需要看到什么、了解什么才能被我们吸引?上课的目标用户是小孩,小孩需要什么?肯定是方便的操作、卡通活泼的内容、彩色的界面……

所以这个项目最后做得四不像,复盘后才发现最基本的问题在于没有找准产品内核。

为什么要找到产品内核,思考出来有2点:

让产品的「地基」牢固。就像一个房子一样,产品内核如同地基和框架,如果连这个都不牢固,谈何装修?让产品在试错阶段,不至于全军覆没、推倒重来。在打磨产品的初期,可能会尝试很多MVP*方案去快速验证「关键假设*」,会存在试错的可能,但在试错发现有问题之后,产品内核能确保不至于整个方案推倒重来,提高效率,节省成本。

备注:

MVP*:需要注意,MVP和产品内核是不一样的,应该先有产品内核、后做MVP方案设计。MVP可以有很多轮,例如房子装修用哪种木地板等,它只是一种工具,用来做业务判断。关键假设*:详见「关键假设做业务拆解」二、什么是产品内核

产品内核是整个产品特性中,价值最高的最小集合。是唯一的、独特的、最核心的价值。

这也是最近学习得来的一个定义,但是给这句话拆解关键词,可以是:

1. 用户

价值是一定会有一个主要作用对象的,因此一定要基于「用户」去谈论价值。

价值可以有多方面,比如说针对具体的目标用户的具体的场景遇到的什么问题,产品可以解决;还比如说针对具体的目标用户,产品可以为其提供核心的服务特性,不一定是用户遇到的问题。所以一定要基于用户去谈产品内核

2. 价值最高

价值最高,即产品最核心的、唯一的、独特的那个东西,是用户愿意选择这个产品、愿意改变习惯去使用的那个东西。

根据俞军的用户体验公式,用户价值=(新体验-旧体验)-替换成本,可以看出这个「价值最高」的产品内核一定是综合体验,而不是某一个方面做的比对手好,用户就愿意放弃当前而选择重新习惯你的产品。

所以这一步其实是最难的,因为会有很多误以为是价值最高的特性来干扰你,这也是我们需要不断MVP测试、不断试错且探索的一步。

3. 最小集合

「最小」很重要,因为它避免让我们在无尽的探索「黑洞」中迟迟无法明确方向。例如一个产品,为了达到目的,做了功能A、功能B、功能C……功能N,最终用户终于买单了,但团队却无法分辨到底是因为哪个功能让用户买单。不仅浪费成本,而且还无法得出真正吸引用户的点在哪里。

最小的产品内核不一定只有1个,可以是一个集合。要进入这个集合,必须是那些「少一个,产品不成立,用户不买了不用了」的特性,而那些对产品影响不大,无法影响大局的特性,则不算是最小的集合。

例如像是Airbnb,最初的名字是Airbed&Breakfast,起源并不是用户需求,而是自身付不起房租因此将阁楼出租。只有3张床和自制简陋的早餐,但还是吸引了首批3个租客。发掘Airbnb最初的产品内核,可以从3个租客的场景和感受出发,即「满足最基本需求,安全,合理价格」,便是它的最小集合。

三、怎么找产品内核、以及怎么验证

怎么找到产品内核,其实也就是日常我们做每个需求/项目,应该遵循的基础4步:

找到目标用户,明确需求(场景 问题); 找到解决方案(能想到的idea、竞品已有策略、用户期望….); 做加法: 汇总全部功能,全部列成list; 做减法:找到产品内核。即是那些「少一个,产品不成立,用户不买了不用了」的特性。

仍以Airbnb为例,在成立最初,如果要验证什么是其产品核心的话,首先把能想到的产品特性都列出来:

有床,可以住;提供早餐;根据目标地区搜寻合适的房源;在网站上浏览到房源信息;价格便宜(可以接受),性价比高;房东安全;有和家里一样便利的设施。

以上7点是从客户角度感受到的产品特性,然后再做减法,根据「少一个,产品不成立,用户就不会来住」的特性,代入思考后,应是以下几点:

1:有床,可以住;5:价格便宜(可以接受),性价比高;6:房东安全。

除此之外,其他的都是优化项,即应该是在验证了即便只能满足1、5、6这三个产品特性的情况下,仍有客户愿意来住之后,再去考虑如何提升用户体验。

关于如何验证产品内核,本着低成本、快速的原则,有如下几种方法:


仍以验证Airbnb的三个核心产品特性为例,其实只需要有一个信息出口展示给用户即可,大可不必说单独设计一个网站、专门找到目标用户的渠道去投放等等,只需要将3个信息规整,挂到网站上,再结合定的目标(比如有xx个用户入住即为验证通过)判断即可。

关于快速验证,想起来之前和同事讨论,“粗糙的产品是否会伤害用户体验”这个问题:个人观点是不会的,点是在于:

原因一,粗糙的产品并不等于全部都是粗糙。产品内核要精细,其他的粗糙,因为我们是要验证产品内核是否成立,所以除了产品内核,其他都是可以适当粗糙的,否则还可能产生如果成功都不知道是哪些特性导致的成功带来的干扰问题。

原因二,验证产品内核,如果是在项目成立初期,没有多少用户,或者都是一些核心用户,此时反倒不必担心因功能不完善导致用户跑掉,让用户参与到产品内核的体验中,提出建议不是更好么?如果是项目较为成熟,拥有较大用户群了,当需要验证某一特性时,尽量选择目标用户来进行小范围验证,让一小部分用户先使用,结合建议再优化,最后再全量推。

原因三,快速验证,需要避免完美主义。产品在早期有一些不完善的地方是非常正常的,不要觉得有bug或者功能比较少就不好意思让用户使用,反倒是选择花很多时间去做一个“完美”的产品,这本身也不现实,因为没有用户的反馈,产品本身也不可能完美。

四、项目实操与思考

想起之前做APP的经历,反思起来,最基本的问题在于没有找准产品内核。所以在这里重新再思考一遍,如果再要做一次,自己会怎么做。

起初做APP的目的是为了整合公司目前所有APP的获客,提升前端获客效率。基于这个目标,我们想从3个不同维度去验证哪个的获客效率会高,分别是品牌获客、内容获客、利益获客。

品牌获客:通过品牌背书来吸引家长购买课程;内容获客:通过优秀学员的创作故事、内容成果来吸引家长购买课程;利益获客:通过优惠券、好礼赠送的方式来吸引家长购买课程。

而后,做加法:思考我们搭建APP的功能,哪些算是产品内核?首先先列出目前已有的功能 本期即将会做的功能:

即来即学的交互视频(目的是让用户能快速感受我们的教学方式);优惠券购课流程;了解品牌;客服咨询;内容探索(读物,家长课堂,漫画,优秀作品);个人中心;老用户的展示;用户召回。

如果将上述功能分类,可分成以下4类:

第一类 产品内核:2、3、5;第二类 用户体验:1、4、8;第三类 APP基础功能:6;第四类 业务兼顾:7(因为该APP可能触达到的用户群里并非只有新用户/游客)。

因此为了快速验证2、3、5这三点,对于提高获客效率是否起作用,我们需要提供产品给到用户,但是可用现成工具(因为优惠券功能、品牌介绍、内容都是已有的),以低成本验证,对用户随机展示不同的获客方式,最后再用关键转化漏斗做好数据判断,则能得出验证结果。

到开发中期,业务方认为1.0的内容太少了,又想增加读物售卖。若是当时,会以下面2点原因回绝该想法:

原因一:在早期阶段,只有产品内核才需要精细,其他都是可以粗糙的。不然成本、时间都太浪费了;判断得出「读物售卖」并非产品内核,所以不值得做。原因二:对于增加读物去售卖这件事,对我们要验证的点并没有太大作用。换言之如果用户能买,我们也无法验证是哪个角度导致的成功;如果用户不买,也无法验证是哪个角度导致的失败。

因此复盘APP1.0的内容,让我更能了解,在开始做一个项目之前,大家一起思考清楚产品内核和同频验证方式对后续项目顺利进行有多么重要。

随着产品经验的积累,我们在和业务方沟通的过程中,要根据他们提出的想法,找到最核心的点,拿捏好产品内核,才能不断提升产品经理的核心能力。

#专栏作家#

莫琳,人人都是产品经理专栏作家。在线教育产品汪,爱产品,爱摄影,自顾自看,一起交谈。

本文原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

 
 
本文地址:https://xinb2b.cn/sport/doy127886.html,转载请注明出处。

推荐图文
推荐运动知识
网站首页  |  关于我们  |  联系方式  |  使用协议  |  版权隐私  |  网站地图  |  违规举报  |  蜀ICP备18010318号-4  |  百度地图  | 
Processed in 0.046 second(s), 1 queries, Memory 0.66 M