秩序从混乱中产生了出来。——弥尔顿

本文记录笔者总结的工作原则27则，涵盖了一个业务/需求从评估，到立项、策划设计、沟通协作，直到完成的整个流程，每天进入工作前默读两遍，用以警示自己，希望对你有启发。

评估

最重要的是信息。

01

产品经理：咦？我感觉B活动更适合下周的新年活动啊。

运营：A活动要明显优于B活动，你看昨天我们做了A活动，参与用户比B活动的人数多了2倍！

真相——昨天是圣诞节，活跃用户数量达到20万，是平时的5倍，而B活动是2个月前日活2万的时候做的。A活动的参与率只有B活动的20%。

原则：不要轻易相信，要收集更多信息再做判断

对于产品经理来说，做判断是要比做原型、写文档、跟项目都要重要的事情，而做出好的判断的必要前提是：要掌握足够充分的信息。

02

需求方：我们的超市今年又再创佳绩！但是无人便利店恐怕会在未来威胁到我们。

产品经理：呵呵，防盗怎么办？无人便利店绝对开不起来！

真相——亚马逊、阿里巴巴还有国内的数十家无人便利店企业拔地而起，发展迅猛。

原则：接纳未知，不轻言否定

作为一个有着常识，基本逻辑的人，面对那些跳脱常识的观点，不免第一反应就是“不可能”。然而世事如风云，变幻莫测，不可能在以以往想象不到的速度变成现实。

03

产品经理：我们新推出的功能您觉得怎么样，是不是解决了您的问题？好用吗？

用户：嗯嗯。

真相——用户数据完全没有上涨，很快竞争对手推出了另一种解决方案，大受欢迎。

原则：做一个冷眼看客

观察，应该尽量不要影响到事物原本的样子，如果带这主观情绪去询问用户，那么用户很可能会迎合你的情绪；如果亲身跟进到流程中去，那么流程中的人和事可能会发生变形。

04

用户：我觉得你们这个特别不好用，因为我经常……

产品经理：嗯，我们现在做了优化，在新版本里我们做了A,B,C,D…

用户：可是我还是觉得不好用啊！

产品经理：怎么会呢？那一定是您不会用，我来教您……

真相——用户之所以认为不好用，其实他是想实现另外一个类似的需求，而现在的解决方案并没有注意到那个新需求。

原则：倾听

记住，在现阶段，你的目的是了解用户的需求，而不是去解决某个用户的问题，更不要急迫地想要让用户爱上你的产品。

05

客户：新版本没有满足我的需求！

产品经理：怎么会呢，我可是按照需求评审会上你的要求做的！

真相——当初客户举例说要在线协调100人，产品经理就真的做成了最大100人的网络，可是客户实际上偶尔也会有协调好几千人的需求。

原则：多想，多问

在需求没有得到最终认可之前，每一个细节都有可能隐藏着陷阱和机遇，因此你需要事事留意，多想多问，不要把它当成一件苦差，因为它完全可以升华意义。

立项

精益求精。

06

老板：我发现有很多客户对海外品牌很有兴趣，而那些做代购的良莠不齐，正是我们的好机会！

产品经理：是的呢。

真相——海外建仓，加关税，还要另外搭建新的供应链、库存管理、客服系统导致实现周期极长，而且利润率大大低于代购。

原则：做投入产出分析

信息足够丰富的情况下，经验丰富的产品经理，应该能够对业务实现的投入产出进行大致判断，如果做的仅仅是一件“65+50=70”的事情，那么就应该好好考虑了。

07

运营：你不能因为你不喜欢，就不做这个功能，这对公司来说非常重要。

产品经理：好吧，但是我真的不喜欢这种做法。

真相——产品经理曾经看过类似的失败案例，但是已经不记得了，只是潜意识在让他抗拒这个做法，最终该功能也因为上线后出现了一些用户的不满，因此被产品经理当做借口下掉了。

原则：不做让自己不高兴的事

所有的理性分析，都离不开情感。

