为什么说B端设计中,产品经理是“弱势群体”?

最近有一位产品经理朋友跟我抱怨,产品设计方案经常受到开发人员的干扰,需求推进不下去,搞得自己压力很大。今天说一下我的个人体会。

更多产品经理的相关思考:

[link https://www.uisdc.com/u/400302/publish/all]

一、B 端产品经理是“弱势群体”

其实在数据类、开发工具类的 B 端产品中,产品经理属于“弱势群体”。主要有以下几个原因:

1. 业务门槛

B 端技术型产品业务门槛确实很高,比如数据处理加工类产品。数据本身就是比较抽象的产品,单是理解 API、库表、数据结构、计算模型、数据库存储等专业名词就非常费劲了。

每种类型还有不同的处理逻辑,再加上一些安全、清洗等业务,或者数据领域独有的客户场景,让产品本身就变得很复杂。这对于非技术出身的产品经理来说,有比较高的学习门槛,尤其是开始阶段,需要投入大量的精力自我学习。

具备了业务知识只是第一步,产品不只是对技术能力的“翻译”,而是需要与用户和场景结合。B 端产品经理接触到实际用户并不容易,有些需求确实是产品经理根据竞品、业务逻辑想象出来的需求。在设计过程中,多多少少会有遗漏和偏差。实际落地时,可能会经不起各方的推敲,遇到问题也正常。需要不断地总结、学习,逐渐弥补不足。

2. 需求五花八门

虽说产品经理是产品的负责人,我的实际感受是“产品经理只是需求实现的负责人”。产品需求并非都是产品经理提出的,很多是被动接收的。

有些需求是自上而下的,上层可能根本不知道现实系统是什么情况,只是基于自己的视角对产品的“要求”,这跟产品需求和用户需求还有很大的差距。但是到了产品经理手里就人为地变成了产品需求,执行落地时就会存在这样那样的问题。

有些需求来自不同的团队,层层传递后给到了产品经理,每次转发时都夹杂了个人的理解,可能早已失真了。有的需求虽然讨论确定了,但是在不同关键人角色眼中有不同的理解方式。在 A 看来需求必须要做,在 B 看来这完全是个伪需求。

这些都是需求管理问题,产品经理没有决策权。如果稀里糊涂执行,过程中会受到质疑,很容易造成各方的不信任感,久而久之产品经理处境会更加艰难。如果对需求细节较真,多方反复求证、协调,会消耗很大的精力,最后可能被夹在其中进退两难。

3. 自下而上的工作模式

正常的产品开发流程都是面向用户的,产品以满足用户需求为目标,技术是实现产品逻辑的手段。

但是有些新型产品,市场并没有形成,没有用户和场景,一切处于摸索阶段。产品需求主要是从功能层面出发,甚至是是从技术实现角度出发,变成了“自下而上”的逆向逻辑,底层的技术实现反而成为了核心。产品经理只能在这个框架内执行,最终变成了“产品能力适配技术能力,用户适配产品”的尴尬局面。

这种模式下的产品经理更加弱势,不仅要面对上层的压力,在推进需求时,又会遇到技术侧的压力甚至是阻力。结果就是产品经理夹在中间出力不讨好,里外不是人。

二、如何解决这些问题

1. 适应环境

每个公司都有自己的文化环境、开发流程。即使规范上一样,在执行过程中可能也会有所差异。不同公司对产品经理要求也不一样,有的需要产品经理有主观能动性、有自驱力、需要体现个人价值;有的则要求产品经理有执行力、行动力,能够将需求落地。

个人需要努力适应公司文化,否则工作会极其痛苦、压抑。当你接纳适应了公司文化,才能找正确的工作方法。

2. 自我提升

其实纯粹的业务门槛比较好解决,通过经验积累、业务学习、竞品分析等常规方法,可以快速提升自己的业务知识。让自己尽快变得专业起来,能够跟各方面的同事在一个频道上交流。

产品经理本身对能力要求就比较广泛,既要能够对接需求,又要能够对接技术。不要只是局限在自己负责的业务领域,适当的了解和外延自己的业务范围对工作也非常有帮助。当自己能力足够强大的时候,有些困难便不再是困难了。

3. 主动向开发人员靠拢

如果你负责的产品偏向技术,这对非技术的产品经理来说始终是短板,很难通过学习补齐,当然我觉得也没有必要去深入的学习开发技术。

有些开发人员有自己想法,对产品设计也比较关注,他们在工作中会负责多个系统,甚至比产品经理更加熟悉全流程的业务逻辑。这对产品经理来说是非常难得的“资源”。我的做法是积极与这类开发人员“共创”,产品经理首先要有自己的需求和想法,有了初步方案后可以找他们做一些需求讨论、评审,弥足产品设计中的不足。让他们参与到产品设计中,也可以让正式的设计评审更加轻松、高效。

以上是我的一些思考。

欢迎关注作者微信公众号:「子牧UXD」

为什么说B端设计中,产品经理是“弱势群体”?

收藏 17
点赞 43

复制本文链接 文章为作者独立观点不代表优设网立场,未经允许不得转载。