美团外卖用户端产品经理实习经历

作者: 程小超 | 来源:发表于2015-05-03 16:20 被阅读36846次

在2014年12月末的时候，非常幸运地加入美团外卖，成为用户端的产品经理实习生。非常感谢曦哥、小雷姐以及各同仁的照顾，在那渡过了充实的4个月实习生涯，好吧，除去过年，实际差不多3个月。我把这3个月来的经历归结成四个阶段，从朦胧不懂逐渐清晰产品思路。爆一张内部图。

盲人摸象

啥都不懂的时候，慢慢摸索，以一个版本切入，以一孔窥全豹，逐渐了解美团外卖用户端产品的整个业务逻辑。

产品设计只占产品经理工作的一小部分

刚来的时候，带着疑惑，不知道PM是做什么的，是不是真的和网上传的一样，PM是CEO的学前班，那么牛掰，那么传神。曦哥向我介绍了产品经理工作的内容，现在只记得那么一句，“产品设计只占产品经理工作的一小部分”。后来，在简书中偶然遇到一篇文章《想成为产品经理要知道的8各问题》，上面写产品经理是产品的设计者、推进者、运营者。具体内容就不赘述了，文章中很多内容和我身处的环境很吻合，仔细一看，原来最初来自于美团章鱼计划的马老师之手。

跟随企业文化，迅速融入

每个公司的企业文化都不一样，就像丛林法则，适者生存。听一个同事说，之前在前一个公司做产品经理的时候，一个产品功能方案需要出7-9遍，不断地评审、不断地优化方案。又听一个同事说，美团外卖有一段疯狂时期，上午定需求，中午排期，下午开发，晚上测试上线。对于创业型公司来说，需要的是快速迭代，尽可能去吸引用户、增加流量。对于成熟型公司，需要的是稳健，他们的任务在于如何服务好已有的用户，尽可能减少用户的流失。这个可以说是一个企业的文化，抑或是一个产品在不同时期的文化。到那的第一周，曦哥就让我负责mt版本（美团外卖频道的一个过渡型版本），这个版本那时候处于较稳定的时候，一周一迭代。

测试是熟悉产品的过程

从美团外卖的第二周开始，曦哥就去和主站的人讨论native版本，丢我一个人在需求会上提mt版本的需求。我做的工作主要是移植app上的活动到mt上，产品方案相对简单，技术也知道实现方案，但问题在于产品的验收环节，也就是测试。其实一开始我是拒绝的，测试不是有专门的测试人员吗？为什么要PM来测试呢？后来发现，测试其实是了解产品业务逻辑的一个好办法，通过测试并回归之前的功能，逐渐了解整个美团外卖用户端产品，熟悉对应各个功能模块的负责人，以及与其他端的关系。

没有KPI，数据同样重要

出于一个理科生对数字的敏感，每次mt版本上线新功能或活动，我都会查产品上线前后的业务数据、用户行为数据等，看有没有满足预期的效果，下一步从哪里改进；有没有异常数据，有没有刷单的风险。实际数据往往跟众多因素有关，一时的数据可能无法从中得到什么结论，但持续的整理分析数据也能预见一二。于是后来也接手了客户端用户行为数据整理并制作了相关业务数据获取的方式。

小试牛刀

将app上的活动移植到mt版本，后期演变成机械性的重复，能力的提升无非是熟悉到熟练，彷徨中来了新的任务，让我小试牛刀了一把。

只做目前最迫切的需求

在学校那阵子负责过一个微信公众号，也就是因为这个原因，曦哥让我对接新媒体营销组一些关于微信公众号的需求。第一个需求是微信关键字配置页面以解决现在配置内容写死在代码中的问题。网上有一大堆第三方微信管理平台可以借鉴，回复文本信息的功能很快就上线啦，他们用的很愉快。然后就一发不可收拾又出了图文信息、H5页面的方案，后来发现这些锦上添花的事情，不是需求方目前最迫切的，自然也得不到资源去开发。资源永远是有限的，用20%的资源维护优化系统，剩下的80%用来做目前最紧要和最有效的事情。

提前沟通达成事前的基本共识

第二个需求是微信接入多客服系统。之前对多客服也没有了解过，于是花了一定时间去了解多客服所能提供的功能、背景知识。在需求会上，直接告诉技术去如何如何做，结果技术听得一头雾水，没法给出一个具体的开发时间。听曦哥教导，类似这种全新的东西，需要实现跟技术沟通，让技术了解相关的背景，达成一定的共识。沟通之后，技术了解完背景知识之后，开发速度是杠杠的。

不做比做更需要勇气