我们常说的产品感，就像是救生员的救生直觉，艺术家口中的灵光乍现，其实是平时积累的东西，在潜意识的呈现，如果你经验足够丰富，遇到一件让人极不舒服的事件，那很有可能你是对的。

如果你已经完全理解了原理，还是单纯地不喜欢它，那么将它转交给其他人吧，它有可能会因为你的喜好而被冷落。

08

老板：我觉得微信的会员卡功能很好，我们也有这么多的用户，照抄一个微信的吧！

产品经理：好的，我觉得我们应该在个人中心增加一个入口，采用……

真相——老板做会员卡的目的只是想让用户了解自己的权限，问题在于当前的用户对特权的感知不强，老板认为用户有了会员卡之后就会仔细研究权限。

原则：先考虑能不能不做

当我们接触到一个新的业务/需求时，怎么才能考虑的更清楚呢？如果仅仅是去考虑它如何实现，实现之后带来的好处，那就相当于一开始就为自己准备了一个狭小的套子，最终也往往是狭隘的。

考虑不做，能够让自己的思考范围从“做”的极端到“不做”的极端，因此思考的可能性就更多。

09

老板：XX直播的形式很好，我们也需要用户更强的互动，我们也能够做直播吧？

开发：是的，我们能够做的。

产品经理：好的，我也就安排。

真相——公司是做共享充电宝的，用户到app上唯一理由是没电了充电，用完即走。

原则：应该做，而不是可以做

其实不仅仅是在需求，因为“可以做”而盲目去做的人随处可见。笔者就因为会做数据分析，会做测试，会写文案，而被老板、同事理直气壮的要求各种打杂。

放大到业务/需求上，做了不应该做但是可以做的事情，不仅事倍功半，甚至可能会带来用户认知的丧失，给产品带来致命打击。

10

运营：我们需要一个第二件半价的营销活动。

产品经理：好的，第一件原价，第二件五折，下周实现。

真相——运营在接下来的日子里又提出了第二件6折、买二送一、满100减10等等活动，产品开发每次都临时开发，运营、开发相互抱怨，苦不堪言。

原则：解决一类事，而不是一件事

很多人在去解决一件事的时候，真的就是在解决这么一件事，下一次哪怕只有少许改动，他们也会从头开始再来一遍，更可悲的是，自始至终他们都没有发现这些事情很类似，如果把这类事的原理告知他们，他们也能够想到解决方案，可惜他们就是不能发现。

这其实就要求产品经理具有较强的抽象分析能力，能够理解到事物的本质，一次性解决类似的事情。如果只是一件，一件的去解决，不仅效率低下，也会让人丧失成就感，终日重复着简单、低效的工作。

策划&设计

不仅仅是解决方案。

11

市场：这个需求对我们来说很重要，希望尽快实现！

产品经理：好的，我们会按照精益思路，先做用户访谈，然后设计MVP，再灰度发布……

市场：？？？听不懂，反正尽快上线就好了！

真相——需求本身的确对用户来说是有用的，但是市场主要是想要有相关的宣传物料给他们做市场拓展，顺便提升下自己的业绩，对于这个功能最终实现的效果如何，市场根本不关心。

原则：了解需求，也了解关键人的诉求

许多时候，业务部门会跟产品开发对立，抱怨产品开发不能体谅他们，而产品开发也振振有词的表示为用户考虑。但或许并不冲突，处理需求的时候也站在需求人的立场，思考“为什么是他提需求？”，“需求满足后对他会有什么好处”，这样我们在处理需求时也能够更好的把握需求的实现顺序。

12

开发：我们的新后台打通了A系统和B系统！

产品经理：那太好了，我们可以将麻烦的X后台迁移到新后台！

真相——麻烦的X后台的主要目的就是为了联系A、B系统，而现在这件事已经被新后台做了，X后台已经没有存在的必要。

原则：牢记目的，反复零秒思考

当我们深入细节，往往会忘记初衷，把注意力集中在一个个细分的点上，甚至问题已经不存在了，我们还醉心于研究解决方案中的细节。

