“如果只是翻译业务需求，那产品经理的价值何在？”
几乎每一个机构业务产品经理都曾面对这一灵魂拷问。提问者可能是公司老板，可能是产品部门领导，更多时候是产品经理自己。
与C端产品经理不同，机构业务类产品的需求大多来自业务部门，客户侧的需求也多是经业务部门反馈至产品经理。
产品经理的工作当然不只是“翻译业务需求”这么简单，但这不是今天的讨论重点。我担忧的是，不少产品经理遭受上述质疑后为了证明自身价值，结果矫枉过正，反倒落入了陷阱。
陷阱一：砍需求
每个产品经理都砍过业务需求，或因需求太过宏大不切实际，或因工期紧必须精简，或因业务有不确定性，逐步迭代更为合理，等等。
砍需求很正常，怕的是养成了拼多多性格，拿到需求，大手一挥，先砍一刀再说。更有甚者，以砍掉多少业务需求为业绩，言必称MVP，实则谬以千里。产品岗设在技术部门时，这种现象尤其多见。
产品经理一定要考虑性价比，但性价比最高的方案不一定就是开发量最小的方案。这里的性价比，要站在公司角度来看，而不是站在开发角度来看，应着眼于产品的中长期运行，而不能仅盯着眼前的版本。
砍价一时爽，当时把某个功能做到了最低底线，看似是节省了开发人力，但业务或客户用着非常别扭，接下来必定会要求优化，最终经过两三次挤牙膏式的优化才勉强满足了业务要求，总体来看实际是增加了开发和测试工作量。更何况这个过程势必导致用户用着痛苦，开发返工不开心，部门间摩擦增加，实在得不偿失。
我曾见过一个案例，业务方设计了A模式，产品经理以某处技术实现难度大为由，砍掉了一些功能。但这导致部分业务无法开展，业务方不得已又设计了B模式，绕过产品经理此前提出的技术难点。运行一段时间之后，业务方运营遇到若干难题，客户抱怨连连，技术部门梳理架构后认为AB并行不合理且不必要，最终下线B模式，重新优化A模式。前后花了一年时间，折腾了业务人员，折腾了客户，回看当初节省下来的人天数，期间浪费的开发和测试工作量又何止十倍。
如果一个功能做到80分和95分都能符合使用方需求，但是做到95分需要两倍的人力或时间，这时可以视情况商量着做成80分的。但是如果做到60分和80分只差一两个人天，那肯定是做到80分更合算。
陷阱二：改需求
产品经理接到业务需求，是一定要做分析和转化的。
一则业务方提需求往往站在业务管理角度，容易忽略客户视角，产品经理要适当补全和矫正。
二则人都喜欢形象化思维，业务人员提需求时常常会直接描述功能和页面。但毕竟术业有专攻，这些描述有时并非最佳方案，有时甚至会掩盖掉真实的业务诉求，造成误解，走了弯路。此时产品经理要能敏锐把握需求实质，再据此来做产品设计。
三则业务需求也并不一定总是真实和诚实的。比如市场人员有时会出于自身利益或一些不便言明的小动机，要求实现某项功能，理由可能冠冕堂皇，细究下去却可能不合理甚至不合规。再比如两个业务部门为责任、利益或控制权争执不下，最后往往会诉诸系统，由此形成的需求常常是治标不治本。
遇到这些情况，产品经理对需求做出补充、修改乃至拒绝都合情合理。
但凡事就怕过度。有的产品经理，尤其是习惯了做C端的产品经理，很难适应自己的产品被业务方框定，一旦形成抵触心理，回回改、处处改，就要坏事。
有的产品经理觉得按业务需求做出来的产品太过普通，体现不出自己的匠心，偏好有“设计感”的功能。甚至有时走火入魔，认为用户一眼看不出为什么的设计，才是高明的设计。喂，这说明你的设计有问题好吧！
希望每一个产品经理都能早日看清并接受，机构业务产品90%的功能都是普通的、平实的、素颜的。别忘了，机构业务是要赚钱的，用来赚钱的东西都是朴素的，只有让你花钱的东西才会美轮美奂。
平心而论，业务人员是最了解业务与客户诉求的人，除去前文所述几种情况，多数时候业务需求还是清晰准确的，强行修改，反倒画蛇添足，甚至有时把老虎改成了三脚猫。
陷阱三：造需求
如果说砍需求和改需求只需注意不要过度，那么造需求则应一概避免。
大家对IT产品经理岗位的认知，基本是从几个互联网大厂那里得来的，产品经理主导产品的理念深入人心。
然而与大厂主做的C端产品不同，机构类产品业务知识精深，专业性强，用户也都是“职业化的人”（参见我此前的文章《什么是真正的B2B思维》）。而产品经理一般不会多年只做某一项业务的产品，加之无法实际参与业务运行过程，因此很难在专业知识和经验上超越业务人员。
在这种情况下，产品经理要想主导产品，既不可能，也不应该。
更何况，目前机构类产品多由相应业务机构自行研发，因其承载的业务规模巨大，往往是企业中的重点项目、战略项目，很多时候产品的发展方向、业务模式乃至重点功能都是领导亲自拍板，连业务部门都控制不了，产品经理又如何主导？
不要自己去创造需求。当然，这里指的是不要闭门造车或盲目借鉴，生搬一套业务流程，生造一种业务模式。对业务需求做必要的补充和优化不在此列。
我曾多次对同事讲过，放下“主导产品”的执念，多听，多看，最终把事情做成、做好才是最重要的，其他都可以妥协。
诚然，老板功能很多是无用的，业务部门选择的方向也有出错的时候，客户提出的不少是伪需求。但需求仍应来源于业务和客户（是的，不该出自老板，但老板的需求你必须要接）。至少目前为止，我见过的由产品部门或技术部门自主创造需求的机构类产品，还没有成功的案例。
产品经理造需求，最容易忽略的是灰犀牛类的风险和问题，比如监管政策、合规问题、信用风险、成本问题、市场推广难度、客户的普遍顾虑，等等。不参与业务运行，不跑市场，不背业绩指标，自然就容易忽略可行性、实操性。
这样讲，不是贬低产品经理的作用，也不是指责产品经理脱离业务，而是强调术业有专攻。
让专业的人做专业的事，业务人员做业务，产品经理做产品，互相配合，主动了解，提出建议，但不越俎代庖，方是成功之道。