发现我们app的举报餐厅页中存在部分的客诉问题，于是我们先做了一些简单地工作，如修改文案、修改选项，发现没啥效果。审查组希望将这部分客诉问题分离出来，更有效分析和处理举报信息。运营组希望将这部分的客诉问题导入到常规的客诉流程中，以便服务好每一个用户。看来分离客诉信息是势在必行了，当时我也把基本的方案也出好了，可仔细一想：用户为什么会在这里面提出客诉问题？这里面的客诉信息真能有效分离吗？用户真的期待这里面的客诉问题被反馈吗？用户体验真的会因此提升吗？经过简单地调研及和曦哥的讨论，结果都指向“不处理是最好的”。于是，工作的重心改变为说服其他组为什么我们不处理。

初生牛犊

之前的产品方案，基本都是有据可循，出身牛犊不畏虎，当然更期待独立的产品思考和产出。

技术思维有时会妨碍产品的设计

微信公众号里大量的粉丝，通过关注微信抢红包，我们期待他们转换成外卖的用户，同时借助于微信的传播也会有更多粉丝。设计方案的时候，过分着眼于微信的开发者文档，以“实现”的角度去看，结果自然出来的东西不尽人意。发现问题后，调整思路，“产品为先，技术为辅”设计好整体产品流程，并在根据微信这个特殊场景做相应调整。

“复制”不见得是最省成本的

关注微信抢红包活动，需要一个相应的红包金额配置后台。由于之前有一个分享红包金额配置后台，为了图快，为了“省”，复制一个页面的想法就出来了。小雷姐（大美女领导）问我，运营需要配置两个页面，这样真的合适吗？扩展功能的需求到底比复制页面增加多少工作量呢？经过与技术的沟通，发现复制页面并不比扩展省多少时间，于是扩展了现有红包金额配置的功能，也有利于以后不同活动的接入，给未来省时间。

框架内的微创新

红包提醒之前采用的是短信通知，用户每收到一个红包，系统就会自动发一条红包到账短信到用户手机上。每天的红包大致有80w，按每条3分钱计算，一天花在红包短信上的费用就有2.4w啦。了解到90%以上的红包领取都在微信中，小雷姐就将这个省钱的任务交给我了。调研发现，嘀嘀打车、功夫熊等通过发送模板信息提示红包到账，我想我们也可以效仿。结果发现这个的前提是需要先关注公众号（有些不需要，你懂的），查询历史红包还要涉及绑定账号等等。那时候正在看《微创新》，与传统的跳出框架去创新不同，它宣扬在框架内利用手头的资源进行微创新。跳出框架之后天马行空的创新，听起来可能很有趣新颖，但是仔细推敲，诟病不少，实用者甚微。而在框架内的思考，是基于现在工作基础上切实可行的微创新，改变不大，收益不少。回到最初的问题，分析一下用户提醒的方式：短信、气泡、push、微信等。最后提出了新用户发送短信，老用户发送push信息的方案，基本完成省钱任务。

越挫越勇

接下里一段时间，在包容犯错的氛围中，不断踩坑，持续前进。

产品解决不了所有的问题

随着新版本的美团app中使用native版本，mt版本已经完成了过渡时期的使命。mt版本作为一个独立版本存于老版本的美团app中，每次开发新功能，都要兼容这个版本，技术、测试、产品都期待它早日下线（切回到i版）。策略分为两步：第一，引导用户升级到高版本；第二，让不升级的用户接受无优惠、无在线支付的低版本。大家都志气高昂地干着“干掉mt”这件“伟大”的事，结果事与愿违，用户压根没去升级，mt版本上的用户数依旧降不下来。小雷姐跟我们说，主站那也期待用户去升级，为什么到现在为止还有那么多老版本存在，引导升级没有那么容易。用户是上帝，我们也只能继续维护这个版本。

偶尔借助一下领导的力量

后来负责搭建运营push管理后台，属于外卖这的第一个运营工具。一个是这个存在技术的难点，另一个是这个属于跨组需求，有时候推动不是那么有效。开学季，需要利用push给用户给发送红包，可当时后台的能力还不支持统计，无法正式使用。任务紧急，没办法，只能借助一下领导的力量，小雷姐过去说明了一下，果然推进效果显著。

先用起来才能发现问题

搭建运营push管理后台的时候，第一次试点，发现单次发送量过小，第二次试点，发现没法满足统计需求，第三次试点，发现线下环境竟然可以发送到真实用户。同时也发现，需要提供通用的用户筛选模型等。不断地尝试，不断地发现问题，不断优化产品方案。