零秒思考，是日本麦肯锡合作人赤羽雄二发明的一种思考方法，它可以让你自由翱翔在自己的思绪，去深入思考问题的方方面面，这是我常用的思考方法，推荐了解。

13

需求方：我要的商务合作的页面做好了吗？

产品经理：嗯，已经加入了排期。不过我想了想，既然做了商务合作，那么对用户也不能吝啬，所以我准备做意见反馈，但是有些简单问题让用户等待实在是体验太差了，所以我研究了一下在线客服系统，还挺好的，可以接入。产品要成长，所以我们要鼓励用户反馈，因此要用积分奖励他，我准备做个积分系统，顺便做个有吸引力的用户等级……

结果——产品经理将这些需求提出来，市场表示他们只需要商务合作，运营表示没资金准备积分奖励，开发表示没时间，客服表示听不懂，老板表示产品经理可以去财务那结下薪水。

原则：保持专注

产品经理常常以脑洞大自傲，但想太多也有可能意味着难以专注，做一个业务/需求，总是患得患失，思绪万千，其实这很有可能是目标不清晰，逻辑混乱的表现。我们要尽量以全局视角观察业务/需求，明确它的目的、职责，保持专注。

14

需求方：用户扫描领取会员卡的需求做好没有，急着用！

产品经理：还不行，H5的图做的没有体现我们的品牌，资料填写的表格不能判断输入的格式，填写完成之后居然不能够直接跳到应用市场下载app……我们要做就要做好。

结果——第二天果然没有上线，需求方到老板面前声泪俱下，老板批评了产品经理和技术团队，技术团队和需求方对产品经理十分不满。而产品经理一再坚持，终于上线了一个华丽的解决方案，但是一段时间之后，用户似乎无动于衷。

原则：完成>完美>完整

本人是精益创业的拥趸，在满足需求的前提下，越简单的实现就越能被我接受。如果一个需求和它的解决方案被用户认可，那么它才值得被完美，被完整，否则只是劳民伤财。

沟通协作

你以为的，不一定是你以为的。

15

需求方：圣诞活动测试完了吗？我们已经在用户群里做了预热，反响强烈。

产品经理：哦，上周我们评估了一下，认为这个活动太老套了，实现起来也挺麻烦的，就取消了。

结果——需求方到老板面前声泪俱下，老板批评了产品经理，最终需求方厚着脸皮去向用户解释，需求方不再相信产品经理。

原则：及时反馈

产品经理往往同时面对很多需求方，很多信息，我们常常刻意或者不自觉的将这些需求方和需求做优先级分类，对于信息的变更，也常常认为理所当然，熟不知对需求方来说，这些需求可能非常重要，反馈晚了，就可能会犯下严重的错误。

16

需求方：你是这个想法啊，可是来到这一步的用户之前就看过这些信息，有必要再看一遍吗？

产品经理：需要的，因为特别重要。

真相——产品经理在需求方表达的同时就意识到了问题，为了维持形象，因此不顾众人反对，坚持上线。后面在用户访谈中，也有用户表达不满，产品经理最终迫于压力改成了自己也认可的方案。

原则：承认错误

许多产品经理认为自己是业务/需求、用户体验方面的专家，听一些“一秒钟变小白”之类的段子，就把其他人都当成小白，不懂装懂，作出一副权威专业的姿态。这样不仅让自己吞下苦果，更会加大自己与用户的距离，变得更加不能理解用户。

17

合作方：你们要求的，做成跟滴滴一样的模式，我们下周技术对接吧。

产品经理：嗯…行吧。

真相——合作是领导牵线的，希望做到跟滴滴一样的接单模式，产品经理意识到接单模式其实不止一种，但是领导都谈好了，总是没错的吧，而且都准备对接了，现在才来问这种问题，岂不是让人看轻自己？还是算了吧。结果，合作方理解的一样的模式果然是跟产品经理理解的不一样，甚至跟领导理解的也不一样，对接了1个半月的合作来这么浑浑噩噩的结束了，合作方将公司列入了黑名单。

