本文记录笔者总结的工作原则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条原则也不能随意违反，事情都是从不紧急变成紧急的，问题都是从小问题变成大问题的。
第三十八届CIO班招生
国际CIO认证培训
首席数据官（CDO）认证培训
责编：content
免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。
抢沙发
