最近有一位产品经理朋友跟我抱怨，产品设计方案经常受到开发人员的干扰，需求推进不下去，搞得自己压力很大。今天说一下我的个人体会。
其实在数据类、开发工具类的 B 端产品中，产品经理属于“弱势群体”。主要有以下几个原因：
1. 业务门槛
B 端技术型产品业务门槛确实很高，比如数据处理加工类产品。数据本身就是比较抽象的产品，单是理解 API、库表、数据结构、计算模型、数据库存储等专业名词就非常费劲了。
每种类型还有不同的处理逻辑，再加上一些安全、清洗等业务，或者数据领域独有的客户场景，让产品本身就变得很复杂。这对于非技术出身的产品经理来说，有比较高的学习门槛，尤其是开始阶段，需要投入大量的精力自我学习。
具备了业务知识只是第一步，产品不只是对技术能力的“翻译”，而是需要与用户和场景结合。B 端产品经理接触到实际用户并不容易，有些需求确实是产品经理根据竞品、业务逻辑想象出来的需求。在设计过程中，多多少少会有遗漏和偏差。实际落地时，可能会经不起各方的推敲，遇到问题也正常。需要不断地总结、学习，逐渐弥补不足。
2. 需求五花八门
虽说产品经理是产品的负责人，我的实际感受是“产品经理只是需求实现的负责人”。产品需求并非都是产品经理提出的，很多是被动接收的。
有些需求是自上而下的，上层可能根本不知道现实系统是什么情况，只是基于自己的视角对产品的“要求”，这跟产品需求和用户需求还有很大的差距。但是到了产品经理手里就人为地变成了产品需求，执行落地时就会存在这样那样的问题。
有些需求来自不同的团队，层层传递后给到了产品经理，每次转发时都夹杂了个人的理解，可能早已失真了。有的需求虽然讨论确定了，但是在不同关键人角色眼中有不同的理解方式。在 A 看来需求必须要做，在 B 看来这完全是个伪需求。
这些都是需求管理问题，产品经理没有决策权。如果稀里糊涂执行，过程中会受到质疑，很容易造成各方的不信任感，久而久之产品经理处境会更加艰难。如果对需求细节较真，多方反复求证、协调，会消耗很大的精力，最后可能被夹在其中进退两难。
3. 自下而上的工作模式
正常的产品开发流程都是面向用户的，产品以满足用户需求为目标，技术是实现产品逻辑的手段。
但是有些新型产品，市场并没有形成，没有用户和场景，一切处于摸索阶段。产品需求主要是从功能层面出发，甚至是是从技术实现角度出发，变成了“自下而上”的逆向逻辑，底层的技术实现反而成为了核心。产品经理只能在这个框架内执行，最终变成了“产品能力适配技术能力，用户适配产品”的尴尬局面。
这种模式下的产品经理更加弱势，不仅要面对上层的压力，在推进需求时，又会遇到技术侧的压力甚至是阻力。结果就是产品经理夹在中间出力不讨好，里外不是人。
1. 适应环境
每个公司都有自己的文化环境、开发流程。即使规范上一样，在执行过程中可能也会有所差异。不同公司对产品经理要求也不一样，有的需要产品经理有主观能动性、有自驱力、需要体现个人价值；有的则要求产品经理有执行力、行动力，能够将需求落地。
个人需要努力适应公司文化，否则工作会极其痛苦、压抑。当你接纳适应了公司文化，才能找正确的工作方法。
2. 自我提升
其实纯粹的业务门槛比较好解决，通过经验积累、业务学习、竞品分析等常规方法，可以快速提升自己的业务知识。让自己尽快变得专业起来，能够跟各方面的同事在一个频道上交流。
产品经理本身对能力要求就比较广泛，既要能够对接需求，又要能够对接技术。不要只是局限在自己负责的业务领域，适当的了解和外延自己的业务范围对工作也非常有帮助。当自己能力足够强大的时候，有些困难便不再是困难了。
3. 主动向开发人员靠拢
如果你负责的产品偏向技术，这对非技术的产品经理来说始终是短板，很难通过学习补齐，当然我觉得也没有必要去深入的学习开发技术。
有些开发人员有自己想法，对产品设计也比较关注，他们在工作中会负责多个系统，甚至比产品经理更加熟悉全流程的业务逻辑。这对产品经理来说是非常难得的“资源”。我的做法是积极与这类开发人员“共创”，产品经理首先要有自己的需求和想法，有了初步方案后可以找他们做一些需求讨论、评审，弥足产品设计中的不足。让他们参与到产品设计中，也可以让正式的设计评审更加轻松、高效。
以上是我的一些思考。