原则：充分表达

不要过分高估了其他人，也不要让不好意思害了自己，把自己踩在脚底下才能更接地气。有疑问就提，有想法就表达，这样能够换取更多未知的信息，对于产品工作，它的作用比你想象中更大。

18

需求方：我有一个想法，为什么不能做一个定时的引导呢，如果用户停住5秒钟不操作，就弹出提示？

产品经理：这样做会吓到用户的，属于预期之外的事情，还是我这种在页面中增加提示按钮的做法合理。

真相——产品经理意识到那个做法是更好的，但是怎么能让需求方占了上风呢？小小提示无关紧要，这可关系到脸面呢。产品经理坚持的解决方案上线了，但是用户还是一直投诉不知道怎么用，产品经理很后悔。

原则：采纳最好的想法

虽然并非人人都是产品经理，但每个人都有解决方案的能力，采纳最好的想法，不仅会让产品更好，也能够让其他人投入到产品设计中，从而更加认可你的工作。

19

产品经理：什么情况？这么多BUG，主流程都没有实现？不是让你们好好测吗？

开发：是好好测了呀，测不出来也没办法嘛。

真相——产品经理并没有给出明确的标准，直说“好好测”，开发只是随便点了几下，并没有用心思考。产品经理对开发更不信任了。

原则：一定要有标准

人是感性的动物，绝大多数时候大脑都会选择最节省能量的方式——感觉，去应对问题。所以我们常常会用“我觉得”、“大多数都是”、“可能”、“用心”这种不明确的词语，但当我们去推进事件时，不能够给出明确的标准，会让被推动方感到无从下手，甚至钻空子。而有了明确的，可量化的标准，不仅有助于事件的推动，也能够让我们更有掌控力。

20

开发：我这已经有很多需求了，时间不多，你这个需求有要求吗？

产品经理：这个需求非常紧急、重要，你们越快越好啊。

真相——开发将需求逐一加入了日程，对这个“越快越好”的需求，由于没有deadline，被开发扔到了一个叫做“零散需求”的地方，直到很久以后产品经理火冒三丈地过来质问。

原则：一定要有deadline

跟需求方呆久了，就会发现对于他们来说，绝大多数需求都是“重要”又“紧急”的，而且要求都是尽快完成。对于这种情况，我向来是不置可否，要求他们给出一个准确的时间。

而自己作为需求方时，为承接方设定明确的deadline，能够避免我们对于项目进展的失控。

21

产品经理A：我们这次做的会员体系，跟用户的个人中心关系比较大，这是我的方案。

产品经理B：你这个改法有点问题，优惠券不应该弱于会员，毕竟优惠券一直是我们的核心。

产品经理C：我正在做个人中心的优化，改动比较大，你们说的我可都不知道啊，不准改。

结果——产品经理A、B直接对开发团队发起了需求变更，开发一片混乱，好不容易达成一致，产品经理C的改版方案获得了通过，之前所做的工作将全部被推翻。

原则：责任分明

工作中，职责不明确的事情屡见不鲜，有些人因为自己熟悉某些工作就指手画脚，而公司内部还乐在其中，以为这是“开放的全民参与”。这样会带来信息的过载，影响到许多人的判断，更会丧失其他人对于产品经理的认知。

22

产品经理：怎么跟阿里奶奶的技术对接还没完成，市场那边就已经向客户推广了？

开发：我怎么知道，我们还以为是你安排的呢！

真相——产品经理将工作安排给开发后，就撒手不管了，而需求方向市场直接下达了任务，最终公司不得不向已经签约的用户致歉，并作出补偿。

原则：跟进到底，确保始终有第一负责人

许多产品经理把自己定义成一个接需求，做方案，推开发的内部产品开发的管理者，对于相关的合作、市场、运营的工作不闻不问，甚至抗拒，而其他人对产品经理的定义理解不清，就会很容易第一负责人的丧失，导致项目失控。如果产品经理并不想做主要负责人，或者在某些工作环节与多人对接时，确保有责任人，并确保大家都知道他是责任人。

