為什么說B端設計中，產品經理是“弱勢群體”？

最近有一位產品經理朋友跟我抱怨，產品設計方案經常受到開發人員的干擾，需求推進不下去，搞得自己壓力很大。今天說一下我的個人體會。

更多產品經理的相關思考：

[link http://www.czdes.cn/u/400302/publish/all]

一、B 端產品經理是“弱勢群體”

其實在數據類、開發工具類的 B 端產品中，產品經理屬于“弱勢群體”。主要有以下幾個原因：

1. 業務門檻

B 端技術型產品業務門檻確實很高，比如數據處理加工類產品。數據本身就是比較抽象的產品，單是理解 API、庫表、數據結構、計算模型、數據庫存儲等專業名詞就非常費勁了。

每種類型還有不同的處理邏輯，再加上一些安全、清洗等業務，或者數據領域獨有的客戶場景，讓產品本身就變得很復雜。這對于非技術出身的產品經理來說，有比較高的學習門檻，尤其是開始階段，需要投入大量的精力自我學習。

具備了業務知識只是第一步，產品不只是對技術能力的“翻譯”，而是需要與用戶和場景結合。B 端產品經理接觸到實際用戶并不容易，有些需求確實是產品經理根據競品、業務邏輯想象出來的需求。在設計過程中，多多少少會有遺漏和偏差。實際落地時，可能會經不起各方的推敲，遇到問題也正常。需要不斷地總結、學習，逐漸彌補不足。

2. 需求五花八門

雖說產品經理是產品的負責人，我的實際感受是“產品經理只是需求實現的負責人”。產品需求并非都是產品經理提出的，很多是被動接收的。

有些需求是自上而下的，上層可能根本不知道現實系統是什么情況，只是基于自己的視角對產品的“要求”，這跟產品需求和用戶需求還有很大的差距。但是到了產品經理手里就人為地變成了產品需求，執行落地時就會存在這樣那樣的問題。

有些需求來自不同的團隊，層層傳遞后給到了產品經理，每次轉發時都夾雜了個人的理解，可能早已失真了。有的需求雖然討論確定了，但是在不同關鍵人角色眼中有不同的理解方式。在 A 看來需求必須要做，在 B 看來這完全是個偽需求。

這些都是需求管理問題，產品經理沒有決策權。如果稀里糊涂執行，過程中會受到質疑，很容易造成各方的不信任感，久而久之產品經理處境會更加艱難。如果對需求細節較真，多方反復求證、協調，會消耗很大的精力，最后可能被夾在其中進退兩難。

3. 自下而上的工作模式

正常的產品開發流程都是面向用戶的，產品以滿足用戶需求為目標，技術是實現產品邏輯的手段。

但是有些新型產品，市場并沒有形成，沒有用戶和場景，一切處于摸索階段。產品需求主要是從功能層面出發，甚至是是從技術實現角度出發，變成了“自下而上”的逆向邏輯，底層的技術實現反而成為了核心。產品經理只能在這個框架內執行，最終變成了“產品能力適配技術能力，用戶適配產品”的尷尬局面。

這種模式下的產品經理更加弱勢，不僅要面對上層的壓力，在推進需求時，又會遇到技術側的壓力甚至是阻力。結果就是產品經理夾在中間出力不討好，里外不是人。

二、如何解決這些問題

1. 適應環境

每個公司都有自己的文化環境、開發流程。即使規范上一樣，在執行過程中可能也會有所差異。不同公司對產品經理要求也不一樣，有的需要產品經理有主觀能動性、有自驅力、需要體現個人價值；有的則要求產品經理有執行力、行動力，能夠將需求落地。

個人需要努力適應公司文化，否則工作會極其痛苦、壓抑。當你接納適應了公司文化，才能找正確的工作方法。

2. 自我提升

其實純粹的業務門檻比較好解決，通過經驗積累、業務學習、競品分析等常規方法，可以快速提升自己的業務知識。讓自己盡快變得專業起來，能夠跟各方面的同事在一個頻道上交流。

產品經理本身對能力要求就比較廣泛，既要能夠對接需求，又要能夠對接技術。不要只是局限在自己負責的業務領域，適當的了解和外延自己的業務范圍對工作也非常有幫助。當自己能力足夠強大的時候，有些困難便不再是困難了。

3. 主動向開發人員靠攏

如果你負責的產品偏向技術，這對非技術的產品經理來說始終是短板，很難通過學習補齊，當然我覺得也沒有必要去深入的學習開發技術。

有些開發人員有自己想法，對產品設計也比較關注，他們在工作中會負責多個系統，甚至比產品經理更加熟悉全流程的業務邏輯。這對產品經理來說是非常難得的“資源”。我的做法是積極與這類開發人員“共創”，產品經理首先要有自己的需求和想法，有了初步方案后可以找他們做一些需求討論、評審，彌足產品設計中的不足。讓他們參與到產品設計中，也可以讓正式的設計評審更加輕松、高效。

以上是我的一些思考。

歡迎關注作者微信公眾號：「子牧UXD」