菜鸟PM眼中的“道”与“术”

　　本篇以一个菜鸟赛季产品经理的视角，从“道”和“术”角度展开讨论。
　　“道”即世界观怎么看待产品经理的世界；
　　“术”即方法论怎么做好产品经理（之我见）。
　　道：怎么看待产品经理的世界
　　什么是产品经理？产品经理需要具备哪些能力？
　　引用我最赞成的关于产品经理定义：驱动和影响设计、开发、测试、运营和市场等人员，推进产品周期的经理人。
　　具体来说，产品经理通过市场调研、竞品分析、用户调研等手段，产生了若干idea（需求的雏形），经过需求评估和管理后，将需求具象化为产品需求文档、原型交互图。接下来，翻译给研发（RD）开发实现；联系测试（QA）测试开发结果是否符合预期，验收无误后联系打包开小流量实验；跟着DA（数据分析师）一起看实验结果是否正向，正向就扩量直至上线发版，否则评估是否下线；产品上线后和运营一起demo出产品策略，包装showcase，为销售提供支撑。
　　总体而言，从需求产生到最终落地，产品经理需要全程参与，是产品的主要负责人。
　　某种程度上，干着老板的活，操着老板的心，但是没有特权，甚至全司的RD都是老板，坊间称为“无授权领导”。
　　（图片来自网络）
　　在产品经理参与产品完整生命周期的过程中，少不了和各方打交道，因此王坚把产品经理比喻成老板、用户、开发之间的翻译。
　　这个非常好理解，产品经理要做的就是用简洁易懂的语言，把用户需求翻译给老板，以争取资源；也翻译给开发，以描绘开发需求的价值；必要的时候把老板的意思翻译给开发。
　　（手动狗头）
　　至于产品经理需要哪些能力，《神一样的产品经理》的能力模型是我比较认可的：
　　聚焦到商业产品经理，最重要的能力如下图：
　　Strikeabalance：产品是平衡各方的产物
　　1）策略效益和开发成本的平衡产品经理和开发的平衡
　　谈及PM，就不得不说到PM和RD之间“不可调和”的矛盾。
　　产品经理和开发之间的矛盾，是策略效益和开发成本之间矛盾的外在表现。
　　一个预期能带来丰厚收益的产品策略，如果因为导致开发成本过高而难以落地，也不能算得上是一个好的策略。毕竟在瞬息万变的互联网世界里，敏捷开发快速迭代是生存的首要技能。
　　举一个简单的例子：
　　埋点记录了事件发生的界面、具体事件、时间动作发生的具体对象，对于产品经理做归因十分有帮助。换句话说，有了埋点，往小了说，产品经理可以知道用户是在哪个环节的哪个区域进行了怎样的触发；往大了说，整体链路上各个环节的用户流失情况可以尽收眼底。
　　极端的一种设想情况（当然这种情况没有实操性）下，通过分析用户进入沉浸流界面后滑动屏幕的触发埋点位置，判断用户使用的是左手还是右手，依此调整接下来屏次转化button的位置。
　　理论上，埋点越详细，产品经理在数据后台生成的的用户行为轮廓越清晰，归因越严谨。但是，增加埋点密度的同时，意味着开发成本的极大提高，而且后台数据量也会爆炸上升，数据存储和处理要占用的资源可能超出承受范围，这时候就得回归到一个重要问题上来：是否有做的必要，ROI是多少？
　　最终，在策略效益和开发成本之间取得一个平衡，那就是只对头像、名称、来源、转化按钮、蒙层、吊起小程序等位置设置埋点。
　　同样的道理，产品经理在考虑极致性的时候，也得考虑可行性。
　　听说过一个极端的反面案例，一硬件厂商PM让RD设计传感器识别用户虹膜颜色，依照识别结果动态调整点击按钮的算色。这种需求听起来很极客，但实际上几乎没有实操的可能，实在是为难程序员。
　　产品经理OS：我不是，我没有，别瞎说啊（图片来自网络）
　　话说回来，当有了明确的产品构想，成本过高不能成为阻碍构想落地的“死线”。
　　王坚做阿里云，前期摸索亏损了不少钱，受到不少非议，好在马云清楚意识到云计算是未来，坚定地站在王坚这边：每年对云计算投入10个亿，连续投十年。事实证明，尽早布局云计算是正确的。
　　当然，不是所有公司都有阿里的财力，也不是所有公司负责人都有马云那样的眼光和魄力，最有实操性的还是在策略效益和开发成本之间取得平衡。
　　2）用户体验和商业变现的平衡
　　互联网的模式大致可以总结为：互联网公司为用户提供问题解决方案或者效率提高服务，用价值吸引用户，并在海量用户盘子上构筑商业模式，通过会员、广告等模式盈利，回过头来更好地服务用户。
　　其中，用户体验的重要性无需多言。当用户体验更好的时候，流量自然会增加，信息分发的上游和下游有更多的触角，用户得到更好的体验。
　　比如美团的外卖业务满足了用户便捷饮食的需求，通过口碑推荐、超时赔付吸引了越来越多的用户，又因为用户基数大、需求旺盛的缘故吸引了越来越多的商家入驻，反过头来带给用户更多的选择。
　　此外，互联网本身就具有边际成本（单位新增产品带来总成本的增量）低的特点，而随着用户和商家数量的快速增加，营销成本被分摊，美团就拥有了更多整合变现资源的空间。
　　贝索斯的“亚马逊飞轮”
　　商业变现是公司生存的前提，尤其在资本活力萎靡的今天，过去那种拿张PPT就能融钱的日子一去不复返，变现能力的重要性日益彰显。
　　早期QQ吸引了海量用户后，却苦于找不到合适的变现模式，马化腾甚至考虑把腾讯打包卖给广东电信局。从一开始的QQ秀到现在的微信朋友圈植入原生化广告，腾讯逐渐摸索出适合自己的变现道路，盈利规模不断攀升。腾讯毕竟是幸运的，更多的企业倒在了没能找到合适的商业变现问题上。
　　“围绕生意展开的主义”（图片来自网络）
　　用户体验和商业变现能力都是互联网企业生存的前置条件，二者似乎又站在了对立面上：
　　对于以广告模式变现的企业，只考虑用户体验，最好永远不要给用户下发广告没有广告企业生存不下去；企业拼命下发广告触达用户，恨不得十屏视频有九条广告用户使用体验太差，就会选择离开，没有了用户，企业也失去了存在的价值。
　　如何破局呢？
　　答案是在用户体验和商业变现能力之间达到折中。
　　比如上述例子的难点归根到底可以聚焦成一个问题：adload设为多少，可以保证在不过分影响用户体验的前提下，实现高广告收益？
　　实际上，演化成一个优化问题，边界条件涉及两方面指标：用户侧的留存、日活、停留时长等；商业侧的广告主消耗、CVR、CTR等。
　　strikeabalance
　　有一说一，用户体验和商业变现能力之间的平衡状态应该是一段动态可调整的区间，而不是单点。
　　比如学生放暑假了，就可以适当放宽游戏行业广告的频控，以期合理收割一波收益；发现素材普遍存在作弊雷同的情况，就把这类广告频控收紧一些，对用户的打扰减少的同时，也能倒逼广告主优化广告素材（多说一句，对广告位的争夺有点像拍卖，以后有机会再讨论）。
　　给用户体验和商业变现分别设定底线，互为镣铐，在双方底线上探索资源分配的最优解。究竟怎样进行折中，就看公司秉持怎样的策略了。
　　Whywhathow的思维顺序
　　让我们闭上眼睛认真思考一个问题：面对一件陌生的任务，我们一般是怎么操作的？
　　是不是不管三七二十一，先做起来再说，毕竟“良好的开端是成功的一半”。于是，我们花费了大量的精力，经过无数艰难险阻，终于摆动出一点模样。这时候，往往陷入到新的麻烦中：我当初要的是什么？我为什么要做这些？我的努力是不是白费了？！
　　这就是典型的howwhatwhy思维顺序，即率先考虑方法，其次是方法施用的对象，最后才回到此番折腾的意义上来。
　　有类似经验的朋友不难发现，“做出来的”和“想要的”之间，往往存在巨大的位错；而被迫返工，带来的是惊人类似的资源浪费和意志损耗。
　　在我们接受到的传统教育中，推崇的是行动的巨人，强调甚至过分强调的是着手去做的重要性。尤其是在无从下手的时候，我们接受的普遍智慧是：那不妨随便动手试试看。
　　这其实是一个巨大的误区，“良好的开端”并不着眼在“开端”上，而在“良好的”上；后者的意思可以理解为深思熟虑、充分准备，短语的意思变成了想好了行动的意义并献上执行力，成功的概率大大增加。行动的巨人没有强大的思想，多半只是贸进的庞然大物；哪怕由于时间紧迫不得不先动手操练，也有必要及时回归初心，“知道为什么出发，才能走得更远”。
　　与howwhatwhy相对，我们应该有一种更为高效的行事思维，也就是Whywhathow。
　　一篇科研论文，先是对课题所处行业做背景介绍，引出自己工作的意义（why），接下来一组图表明自己为了实现意义，做了哪些工作（what），最后附上实验方法（how）。在写文章阶段，优秀的科研工作者（当然我不是）会花甚至一半的精力来写introduction，为的就是说服编辑同时说服自己。接下来描述的具体工作是有价值的，这是文章发表的基石。
　　大道相通，做事时秉持这套思维，能够极大降低返工的概率，获得更大的收益。
　　“你是想继续卖糖水，还是和我一起改变世界”，这句话为乔布斯为苹果拉来了时任百事可乐公司总裁的斯卡利
　　参加公司实习转正面试时，样式部门负责人问了一个问题：西瓜视频feed流的长视频前贴广告，怎么提高用户点击率？
　　我不假思索地把我认识世界里所有炫酷的样式优化几乎全答上去了，其中包括视频下方广告转化按钮的延时出现、算色和动效。这时候，他问我为什么要做样式优化，我答为了原生化减少用户反感、增加转化入口
　　没等我答完，他追问：实现这些的目的的前提是什么？见我没有回答，他继续说：是用户能够看到。长视频的使用场景以横屏全屏播放为主，也就是说我在视频下方位置进行的所有优化，用户都看不到，完全是无用功。
　　现在回头看，这道题是面试官挖的一个坑：给到的需求不一定全是有价值的需求，需要多问几个why，深挖需求背后隐藏的价值。对于这个需求，应该先调研用户横竖屏看长视频的比例、切换至横屏的时机分布，然后评估需求有无必要进行，有必要的话再考虑算色动效这些具体的方法。
　　人是善于自驱的动物，多思考背景、意义，会有更足的动力启程，一定比盲干上算得多。
　　借鉴他山之石
　　实习期的末段的一天下午，在公司内部做AB测试的平台上，看到一个很有意思的问卷调查。征集的是对测试平台的满意度和改进意见，可能考虑到大家在平台都有急活，很可能不耐烦地叉掉问卷，所以问卷被设计成叉选后变成小窗停留在角落，点击后恢复。
　　我心血来潮地想，对于按点击收费的开屏广告而言，这个样式是不是可以借鉴一下？
　　当时小范围调研了一下，大家都有随手叉选开屏广告的习惯，并且相当比例的同事表示有时候进行叉选操作的同时发现广告内容是自己感兴趣，想要再仔细看，不过为时已晚。
　　更往前一步，如果用户有同时浏览不同屏次内容的需求，是不是可以广泛采纳浮窗样式？需求调研一直到实习期结束，回到学校没多久，发现新版微信采用了浮窗了样式，侧面印证了当时的想法并不是天马行空。
　　微信浮窗样式
　　从AB测试平台一个不起眼的问卷调研产生灵感火花，推及浮窗新样式，可见借鉴的力量有多么强大。
　　借鉴并不是一件简单的事，得有敏锐的嗅觉，察觉出有借鉴价值的新事物新现象，深挖背后逻辑，发掘更多可能性。
　　举个例子：微信做了小程序，各家也纷纷布局小程序、快应用。
　　如果深挖一步，就可以看到这个现象的借鉴价值：小程序对于用户的价值之一就是无需下载应用就可以玩起来，也就是坊间说的“先让用户爽了再考虑留存”，反映了用户的“偷懒”心理最好拿来就能玩，don’tmakemethink，中间所有的链路环节，通通不要。
　　思考到这，可以尝试借鉴小程序对用户心理的迎合：在游戏类广告里加入试玩元素，无需跳转下载，先在界面里试玩。用户有良好的体验后，试错成本不复存在，下载概率大大提高，起码对游戏本身有了了解。
　　当然，这对游戏本身的质量和获客成本的预期有比较高的要求。“先玩后下载”和某些头脑灵光的瓜果小贩“甜过初恋，不甜不收钱”是一个路数，对传统贩卖套路是降维打击。
　　坦诚清晰
　　从生活小事说起，前段时间看了《非暴力沟通》，里头提到非暴力沟通模式的四个要素：
　　书中原本的表述是：
　　准确清晰、客观地描述观察结果；
　　对于观察结果的感受；
　　表达抽象的需求价值观；
　　提出具体到可以直接行动的请求。
　　非暴力沟通模式被封为圭臬，从模型要素可以看出，其出发点和落脚点都是再清晰不过的客观事实。这样的沟通模式人们乐于接受，又有着力点去推动建立亲密关系，在职场上表现为工作有的放矢，淘汰无效环节。
　　有趣的是，在现实生活中，经常可以看到暴力沟通的影子：
　　对应上面提到的非暴力沟通模型，女生直接表达感受，模糊表达了“哄我”、“道歉”的抽象需求，却把最重要的第1步和第4步忽略了。这时候，男生往往云里雾里莫名其妙惶惶不可终日，两个人的关系无形间被推远了。
　　这就是一个劲让对方猜的恶果。
　　如果足够坦诚清晰，很多问题并不能称得上是问题，“哦，刚刚微信上找我的女生啊，我以前的同学，问我你的口红色号呢，要不你和她说说？”
　　话说回来，如果女生就是不肯讲原因不肯提具体要求，甚至质疑：你在和我讲道理吗？
　　2333，这道题太难了，远远超出我的能力范围
　　互相揣度的习惯，大抵上来源于我们的传统文化强调的“含蓄”，具体体现为“话不说透”、“点到为止”的生存智慧，连山水画也讲究云遮雾绕的朦胧美，这些文化符号潜移默化地影响了我们为人处事的风格。
　　在企业实习的三个月，最直观的感受是效率就是生命，而含蓄是效率的天敌。化用许嵩的一句歌词，“我们的含蓄是对生命的极大浪费”。为了保证效率，与人处事必须坦诚清晰，有一说一，没一不说。
　　我有一个朋友（滑稽），刚实习的时候，他不习惯在群里疯狂艾特别人，即便是拉的会有人迟到，也是私聊问到哪了、啥时候上线；没听懂不好意思麻烦别人，他自己默默查资料；找程序员下发字段，按照惯例没有标明限定的附加创意，结果新来的打包同学给不支持的附加创意也下发了字段，导致返工总之，时而不坦诚，时而不清晰，时而既不坦诚，又不清晰。
　　经过一段时间历练才明白：同事都很忙，不在群里艾特或者加急一下，可能根本想不起来还有会议；公司尤其是互联网公司大家都很热心，都愿意解答疑惑，多请教能少走不少弯路；把所有细节标注清楚不留死角不仅是对自己负责，也是对同事负责。
　　没有实现不了的请求，只有说不出口的请求；没有所谓的不好意思麻烦别人，只是不希望被别人麻烦的封闭思想在作祟。身处互联网，应该openminded，清晰了当表明诉求，会有事半功倍的奇效。
　　敏捷
　　瞬息万变的时代适者生存，足够敏捷，才能在未来生存。
　　对产品经理而言，掌握“抓准需求快速demo丢进市场搜集反馈迭代更新”的全套能力是生存法宝。不断试错，才能不断成长。
　　信息时代赋予我们许多便利，各领域开源库一应俱全，硬件软件工具用遍得等到下辈子，只要想清楚为什么出发和想要去哪，就可以快速制作出模型；模型哪怕很粗糙，丢给用户和市场去砥砺。
　　“小步快跑”远比“闭门造车”来得好得多。当然，照之前提到的，设计好跑步前进的目的地和路线也至关重要。
　　可能是因为缺乏安全感的原因，人们都喜欢追求大而全，一个具体表现就是乐于收藏整理一大票工具网站的帖子，同时有一大票高赞回答在网罗堆砌所谓干货。
　　收藏了会用吗？
　　要用的时候能找到吗？
　　找到以后会用吗？
　　与其追求出于害怕错过而收藏的那一点安全感，不如学习怎么快速搜索资源，怎么快速上手新事物，需要的时候拿起来用就好了。
　　人应该做工具的主宰，而不是相反。我们这些“普通的大多数”可能根本没办法做到“想起就能拿，拿来就能用，用了就能用好”。那么，不妨把相关领域的帖子的内容快速过一遍，建立一个大致框架。
　　谈到工具想起一桩往事，实习期间旁边的小前辈向我要一个APP数据分析网站，我一股脑把收藏的七麦、极光、艾瑞、易观等10多个网站的帖子发给她，被问到这些网站有什么区别时竟然答不上来。她删繁就简随机挑选了一个，十分钟后生成了一份好看的数据报表，实现了她使用分析工具的目标。当时的感触是：做那么多无用功干嘛，敏捷真好。
　　聚焦是敏捷的表兄弟，过于发散是不可能敏捷的。
　　不管能力几何，精力总是有限的，找准一两个点，钻透了才能感受“大道至简”、一通百通。
　　术：怎么做好产品经理（之我见）
　　数据导向
　　之前提到过，对产品经理数据能力要求越来越高：通过搜集数据和信息，经由逻辑分析得出解决方案，以数据验证方案的有效性，一切基于数据。
　　在公司里，数据会由专门负责的程序员落到hive表，产品经理需要会写sql从表里取数。在W3school网站里摸索半天，sql基本的增删查改语句能过一遍，实际使用难点还是做不同表的join。
　　有了数据之后，就可以做逻辑分析了（说实话这一块我还没怎么接触，以后有机会详细写）。
　　对于程序员小哥负责的数据获取，菜鸟赛季的产品经理最好也能学一些爬虫语句，熟悉数据是怎么来的、怎么存储，大致怎么分析。
　　“别人家”（多语言呼叫中心）炫酷的可视化图（图片来自网络）
　　组织会议
　　1）介绍人员
　　公司越来越普遍地从按部门架构转型为按项目架构，这就导致参与新项目的各方之前并没有实际接触和了解。产品经理在会上先简单介绍项目成员的基本情况，包括所在部门，职能，负责过的相关项目，让大家对彼此有一个初步认识，及早确定会上与不同方讨论的侧重点。
　　2）介绍需求背景
　　用三两句话描述需求背景，然后展开（建议使用讲故事的形式），接着讲述需求的预期收益和具体实施方案。从小处讲起，大家能有更直观的感受。
　　3）头脑风暴，记录
　　头脑风暴是会议的核心环节，直接决定了产出结果质量高低。
　　职能不同的小伙伴，关注点也不尽相同，在讨论时产品经理除了引领发散以外，还要兼顾各方诉求。
　　一般而言，研发会关心需求的实操性、开发链路是否顺畅，比如数据落表格式的一致性；用户型产品经理注重能否带来用户平均停留时长、次留率等用户侧指标的提升；数据分析师则更关心同类需求实验是否正向。预判小伙伴们可能存在的疑问并提前做好功课，也是会前必不可少的工作。
　　另外，会上做好记录。
　　4）确认排期
　　讨论完需求细节后，确定各方排期，保证需求能按照自身的排期走，或者根据各方排期调整需求的排期。如有必要在各方需求池填排期表，也做好记录，防止遗漏。
　　5）会后同步todo
　　开完会并不是万事大吉，为了防止小伙伴们遗忘，及时同步会上确定的todo及时间表，可以尝试使用甘特图，并设好提醒闹钟。
　　甘特图示意（图片来自网络）
　　包装showcase
　　Showcase和平台的关系是：平台用资源为showcase背书，showcase用模板效应为平台赋能。有了好的示例产品，包装起来show给用户或者广告主，能获得口碑或者收益上的回报。
　　对个人而言也是如此，本质上参加面试就是在向企业推销我们“这款产品”，“卖点”的多少、好坏，直接影响面试结果。最直观用来展示“卖点”的就是自己的简历，建议用STAR原则包装项目，附上做过的产品分析报告和个人网页（如果有）二维码，多用具体数据表征成就。
　　设计埋点（以广告埋点为例）
　　埋点构成
　　埋点分类
　　埋点设计步骤
　　确定广告样式和交互：包括素材的类型是图片还是视频，图片的话是大图还是组图，视频的话是横板视频还是竖版视频；样式有哪些更改；附加创意（表单提交、电话拨打、应用下载等），以及它们的触发情况。
　　确定需要的数据及埋点。
　　确定每个埋点的字段和上报格式。
　　五方验收
　　五方指哪五方？
　　客户端QA、广告侧PM、广告侧DA、广告侧QA、客户端RD。
　　具体流程
　　客户端QA：按照埋点文档的每个场景上报埋点；
　　广告测PM：确保功能交互、埋点交互，确保QA验证的埋点场景正确且没有遗漏；
　　广告测DA：确保上报埋点字段正确；
　　广告测QA：确保上报埋点正常落库，并记录五方存在的问题；
　　客户端RD：解决五方验收中出现的问题。
　　一个需求的一生
　　流程补充说明：
　　1）产品需求文档需要包含需求背景、预期收益、需求方案、埋点、实验方案；
　　2）用户侧评审时，需要向用户侧RD讲清楚需求，让他们给出排期；
　　3）找DA确认新增埋点格式；
　　6）根据UI出稿，在平台录入新样式，并报平台产品经理审核；
　　7）case评审由端上QA主持，解决开发测试中存在的所有细节问题，需要PM参加；
　　8）可以订阅发版日历；
　　9）实验邮件发给打包，抄送全组；
　　12）评估实验需要充分理由，严谨归因。一般半个月还负向或者正向不显著的实验，就可以考虑关停；
　　15）扩量、缩量、关停、推全量，均需要回复最初的实验邮件。
　　一点题外话
　　这篇不成熟的帖文，谨作为迟到的暑期实习总结。
　　给看到的各位开了编辑权限：对它有任何不满意的地方，欢迎留言。我们把它当成一款产品，一起迭代更新。