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

美团外卖用户端产品经理实习经历 在2014 年 12 月末的时候，非常幸运地加入美团外卖，成为用户端的产品经理实习生。非常感谢曦哥 、小雷姐以及各同仁的照顾，在那渡过了充实的 4 个月实习生涯，好吧，除去过年，实际差不多 3 个月。我把这 3个月来的经历归结成四个阶段。 盲人摸象 啥都不懂的时候，慢慢摸索，以一个版本切入，以一孔窥全豹，逐渐了解美团外卖用户端产品的整 个业务逻辑。 产品设计只占产品经理工作的一小部分 刚来的时候，带着疑惑，不知道 PM 是做什么的，是不是真的和网上传的一样， PM 是CEO 的学前班 ，那么牛掰，那么传神。曦哥向我介绍了产品经理工作的内容，现在只记得那么一句， 产品设计只“ 占产品经理工作的一小部分 ”。后来，在简书中偶然遇到一篇文章《想成为产品经理要知道的 8各 问题》，上面写产品经理是产品的设计者、推进者、运营者。具体内容就不赘述了，文章中很多内 容和我身处的环境很吻合，仔细一看，原来最初来自于美团章鱼计划的马老师之手。 跟随企业文化，迅速融入 每个公司的企业文化都不一样，就像丛林法则，适者生存。听一个同事说，之前在前一个公司做产 品经理的时候，一个产品功能方案需要出 7-9 遍，不断地评审、不断地优化方案。又听一个同事说， 美团外卖有一段疯狂时期，上午定需求，中午排期，下午开发，晚上测试上线。对于创业型公司 来说，需要的是快速迭代，尽可能去吸引用户、增加流量。对于成熟型公司，需要的是稳健，他们 的任务在于如何服务好已有的用户，尽可能减少用户的流失。这个可以说是一个企业的文化，抑或 的任务在于如何服务好已有的用户，尽可能减少用户的流失。这个可以说是一个企业的文化，抑或 是一个产品在不同时期的文化。到那的第一周，曦哥就让我负责 mt 版本（美团外卖频道的一个过渡 型版本），这个版本那时候处于较稳定的时候，一周一迭代。 测试是熟悉产品的过程 从美团外卖的第二周开始，曦哥就去和主站的人讨论 native 版本，丢我一个人在需求会上提 mt 版本 的需求。我做的工作主要是移植 app 上的活动到 mt 上，产品方案相对简单，技术也知道实现方案， 但问题在于产品的验收环节，也就是测试。其实一开始我是拒绝的，测试不是有专门的测试人员吗 ？为什么要 PM 来测试呢？后来发现，测试其实是了解产品业务逻辑的一个好办法，通过测试并回 归之前的功能，逐渐了解整个美团外卖用户端产品，熟悉对应各个功能模块的负责人，以及与其他 端的关系。 没有 KPI ，数据同样重要 出于一个理科生对数字的敏感，每次 mt 版本上线新功能或活动，我都会查产品上线前后的业务数据 、用户行为数据等，看有没有满足预期的效果，下一步从哪里改进；有没有异常数据，有没有刷单 的风险。实际数据往往跟众多因素有关，一时的数据可能无法从中得到什么结论，但持续的整理分 析数据也能预见一二。于是后来也接手了客户端用户行为数据整理并制作了相关业务数据获取的 方式。 小试牛刀 将app 上的活动移植到 mt版本，后期演变成机械性的重复，能力的提升无非是熟悉到熟练，彷徨中 来了新的任务，让我小试牛刀了一把。 只做目前最迫切的需求 在学校那阵子负责过一个微信公众号，也就是因为这个原因，曦哥让我对接新媒体营销组一些关于 微信公众号的需求。第一个需求是微信关键字配置页面以解决现在配置内容写死在代码中的问题。 网上有一大堆第三方微信管理平台可以借鉴，回复文本信息的功能很快就上线啦，他们用的很愉快 。然后就一发不可收拾又出了图文信息、 H5 页面的方案，后来发现这些锦上添花的事情，不是需求 方目前最迫切的，自然也得不到资源去开发。资源永远是有限的，用 20% 的资源维护优化系统，剩 下的 80% 用来做目前最紧要和最有效的事情。 提前沟通达成事前的基本共识 第二个需求是微信接入多客服系统。之前对多客服也没有了解过，于是花了一定时间去了解多客服 所能提供的功能、背景知识。在需求会上，直接告诉技术去如何如何做，结果技术听得一头雾水， 没法给出一个具体的开发时间。听曦哥教导，类似这种全新的东西，需要实