本文来自微信公众号“产品班花”，作者:班花，纷传经授权发布。
产品经理：你说说有什么需求，这个需求的业务场景是什么？
业务：吧啦吧啦说了一堆
产品经理：好的，了解了
过了几天，通知业务需求评审
产品经理：吧啦吧啦
业务：等等，这里不对，不是这样……
产品经理：好的，我记一下，继续吧啦吧啦
业务：等等，这里不对，不是这样……
产品经理：不，这里应该要这样，吧啦吧啦
业务：不行，实际业务不是这样……
产品经理：那是你们业务问题，不是我的产品设计问题，吧啦吧啦
业务：你这样解决不了我的问题……
产品经理：先这样上线用，到时候遇到问题再改，吧啦吧啦
然后就是上线了没人用，浪费了时间资源，问题还是没有解决。
你觉得这个产品经理咋样，可能会觉得水，但是你有木有想过自己是不是也经常这样。
01
说不明白
其实，水是很正常的。
这玩意入门门槛极低，不需要会写代码，不需要会画图，不需要理解目标，什么都不需要，好多人连话都说不清楚。
基本上可以把话说清楚就已经是还不错的产品了。
我记得我之前面试了一个产品，大哥是真让我知道这行业的下线有多低。
他还是在某个小公司做了1年半产品，简历看着还不错。
结果那是汪洋大海啊。
他：我弄过app的弹窗/个人中心/xxx/yyy业务。
我：可以具体说说弹窗吗？
他：就是app启动弹窗啊
我：弹得内容是什么？
他：广告啊，还能是啥
我：什么广告？
他：当然是商业广告啊
我：具体机制呢？
他：打开app后广告弹出来，可以关闭。。
我就不想再继续面试下去了。
启动广告存是否可以点击？点击后去哪里？有没有统计？什么时候展现？什么时候不展现？怎么更新？等等都可以详细聊聊啊，这不难啊，基本上做过肯定知道，不知道也会被开发追着问啊。
后来了解到，他就是按照他说的那样提这个需求，开发凭感觉来做，做完了合适就留着，不合适就改了重来。
他们对敏捷开发的理解就是需求随意提，开发随意做，产品和开发自己做测试，不行重新来。。。
我觉得产品的最低要求
1知道为什么要这个需求
2具体怎么做
3能给别人说清楚
4能做好总结同步给大家
但是根据我实际面试的情况来看，大部分人都不满足这四点。有的自知，有的不自知。
通常有大厂工作经验的好一点，有人带着走过。小厂自己摸索的最苦，当然小厂也有不错的人，相对来说平均情况不如大厂的。。。
02
写不明白
一个好的产品经理的基础就应该能够产出完善且细致的需求文档，能够将需求的背景目的以及改进细节都描述的恰到好处，同时在产品维度上能够提出关键性兜底或兼容方案。
尽可能的将需求改动的重点描述清楚，降低不同角色的理解成本，能够让研发围绕着这一份文档来进行技术设计，这样的文档或许才称得上完善。
但是实际上许多产品的文档并不尽如意。
PRD要么完全沉溺在自己的表达中，让人抓不住重点；要么大篇大论，或苛求一些并不核心的细节点。
一旦遇到这样的需求文档，通常意味着需要永无止境的确认、争论以及成本取舍。最终影响的就是开发流程中负责每个节点的负责人的体验。
可能有些人会觉得产品提出的需求文档就是要跟开发一起讨论才能得出最终的完善版本。我觉得这种观点完全就是产品不负责任的表现，可以根据需求文档来进行更深层次的讨论。
但是前提一定是文档是完善的，是需要产品经理事先站在产品的维度上进行过思考和沉淀。而不是依赖别人来帮忙查漏补缺。
03
需求进行反复变更
这一点相信是让所有参与需求推进的人员都最为恶心的事情。在我眼中，需求变更的程度与产品经理的能力直接挂钩。
很多时候，经常性的需求已然进入开发阶段，甚至是临近开发完成时，产品经理总是阴差阳错的发现了某些功能或改动的不合理性，从而肆意发起需求变更，甚至是需求反复变更。
需求的反复变更不仅影响的是整体需求推进效率，还有可能会导致开发质量降低以及多方协作不对齐的问题。说起来可能只是工作量的问题，但其实影响面十分广泛。
站在开发的视角，我觉得作为一个成熟的产品经理，就应该在开发介入前或者开发前期能够将所有需求点都确认下来，并且能够打通各方都质疑以及资源支持，不该想到一茬是一茬。
我见过很多产品经常受不了别人的质疑，一旦听到有质疑的声音，就会去变更需求以避免争议。这种的行为实在是无力吐槽。
04
缺乏良好的沟通和协作能力
产品经理在产品实现流程中处于承上启下的核心位置，本该是弥补信息不对称的存在，但在高压、快节奏、复杂多变、利益冲突、认知差异的多角色密切协作的环境里，沟通往往演变成日常撕逼。
如果真心想做实事，这样的日常实在是过于巨大的内耗，所以产品经理如果缺乏良好的沟通和协作能力对整个团队来说是灾难性的存在。
因此，产品经理应该：
第一，与开发团队建立良好的沟通渠道，及时沟通产品需求和设计细节，解答开发过程中的疑问，确保团队对产品的理解一致。
第二，产品经理还应该关注团队成员的反馈和意见，鼓励团队成员分享想法和建议，共同推动产品的优化和进步。
第三，如果是SaaS产品的产品经理，还应该与合作伙伴进行沟通，更好地满足客户的需求，共同制定产品的开发计划和推广策略。提供全面且具有竞争力的解决方案，推动产品的成功。
05
不考虑工程成本
「这个做不了」想必绝对是程序员的口头禅之一。
很多时候产品经理找过来，说要实现某个需求时，我们都会礼貌的回复他，这个做不了。
很显然，这并不是我们开发好逸恶劳想要偷懒的行为，而是很多时候，基于工程现状以及技术成本，的确没办法实现某些功能。
所以每当产品提出这样的改动，我们都会很头疼。当我们明确说明的确在技术上实现不了的时候，可能还会引起产品的不满。
很多时候我们都在说，技术是为业务服务的，脱离业务的架构也是没有意义的。
但是事实上很多时候技术的现状就是没办法满足产品的天马行空。所以产品并不是一昧的为达到自己的目的而不考虑技术现状和工程成本。
06
压缩需求排期
一般在大厂，都是遵循所谓「重流程，轻人情」的规则。也就是说，在项目或者需求开发过程中，更多是以流程规则为准，包括研发阶段的各个节点，比如需求评审、技术评审以及开发估时排期等。
项目实际需要的开发时间是通过对工程的现状调研以及实现成本来综合考量的，而不是领导或者产品经理强行给出的开发周期。
当然这只是最理想的情况，大厂之所以内卷这么严重，很大程度还是因为有些职能并不能遵守流程规则。
产品经理可能在节假日来临，或者与竞品赛马时，总是会突破流程规则的限制，疯狂挤压项目或需求的排期。
这就导致本来需要一个月开发量的改动被压缩成两周甚至一周，这造成的结果就是人员的工作压力骤增，开发体验骤降，以及工程项目的逐渐「屎山化」。
盲目追求热点，应对节假日缺乏提前规划，只着重于产品竞争，这些问题都会导致开发流程的形同虚设，造成产品经理为了上需求而肆意妄为。
07
强行堆砌实验变量
对于一个大型的产品而言，往往会采取AB实验的方式来验证新增特性是否满足用户需求。
AB实验本质上就是初中生物化学里学的设置对照组和实验组。然后通过控制变量法来验证某一个改动是否存在收益。
本身用这种方式来验证需求的价值性无可厚非，但是很多时候控制变量会被滥用。
比如想验证一个对用户来说体验最好的按钮颜色，那么在做AB实验时，唯一的变量就是按钮的颜色，然后不同的颜色就可以作为不同的实验组。最终看哪个实验组的数据最好就能够回收结论。
但是颜色数量那么多，该怎么去选取呢？缺乏产品设计经验的产品经理估计可能就会尽可能罗列所有的颜色来验证，而缺乏自己的判断和筛选。
这实际上是一个很常见的问题，产品往往因为自己也摸不清楚用户想要的东西，于是在需求开发中会选择堆砌或者排列组合所有实验变量。
看起来没什么毛病，但是过多的实验组合会导致开发复杂度变高，同时也严重影响业务代码的逻辑和架构。
所以我认为一个好的产品经理应该能够在排列组合的实验变量中有自己出于产品调性和用户理解的判断，筛选出真正值得去实验的变量组合。这样才能净利益最大化。
本文由作者授权纷传发布，建圈子、做付费社群用纷传。
