to B 的產品經理和 to C 的產品經理有什麼差別？

曾經聽一位朋友提起，面向個人用戶的產品的產品經理，會像一個產品經理。因為你需要去「挖掘」和「創造」需求。而面向企業客戶的產品的產品經理，更多的時候，是在滿足需求。從我自己的理解上，我覺得這種觀點還有點道理。

那麼，作為一個主要面向企業客戶的產品的產品經理，如何體現自己的價值？深度體現在什麼地方?

覃浩，騰訊產品經理

to c產品是發現用戶需求，定義用戶價值，並準確的推動項目組達成這一目標。

to b產品是根據公司戰略或工作需要，構建生態體系，或者推動將流程系統化，提高效率。

說得有點繞，白話就是：

to c產品是你去挖掘用戶需求，是創造，從無到有。

to b產品是公司戰略或相關方給你提出要求，產品經理將這類「線下已有的需求」系統化，達到提高現有流程的效率的目的。也就是出圖紙，推動能力建設，完成甲方需求。從語句之中，你感受到是這類產品一般都是支撐型的平台產品。當然，支撐不等於不牛逼，支撐和業務實際上只是兩種不同的價值體現，就像媽媽和太太，你說誰更重要?

to c產品對產品經理的最大要求是：

很好的用戶嗅覺，能準確提煉用戶真實需求，為產品的市場化方向和用戶利益尋求到一個平衡點。需要有一定的運營基礎，能根據用戶反饋不斷優化產品。

做to c的產品經理一般都樂於分享，經常可以看到他們跟老闆pk，性格不會很悶。他們還會懂那麼一點運營、營銷、品牌策略，並會將其體現在產品形態中。

另外，to c的產品和開發是同一個團隊，目標一般都是一致的，他們朝著同一個產品方向去努力即可。所以你會看到to c產品經理的項目推動力要求沒有to b產品經理的推動力要求那麼高。

to c產品經理還需要擁有很高的交互設計能力和用戶體驗感知，這裡所說的交互設計和體驗感知都必須圍繞公司戰略和產品方向進行展開，to c的初級產品經理最容易犯的錯誤是把太多的時間摳在產品的設計細節上。說具體些，就是把產品的交互設計和UI設計看的太重，幾乎大部分的時間都花在axure原型圖的設計上了，而忽視了產品方向和產品本身應該重點考慮的地方。

在很多產品相關的網站，博客，你會發現討論和分享的絕大多數都是交互和設計相關的內容，這個怪像容易讓初級產品經理陷入泥潭，會造成整體產品整體感覺喪失。

to b產品對產品經理最大的要求是：

to b端的產品經理需要具備優秀的需求梳理能力和推動能力，在大公司尤其明顯。

舉個企業支撐應用的栗子，如果讓你做騰訊遊戲的結算系統，結算涉及到如何獲取支付流水、內部系統化對賬、跟外部供應商系統化自助對賬、出結算單、銀行打款流程等各方面，這些方面中的每一步都有正常流程、異常處理等問題，如果是上市公司，還涉及審計合規，這些流程可能會跨多個部門、多個事業群、以及外部公司。

再舉個構建生態體系的栗子，微信開放平台，因為需要落實騰訊整體開放策略，對於這類開放策略的實施，涉及到整體開放生態的構建，如公眾號生態體系、支付生態體系，這裡面的每一個體系實際上都是一個很大型的系統化產品。這類平台級產品經理除了對策略理解能力提出較高要求，因為底層的介面開放設計需要，他們的部分職位還會對技術理解能力會提出一定的要求，當然不會要求你寫代碼。

你可以看到，to b端產品的需求是服務於公司戰略、或者服務於線下已有的流程，產品經理要做的是理解和實施公司戰略，構建生態系統，或者將已有流程系統化，也就是說需求主要的來源並不是普通用戶。

構建完整生態，或者提升效率，就是to b產品經理的價值所在。你的某個推動，會改變行業，如微信公眾號的產品經理，提出的商家管理生態，就為線下商家提供了完整的互聯網化轉型解決方案。或者，如果沒機會接觸這麼巨量用戶的平台，對於企業內部的支撐產品，你做的財務對賬系統化，就能釋放財務、出納的xx人人力，提升效率就是你的成就。

如果沒有很強大的需求梳理能力，很難將這類流程和邏輯梳理出來，任何一個地方出現遺漏或差錯，都會面臨高層老闆、合作部門、或外部公司的挑戰，甚至面臨合作公司的起訴風險。

同時，因為這類功能一般都會牽扯到跨部門、跨事業群團隊的合作，他們的目標一定不一致，如果沒有很優秀的推動能力，是不可能推動公司那麼多部門協同為你構建你的目標而努力的，優秀的to b端產品經理渾身會散發出逼人的領導力。

所以，你可以看到to b端產品的最大要求是公司戰略或需求理解能力和推動能力。這類產品並不側重運營，所以你看到，to b的產品經理運營能力是缺失的。

做這類to b產品的產品經理一般都擁有慎密的邏輯思維，他們的性格相比to c產品經理也稍顯沉悶，他們大多數理性過頭。他們能夠很耐心的坐下來理解公司或合作部門提出的要求，其實他們同時擔任任著產品經理和需求分析師的角色，優秀的to b產品經理如果轉型，具備做大公司的IT系統諮詢分析師的能力。

產品目標考核

to c的考核指標相對直接，可以定量分析，如日活躍用戶數、月活躍用戶數、用戶增長率、營收相關指標。這類指標，完成就是完成，差xx%完成就是差xx%完成，沒有二話。

to b端產品因為其產品形態的問題， 在為web端產品團隊制定kpi考核指標的時候，都是圍繞系統建設、效率提升、工作能力進行指標構建。

也就是說，老闆們、業務側等同學都知道，to b的支撐產品線的價值是巨大的，也是不可缺失的，但是，to b的考核指標和to c產品的用戶數、營收指標相比，確實顯得比較模糊，很難精確定量考評。

換直白的話說，就是因為kpi模糊，to b團隊的年終獎就不會像業務部門那樣出現各種因超額完成kpi帶來的天價年終獎。

實際這也是我和我的小夥伴們在工作中的疑惑點，因為缺失目標導向，團隊的工作評估和管理方面確實存在難題。

騰訊某個事業群的總經理曾經提出這樣的建設性考評辦法：在騰訊內部建立IT分包機制，業務方被定義為甲方，to b端建設團隊被定義為乙方。甲方向乙方提出能力構建需求，需按照市場價向乙方支付傭金。於是，對於這類to b產品團隊的考核指標就變成了這樣的內部分成結算，在內部模擬了一套內部盈利分成體系。coo已經將這種方案已經上升到公司級方案了，當然，過程一定是很漫長的。

產品經理必讀文章