从《啥是佩奇》提炼出的产品三部曲

产品经理的角度来看,《啥是佩奇》展现了一位极其渴望获得客户认可的产品经理,在客户需求不明确,沟通不畅,且资源非常有限的情况下,如何利用现有资源,在有限时间内,迅速完成需求,获得需求方认可赞赏的故事。

从《啥是佩奇》提炼出的产品三部曲

《啥是佩奇》这个被刷屏了的广告,在互联网圈里也引爆了话题,为什么呢? 因为我们在主角李玉宝身上,看到了产品经理的影子:探寻需求,分析需求&推动需求各方让需求转化为真正产品功能。

从产品经理的角度来看,《啥是佩奇》展现了一位极其渴望获得客户认可的产品经理,在客户需求不明确,沟通不畅,且资源非常有限的情况下,如何利用现有资源,在有限时间内,迅速完成需求,获得需求方认可赞赏的故事。

这是产品经理的日常,围绕着一条主线进行的,这条主线就是产品三部曲:什么是真正的需求,如何把握产品设计,和如何推动产品落地。

未看视频的小伙伴,[啥是佩奇](https://www.bilibili.com/video/av41021517/?redirectFrom=h5)

剧情简介:临近年关,眼瞅三岁孙子要回村过节,李玉宝却难为坏了,孩子想要一个佩奇,可啥是佩奇?一头雾水的他借村里的喇叭问了一圈,得到的答案令人啼笑皆非,有人说是直播网站性感女主播,有人拿出同名洗洁精,还有人说是棋牌的一种。兜兜转转,懵懵懂懂,最后李玉宝用鼓风机自制了一个“佩奇”。

一、什么是真正的需求

产品经理的需求来源广,我们可将需求按来源分成以下几个方面:

客户(现场沟通、调研),这里的客户要区分,是真正的使用者还是购买决策者,对产品的体验和使用要求不一样,需要选择分析;

老板要求,老板拍脑门或是经过思考的洞见,需求进一步沟通确认;

用户调研,通过定量或定性的调研,注意产品筛选、转化;

产品自主规划,根据现有的产品生态发展、竞品、行业等思考转化,也需要提炼和转化。

一般情况下,产品在接到客户需求后,不是一味的接受(产品小白容易犯全盘接受客户、用户需求,认为所有的客户提出的都是对的,都要实现的错误),需要探寻需求最初的根源,最原始的需求,要了解真正的需求。消费者说要一匹更快的马,其实是汽车,最根源的是希望更快的交通工具;消费者说要买锤子去砸钉子,最根源需求的是一个黏钩(挂东西)。

举一个笔者在工作中遇到的例子,接到业务部门提的一个需求:统计医院号源总限数。接到需求后,我和同事A一起分析,既然要统计数目,就要精确。因此,我们具体分析了不同情况,包括独享、共享模式,有号源、无号源、有限数、无限数等不同情况下,号源总限数和医院+限数的统计方式。

设计方案出来后,我们发现,如果要统计精确的号源数,即使采用这套详细的设计方案,还是会有问题,因为有些医院可能是无号源无限数,没有准确的号源量。

从《啥是佩奇》提炼出的产品三部曲

需求

于是,我们又重新审视我们的需求,为什么要统计号源量。我们了解到统计号源主要是为优化导医分配提供依据,那进行导医分配需要我们怎么样的数据支持呢?

我们顺着这个思路向下思考,发现其真正要解决的问题有两个,一个是我们是否需要在这个医院投放导医,另一个是投放导医后的效果如何。根据要解决的情况,回归到我们最初的问题,是需要所有医院的号源量必须都非常准确么?是需要统计相关号源的所有维度么?

从《啥是佩奇》提炼出的产品三部曲

需求本质探寻

其实不然,我们是要找到预约总量大,号源紧张、但线上预约量少的医院。这些医院的号源数据和维度一定要准确,而对于那些预约量小的医院,其实不必纠结,但往往是这种少量的小医院,导致我们的统计复杂很多。根据这样分析的结果,我们设计了一套合适的方案。

从《啥是佩奇》提炼出的产品三部曲

本质需求应对方案1

当我们即将把设计方案投入开发时,了解到,公司最近战略的改变,降低导医推广力度。因此,通过统计医院号源数以协助分配导医已经不是我们的痛点,通过号源总限数展示我们的业务能力取而代之。

从《啥是佩奇》提炼出的产品三部曲

需求变更

基于这种情况,我们可以通过COP定时统计医院的剩余量与预约成功量之和作为号源总限数,从量级的程度上保证号源总限数更接近实际情况。

从《啥是佩奇》提炼出的产品三部曲

本质需求应对方案

所以,产品经理在拿到一个需求后,需要先分析需求,探寻最原始的需求根源,搞清楚对方的目的是什么,去提炼和抽象。需求是动态的,当需求发生改变时,要保持敏感,快速灵活地调整方案,不能一味地只盯原始需求不放,忽略了需求的变更带来的变化。

从《啥是佩奇》提炼出的产品三部曲

真正的需求

在《啥是佩奇》中,李玉宝接到孙子“客户”的想要佩奇的需求,但由于情况所限,无法进一步沟通,他只能想方设法去了解客户真正的需求到底是什么,他广泛调研,通过各方线索,不断挖掘需求,探寻真实需求:他去查字典,去村委会借村里的喇叭问,期间得到了各种不靠谱的答案。

在这个过程中,不断寻找最了解需求的人,哪怕获得了答案,但自己分析答案与孙子初衷是否一致。最终他找到了关键任务:老三家媳妇,得到了关键信息:佩奇是红色的猪,为李玉宝指明了方向。

二、如何把握产品设计?

产品或需求方向明确之后,如何把握产品设计呢?

我先前接过一个非常紧急的项目11.11号接到客户要求,25号上线。为了给开发预留充分时间,接口设计预计在2天里完成。

第一天,我将所有MM健康档案相关的医疗信息资料搜集到位,熟悉业务,并参照医院+的接口,设计了第一版健康档案医疗信息接口。这个基础版接口可以满足项目上线需要,但可能存在医疗信息列表页加载时间长,用户体验不好的情况。因为基础版的检查检验等有主子关系的接口是一个,而医疗信息明细项目又比较多,如果在列表页加载了明细信息,可能需要用户长时间等待。

考虑到这种情况,第二天,我就对健康档案的接口进行了改造,将检验检测单、诊断等有主子关系的医疗信息的列表、详情接口进行了拆分,这样,在列表接口中只返回简要信息,加载时间短。当用户需要查看某项具体检查时,我们再调用明细接口给用户展示详细内容,以提升用户体验。

在开发过程中,我们发现在不到两周的时间1个人力开发10个接口,过于紧张,因此,我们必须对接口再改造。考虑到APP展示的逻辑和用户体验,我们将医嘱、处方接口的列表和详情进行了中和,将获取检查检验单列表的接口进行了合并,最终将第二版的10个接口改进成4个。

在接口合并时,其实我内心经过了一番挣扎,因为这样的合并不符合我们对精益求精的追求,但是如果我坚持原则可能导致项目延期,因此,我还是做出了妥协——第三版接口作为最终的使用版投入了开发。健康档案的项目后来进展很顺利,按照预期完成了项目上线。

从《啥是佩奇》提炼出的产品三部曲

把握产品设计

每个产品经理心中都有一个乔布斯,希望追求极致,每个细节做到最好,本着这样的想法,我设计了健康档案第二版接口。

从《啥是佩奇》提炼出的产品三部曲

产品追求

但,很多时候,我们面临的是时间、资源有限的项目,如果一味追求极致和完美,可能导致项目延期,就像刚刚提到的,如果采用第二版接口,我们无法在要求时间节点前完工。这种情况下,我们就要在保证数据正确和用户体验这个大方向一致的情况下,牺牲部分完满,做出适度的让步,以顺利地完成项目。

从《啥是佩奇》提炼出的产品三部曲

平衡适度设计

《啥是佩奇》中,李玉宝拿到了真正的最根源的需求:卡通小猪佩奇,他没有马上动手,他又进行了深入的分析。因为他没有办法做一个真正会说话的佩奇给孙子,他更没有办法在这样短的时间里做到,他必须经过转化和平衡,找了形似佩奇的鼓风机,并在做的过程中不断沟通和修正,类似敏捷开发,利用现有的有限资源让产品真正实现。

三、如何推动产品落地?

在《啥是佩奇》中,产品李玉宝在历尽千辛万苦将“佩奇”做出来,本想要给客户交付,当接到需求不做了的时候,虽然有些失落,其积极争取展示机会,最后终于将产品在客户面前展示,获得了超过预期的效果,对需求提出分真正产生价值。画外音,现在李玉宝的大作产品,佩奇手工艺、佩奇观赏品、还有周边衍生品,在各大电商渠道有售,真正地让大家用了起来。

当需求历经设计、开发、测试层层考验诞生后,还不是真正的产品,因为真正的产品是有价值的,而产品要人’用”起来,感知到才有价值。

笔者,先前在工作中发现,各医院HIS返回的预约挂号失败原因众多、内容杂乱不明晰,用户体验差。因此,我们对医院HIS返回的失败原因进行分类和标准化,将HIS返回杂乱的原因通过规则映射成标准失败原因展示给用户。但随着我们业务的发展,各医院HIS系统对预约挂号业务失败返回的原因在不断增多,现有的预约挂号失败原因的规则不能囊括所有的失败原因,需要继续维护。

从《啥是佩奇》提炼出的产品三部曲

需求背景

于是,我设计了一个失败原因映射规则的后台管理,这样,通过固定的流程就可以在后台管理中方便地实现规则的维护。原先,我的预想是,运维人员通过标准流程可以在后台中对规则进行日常的监控和管理。

从《啥是佩奇》提炼出的产品三部曲

产品方案

但后来我发现,实际情况没那么简单。一方面,HIS返回的失败原因可能不明确,运维人员不能从HIS返回的失败原因判断具体情况,从而无法定义规则,这时,就需要实施协助确认;另一方面,失败原因作为展示给用户的内容,运维不好把握规则的定义,需要产品经理协助判断。

面对这种情况,我们协调各方人员,制定了实行方案:运维人员每周监控统计未映射的失败原因。对于不明确的原因由实施人员协助确认。此外,实施人员还可以反馈映射有误的失败原因给运维,运维汇总后根据标准流程新增或修改映射规则,产品对运维新增或修改的规则做质量把控,确认后由运维同事将规则维护到后台管理中。如果遇到问题,开发协助定位解决。

从《啥是佩奇》提炼出的产品三部曲

产品推动落地

通过这样一连串标准的流程和职责明确的分工,失败原因映射规则的后台管理用了起来,通过它我们不断完善失败原因管理规则,从一定程度上提升了用户体验。

产品经理不仅仅要关注产品、需求的分析和设计,当产品做出来后,产品经理还要能推进产品的落地和使用,如果我们在后台管理完成后直接交给运维同事不管,很可能因为刚刚我们提到的原因用不起来,产品经理要协调不同部门的同事,一起为了目标去设定整套的标准和流程帮助产品的正常运行。

从《啥是佩奇》提炼出的产品三部曲

产品三部曲

作为一名产品经理,拿到需求的时候,不能盲从,就像李宝玉一样,我们需要多方探寻,了解需求的本质,把握需求的变化,根据实际情况灵活调整设计方案。

需求确认后,我们要权衡产品的追求和实际情况,在有限时间、资源,保证项目进度情况下,将产品做到精益求精;产品诞生后,产品经理还要能协调各方力量,争取客户认可,让产品真正用起来,让你的“佩奇”发挥产品的价值~

本文由 @stellaxu

去年今日运营文章

  1. 2022:  人人都在说谎(0)
  2. 2022:  抖音术语“黑话”必知必会(0)
  3. 2021:  2020年视频号发展白皮书(0)
  4. 2021:  2021年2月营销日历(开始放假)(0)
  5. 2018:  你连什么是「运营」都不知道,凭什么进互联网公司工作?(0)

本文转载于stellaxu ,本文观点不代表爱运营立场,转载请联系原出处。如内容、图片有任何版权问题,请联系爱运营处理。

(0)
爱运营爱运营管理员
上一篇 2019年1月21日 下午6:45
下一篇 2019年1月21日 下午7:09

推荐资讯

发表回复

登录后才能评论
分享本页
返回顶部