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