23

开发：又是XX提的需求？前两次都是没搞清楚情况就火急火燎的来提需求，这次你调研了没？

产品经理：前两次我都跟他讲明白了，相信他这次不会继续犯错了。

结果——需求人这次依然在犯错，而且出现的问题比之前更大，他也不以为意，让产品经理去收拾烂摊子了。

原则：不要相信一个犯错两次的人

同样的错误，如果两次发生在同一个人身上，那么我会认为这个人是不用心的，不靠谱的，以后需要谨慎防范的，甚至使用一些可以规范他思维的方式，比如需求提出文档、交互检查清单等，去帮助他发现自己的错误。（仅代表个人观点）

24

设计：这种交互虽然还很新潮，但是在欧美年轻人那里已经很受欢迎了，我们也尝试尝试嘛~

产品经理：看在你这么热情的份上，就这么做吧。

结果——新版本上线之后，用户并不接受，吐槽“越改越差”，迫于压力，产品经理又将其改回了老版本的样子，设计师反而也瞧不起产品经理了。

原则：只做事，不做人

当遇到想法不一致时，很多人不仅考虑事情，还受到人情事故的影响，生怕惹他人不高兴。产品经理作为各方的枢纽，这种事情就更多了，我们的确是要站在其他人的立场考虑，但不应该因为照顾某些人而去做不对的事情，坚持自己的立场，只做事，不做人，或许事情也没你想象中严重。

25

产品经理：我故意做成这种简单的原型，就是想让你们设计师好好发挥想象力与审美能力。

设计师：该你想的你不想，还让我来帮你想，你是产品经理还是我还是啊！我不管，反正你原型什么样我就做成什么样！

真相——设计师以前都是由需求方给出图，然后将其上色，改成高保真，对于交互设计也并没兴趣，认为产品经理应该做出高保真和交互效果。产品经理苦心劝导无果，反而被设计师告到老板那里说“不懂脑子，推卸责任”。

原则：区分对待，赋能与把控

赋能，给一个目的，让执行人自由发挥；把控，明确做法、步骤、目的、时间，让执行人严格执行。自谷歌提出赋能后，国内大大小小公司都提出了各种赋能，我也很喜欢给同事赋能，但事实证明，很多人不理解，不接受，不能承受赋能，把控对他们才是有效的。

观察你的合作伙伴，根据情况赋能与把控，让他们都进入到更舒服的状态。

26

开发：这个功能做的不彻底啊，为什么不一次性开发完？

产品经理：哦，你们一直说时间紧，任务重，所以我故意做简单点，以后有时间了再补充。

真相——一次性开发完并不比现在麻烦多少，开发很高兴对别人说时间紧、任务重，讨厌外行评估他们的工作。

原则：不了解别人的立场，就别自以为是对别人好

作为同理心强的产品经理，我们常常为其他人考虑，做我们认为对他们好的事情，但是其他人似乎并不领情。这是因为“为你好”与“站在你的立场”是不同的，如果不能理解别人的立场，那么千万别自以为是对别人好。

最后谨记

27

开发：这里漏了一个逻辑，如果用户是先买东西后取消订单，这个商品会对他15分钟内不可见！

产品经理：还好，用户都取消了就不太可能再买了，还是上线重要！

真相——这是电商购物的一个很正常的现象，出现的概率还是有的。上线之后，投诉电话如潮水般涌来，用户流失率飙升，产品经理不得不跟开发一起，通宵修复BUG，并做用户道歉。

原则：相信墨菲定律，不抱侥幸心理

写这最后一条，其实是用来警示自己，除了做事不要抱有侥幸心理外，对于以上的26条原则也不能随意违反，事情都是从不紧急变成紧急的，问题都是从小问题变成大问题的。

#专栏作家#

朝聆夕改，人人都是产品经理专栏作家。移动应用客户端产品经理，关注移动社交、教育等领域；拒绝空谈的行动派，爱深度研究。

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

题图来自 Unsplash，基于 CC0 协议