一个产品人八年的修炼感悟

编辑导语：本文作者总结了自己3年C端、5年B端产品路的产品修炼感悟，从产品、管理、思维等方面进行了分析，希望能给你带来帮助。

岁月不居，时节如流，不知不觉已走过3年C端、5年B端产品路，从0到1，做成了几款产品，现将我这八年的产品修炼感悟总结出来，与大家交流。

一、产品设计&需求管理

功能上线没有人用怎么办？考虑功能入口是否隐蔽，低频功能入口可以放到高频页面中来提升用户使用率，引用Ant Design联合创始人林外的一句话就是，“让功能找用户”。

比如，在某平台的需求管理子系统中，需求评价功能上线后无人使用，如何优化呢？仅需把需求评价放到平台首页待办中（首页是高频，每日都进），待办有邮件提醒（邮箱更是高频，打工人必用）。

MVP最小可行性产品策略真是太香了，但在乞丐版产品上线后，耐得住寂寞是成功的关键，一开始的用户数据必然不会太好也不要强推，验证产品方向正确后，这时产品经理只需要抓住关键用户，与用户一起打磨产品。

打磨一段时间后，就是大规模推广阶段，这时数据会随着时间的推移呈上升曲线，有用户，就有反馈，这个产品就被打磨的越来越好，产生正向飞轮效应。

在做平台类产品时，一个产品有多个子系统，有时子系统的产品设计人员会局限在自己负责的子系统内部进行设计，不与平台及其他子系统产生关联。

我们拿故障管理功能举例，如果故障发现、故障调度、故障工单、故障处置互为孤岛，那用户需要在这4个子系统中来回跳转，体验极不连贯，产品经理需要有整体的思维，端到端的设计解决方案。

产品设计不要大而全，面面俱到。道理都知道，尤其在外采项目中很难执行，想着采购周期长，后期加需求难。采购项目一期的时候建议小儿精，用户用的好了，自然会提新需求，项目都是渐进明细的，大而全的产品设计必然考虑不周，资源铺不开，后期还需返工。

B端公司内部产品的用户提的需求，不一定是他想要的，需求收集时会邀请相关干系团队，各团队派一名代表提需求，有些代表担心漏提需求未来加需求难，把能想到的需求都提了一遍，有些代表其实没有需求，但是看到别的代表都提了，自己感觉不提亏了，产品经理不是用户的传声筒，用户不能讲清楚需求是常态，产品经理应该识别目标用户，挖掘本质需求，排除伪需求。

在需求评审阶段发现问题，比在测试及交付阶段发现问题，付出的时间和人力成本要小的多。

熟读唐诗三百首，不会作诗也会吟。产品经理需要多看、多体验各种产品，在做产品设计时，会发现自己有了信手拈来的能力。

产品经理需要做好需求后评估，有些用户提的需求上线后没有使用，下次这个用户提的需求，就应该调低优先级。

二、迭代管理&项目管理

迭代时间真是越短越好吗？是不是把迭代周期缩短就能做更多需求了？针对小型项目的的答案是：是的（迭代周期1-2周都行）。《看板实战》一书通过便士（硬币）传递游戏直观的告诉我们，限制在制品（需求）的数量，促进工作快速流动，软件交付的速度更快、数量更多。

但是针对大型复杂项目不适合将迭代时间安排的太短，著名架构师郭东白在《如何组织阶段性的价值交付》一文中写到：“大项目的联调成本很高，交付过于频繁会会打乱研发节奏”，复杂的团队联调和沟通成本高是常态，在做项目计划的时候，这部分的时间成本需要考虑进来的（建议3周及以上最佳）。

世界上最快的速度是匀速运动，研发团队的研发节奏、默契感一旦形成，将收获稳定的产出。

不要小看每日站会的力量，每日花的时间不多，却能让团队成员目标感更强，大家说自己的进度、需要别人配合的、遇到的问题，一起讨论解决，每个人的进度透明，项目进度和风险就可控了。

需求文档和测试数据如果可以一直提前一个迭代完成，就能保证后端资源最大化利用。

一个再厉害的产品经理，遇上能力、执行力低的研发团队，也拿不到好的结果。《人月神话》一书中写到，一次实际项目的测量结果：“最好的和最差的程序员表现在生产率上的差异平均为10：1。”有时候项目能拿到好结果，是整个团队共同努力的结果。不要把团队的成功，当成产品经理自己的成功，空杯心态。

一个再小的需求，并没有我们想象的小，小需求也会涉及到产品、后端、数据开发、测试、部署5个项目成员，项目成员越多沟通成本越高。

少量经验不足程序员在技术评估方案时比较乐观时，这时作为产品经理一定要请他三思，请研发经理再次评估，方案工时需要在一开始评估好，避免后期出现多次反复。

接手一个历史项目，比从0 到1新开发一个项目难的多，梳理和学习历史项目的时间成本需要考虑。

跟软件厂商合作，需要做好教练工作，什么时间做什么事情，完成标准是什么，不要给厂商太多的冗余时间，因为不给厂商压力，厂商的时间就可能会用到其他项目上。

遇到过少量程序员，喜欢用即时通讯软件打字沟通，别人没有回复也不跟进了，可能进度就卡住了。建议如果在自己的项目中，遇到该类程序员，需要在团队内培训大家遇到卡住的问题直接电话呼过去，积极主动。

