|
从产品经理的角度来看，《啥是佩奇》展现了一位极其渴望获得客户认可的产品经理，在客户需求不明确，沟通不畅，且资源非常有限的情况下，如何利用现有资源，在有限时间内，迅速完成需求，获得需求方认可赞赏的故事。  《啥是佩奇》这个被刷屏了的广告，在互联网圈里也引爆了话题，为什么呢？ 因为我们在主角李玉宝身上，看到了产品经理的影子：探寻需求，分析需求&推动需求各方让需求转化为真正产品功能。 从产品经理的角度来看，《啥是佩奇》展现了一位极其渴望获得客户认可的产品经理，在客户需求不明确，沟通不畅，且资源非常有限的情况下，如何利用现有资源，在有限时间内，迅速完成需求，获得需求方认可赞赏的故事。 这是产品经理的日常，围绕着一条主线进行的，这条主线就是产品三部曲：什么是真正的需求，如何把握产品设计，和如何推动产品落地。 未看视频的小伙伴，[啥是佩奇](https://www.bilibili.com/video/av41021517/?redirectFrom=h5) 剧情简介：临近年关，眼瞅三岁孙子要回村过节，李玉宝却难为坏了，孩子想要一个佩奇，可啥是佩奇？一头雾水的他借村里的喇叭问了一圈，得到的答案令人啼笑皆非，有人说是直播网站性感女主播，有人拿出同名洗洁精，还有人说是棋牌的一种。兜兜转转，懵懵懂懂，最后李玉宝用鼓风机自制了一个“佩奇”。 一、什么是真正的需求产品经理的需求来源广，我们可将需求按来源分成以下几个方面：
一般情况下，产品在接到客户需求后，不是一味的接受（产品小白容易犯全盘接受客户、用户需求，认为所有的客户提出的都是对的，都要实现的错误），需要探寻需求最初的根源，最原始的需求，要了解真正的需求。消费者说要一匹更快的马，其实是汽车，最根源的是希望更快的交通工具；消费者说要买锤子去砸钉子，最根源需求的是一个黏钩（挂东西）。 举一个笔者在工作中遇到的例子，接到业务部门提的一个需求：统计医院号源总限数。接到需求后，我和同事A一起分析，既然要统计数目，就要精确。因此，我们具体分析了不同情况，包括独享、共享模式，有号源、无号源、有限数、无限数等不同情况下，号源总限数和医院+限数的统计方式。 设计方案出来后，我们发现，如果要统计精确的号源数，即使采用这套详细的设计方案，还是会有问题，因为有些医院可能是无号源无限数，没有准确的号源量。  需求本质探寻 其实不然，我们是要找到预约总量大，号源紧张、但线上预约量少的医院。这些医院的号源数据和维度一定要准确，而对于那些预约量小的医院，其实不必纠结，但往往是这种少量的小医院，导致我们的统计复杂很多。根据这样分析的结果，我们设计了一套合适的方案。  需求变更 基于这种情况，我们可以通过COP定时统计医院的剩余量与预约成功量之和作为号源总限数，从量级的程度上保证号源总限数更接近实际情况。  真正的需求 在《啥是佩奇》中，李玉宝接到孙子“客户”的想要佩奇的需求，但由于情况所限，无法进一步沟通，他只能想方设法去了解客户真正的需求到底是什么，他广泛调研，通过各方线索，不断挖掘需求，探寻真实需求：他去查字典，去村委会借村里的喇叭问，期间得到了各种不靠谱的答案。 在这个过程中，不断寻找最了解需求的人,哪怕获得了答案，但自己分析答案与孙子初衷是否一致。最终他找到了关键任务：老三家媳妇，得到了关键信息：佩奇是红色的猪，为李玉宝指明了方向。 二、如何把握产品设计？产品或需求方向明确之后，如何把握产品设计呢？ 我先前接过一个非常紧急的项目11.11号接到客户要求，25号上线。为了给开发预留充分时间，接口设计预计在2天里完成。 第一天，我将所有MM健康档案相关的医疗信息资料搜集到位，熟悉业务，并参照医院+的接口，设计了第一版健康档案医疗信息接口。这个基础版接口可以满足项目上线需要，但可能存在医疗信息列表页加载时间长，用户体验不好的情况。因为基础版的检查检验等有主子关系的接口是一个，而医疗信息明细项目又比较多，如果在列表页加载了明细信息，可能需要用户长时间等待。 考虑到这种情况，第二天，我就对健康档案的接口进行了改造，将检验检测单、诊断等有主子关系的医疗信息的列表、详情接口进行了拆分，这样，在列表接口中只返回简要信息，加载时间短。当用户需要查看某项具体检查时，我们再调用明细接口给用户展示详细内容，以提升用户体验。 在开发过程中，我们发现在不到两周的时间1个人力开发10个接口，过于紧张，因此，我们必须对接口再改造。考虑到APP展示的逻辑和用户体验，我们将医嘱、处方接口的列表和详情进行了中和，将获取检查检验单列表的接口进行了合并，最终将第二版的10个接口改进成4个。 在接口合并时，其实我内心经过了一番挣扎，因为这样的合并不符合我们对精益求精的追求，但是如果我坚持原则可能导致项目延期，因此，我还是做出了妥协——第三版接口作为最终的使用版投入了开发。健康档案的项目后来进展很顺利，按照预期完成了项目上线。  产品追求 但，很多时候，我们面临的是时间、资源有限的项目，如果一味追求极致和完美，可能导致项目延期，就像刚刚提到的，如果采用第二版接口，我们无法在要求时间节点前完工。这种情况下，我们就要在保证数据正确和用户体验这个大方向一致的情况下，牺牲部分完满，做出适度的让步，以顺利地完成项目。  平衡适度设计 《啥是佩奇》中，李玉宝拿到了真正的最根源的需求：卡通小猪佩奇，他没有马上动手，他又进行了深入的分析。因为他没有办法做一个真正会说话的佩奇给孙子，他更没有办法在这样短的时间里做到，他必须经过转化和平衡，找了形似佩奇的鼓风机，并在做的过程中不断沟通和修正，类似敏捷开发，利用现有的有限资源让产品真正实现。 三、如何推动产品落地?在《啥是佩奇》中，产品李玉宝在历尽千辛万苦将“佩奇”做出来，本想要给客户交付，当接到需求不做了的时候,虽然有些失落，其积极争取展示机会，最后终于将产品在客户面前展示，获得了超过预期的效果，对需求提出分真正产生价值。画外音，现在李玉宝的大作产品，佩奇手工艺、佩奇观赏品、还有周边衍生品，在各大电商渠道有售，真正地让大家用了起来。 当需求历经设计、开发、测试层层考验诞生后，还不是真正的产品，因为真正的产品是有价值的，而产品要人’用”起来，感知到才有价值。 笔者，先前在工作中发现，各医院HIS返回的预约挂号失败原因众多、内容杂乱不明晰，用户体验差。因此，我们对医院HIS返回的失败原因进行分类和标准化，将HIS返回杂乱的原因通过规则映射成标准失败原因展示给用户。但随着我们业务的发展，各医院HIS系统对预约挂号业务失败返回的原因在不断增多，现有的预约挂号失败原因的规则不能囊括所有的失败原因，需要继续维护。  产品方案 但后来我发现，实际情况没那么简单。一方面，HIS返回的失败原因可能不明确，运维人员不能从HIS返回的失败原因判断具体情况，从而无法定义规则，这时，就需要实施协助确认；另一方面，失败原因作为展示给用户的内容，运维不好把握规则的定义，需要产品经理协助判断。 面对这种情况，我们协调各方人员，制定了实行方案：运维人员每周监控统计未映射的失败原因。对于不明确的原因由实施人员协助确认。此外，实施人员还可以反馈映射有误的失败原因给运维，运维汇总后根据标准流程新增或修改映射规则，产品对运维新增或修改的规则做质量把控，确认后由运维同事将规则维护到后台管理中。如果遇到问题，开发协助定位解决。  产品三部曲 小结作为一名产品经理，拿到需求的时候，不能盲从，就像李宝玉一样，我们需要多方探寻，了解需求的本质，把握需求的变化，根据实际情况灵活调整设计方案。 需求确认后，我们要权衡产品的追求和实际情况，在有限时间、资源，保证项目进度情况下，将产品做到精益求精；产品诞生后，产品经理还要能协调各方力量，争取客户认可，让产品真正用起来，让你的“佩奇”发挥产品的价值~
本文由 @stellaxu 原创发布于人人都是产品经理。未经许可，禁止转载 题图来自Unsplash，基于CC0协议 |