这是我们的研发诸经理经常给项目成员强调的话：“目标为导向，要先解决阻塞自己的问题，我不管你在干嘛，你给先配合我解决我的问题，如果对方时间上影响到我们的项目或是不配合，需要第一时间上报研发经理、产品经理”。

产品经理需要和运维团队分割好各自的领域，如果用户线上使用问题、BUG都来找产品经理，产品经理还有精力做其他事情吗？方法是交维时配置产品拨测和告警，产品有异常告警派单给运维人员处理。

各种评审，是收集各个领域的意见，完善自己方案的必备过程，人无完人，查漏补缺。

避免变更升级当晚状态频出，需要提前做好变更评审，核对变更前的checklist。管理好自己的上下游，约定好上游变更时，一定要通知我们，我们自己变更时，也会通知下游。

三、思维升级&影响力

产品经理需要处理好整体和局部的关系，面临业务复杂、多团队&多模块的跨领域整合难点，如果是涉及跨域管理的产品经理需要有从整体视角出发，如果是子域的产品经理，切忌不要过度优化，局部利益服从整体利益。

著名供应链管理专家刘宝红在其书《供应链管理：高成本、高库存、重资产的解决方案》中写道：“有些民营企业实现了订单、料号层次的最优，比如成本最低，却以供应商层面的最大优化为代价。供应商层次的大优化总体上可弥补料号、订单层次的不优化，但料号、订单层次的优化很难弥补供应商层次的不优化。没有统一的供应商管理流程，就不可能有一致的、可预见的供应商管理结果”。

尽可能多地参加比赛。2021年，我们团队打造的两个产品获得了公司在岗革新二等奖、公司研发管理最佳实践二等奖、部门内部打榜两个一等奖，比赛获奖可以让团队成员获得自信、奖金和名气的激励，也可调动项目成员的积极性，提升团队凝聚力。

内部工具产品，就是用于效率提升的，为业务带来了什么，效果最好有一些数据化的东西去呈现，比如用户规模、使用情况、使用后的业务指标有没有提升，有没有提升了满意度等。这些指标最好可以做成在线报表，可以节约拉数据人工统计数据的重复工作量。

功能升级后的阶段性培训可以增加与用户的接触次数，也是提升影响力的一种方式。

产品经理如果自身够专业、自律、爱学习，在朋友圈分享自己的心得的同时，顺便刷个脸熟，得到大多数人的好感，会发现自己在协调项目的时候更顺畅。

四、心态管理

别让自己忙到没有时间思考。作家九边在自己的书《向上生长》中给我们介绍了热力学第二定律：“孤立的系统不持续输入能量就是死路一条”。产品经理如果不能从外部输入不一样的能量，那成长速度将是缓慢的。

每个人都有遇到不公平待遇，内心郁闷、自我怀疑的时候，该如何快速走出心魔呢？我们都知道大型比赛的评分，为了保持客观公正，都是要去除一个最高分，去除一个最低分，而这个给我们不公平待遇的人的评价其实就是最低分，应该是无效的，不应该对我们造成伤害。内心一定要强大，自信的人是无敌的！

负能量的人悲观、做什么都提不起劲，自然会一事无成。如何才能改变呢？答案是少想多做。把我什么都做不成的想法，改成先做了再说立即行动！学到新知识，想到了一个好的点子，都会让人心情开心，不要一直想自己无能为力的事情，绕过它，去做能让自己开心的事情。一个正能量的人，会自信发光、身上有花不完的劲。千磨万击还坚劲，任尔东西南北风！

手不释卷，越读书，越发现自己的浅薄，终身学习。华杉、冯唐、俞敏洪、余世维等等都是爱读书的前辈。不能只读技术相关书籍了，需要拓展阅读心理学、社会学、经济学、历史相关的书籍，便于我们能够更好地理解人性、理解这个世界的底层逻辑。

无我，放下以自我为中心，从社会导向来思考，不计回报地做有意义的事情，会让人成就感满满，愿我们出走半生，归来仍是少年！

参考资料：

1、文章《前馈：让功能找到用户》林外：https://mp.weixin.qq.com/s/bJuGQqE-1K4JPLHBwrcYIQ

2、《看板实战》（瑞典）哈马伯格，（瑞典）森顿著. ——北京：人民邮电出版社，2016.1

3、文章《如何组织阶段性的价值交付》郭东白：https://time.geekbang.org/column/article/c8d4806af8578be483719ffbbea40b9e/share?code=MjHN-6SA7Vf8-MyUcubIAkd%2F64BL0w7NCjaiVQg9TYA%3D&source=app_share

4、《人月神话》（美）布鲁克斯著. ——北京：清华大学出版社，2007.9

5、《供应链管理：高成本、高库存、重资产的解决方案》刘宝红著. ——北京：机械工业出版社，2016.4

6、《向上生长》九边著. ——贵阳：贵州人民出版社，2020.6

#专栏作家#

沈子砚，公众号：ziyan-shen，人人都是产品经理专栏作家。用户体验专家、PMP项目管理专业人士，3年C端、5年B端，从0到1，做成了几款产品。

本文原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议