to B 的產品經理和 to C 的產品經理有什麼差別? to B 的產品經理的價值如何體現?

曾經聽一位朋友提起,面向個人用戶的產品的產品經理,會像一個產品經理。因為你需要去「挖掘」和「創造」需求。而面向企業客戶的產品的產品經理,更多的時候,是在滿足需求。從我自己的理解上,我覺得這種觀點還有點道理。
那麼,作為一個主要面向企業客戶的產品的產品經理,如何體現自己的價值?深度體現在什麼地方?


我目前在做的產品是物流(配送)領域的產品,介於 to C 和 to B 之間。可以說下我的理解。

先說 to C 產品。大家都比較熟悉用戶產品,分析的思路都是看市場組成、看競爭對手、看用戶群體,可以說,得用戶者得天下。不管是用戶體驗至上、打價格戰補貼戰,還是講情懷說故事、買廣告做公關,這樣的產品就是想方設法要讓用戶用上、而且讓用戶喜歡上。

對於這樣的 to C 產品,產品經理要做的事情是我們平時都會聊到的:需求分析、功能設計、用戶體驗、迭代推進等等。用這些工作保障產品一直在向讓產品更有價值、用戶更願意埋單的方向進步。

因此,對 to C 產品的產品經理來說,主要能力大概是:

  • 對市場和用戶敏感,懂得做調研、訪談和分析
  • 對需求和場景敏感,可以做好功能設計
  • 熟悉用戶體驗,懂審美
  • 溝通、團隊協作和管理能力
  • 熟悉運營、營銷方面的知識

再說 to B 的產品。to B 的產品有兩種,一是內部產品,比如後台產品、CRM 系統或者 ERP 系統,這是針對公司的需求讓很多工作結構化、信息化以及流程化,而公司未必是做 to B 的產品的;二是公司的商業產品原本就 to B,比如一些外包團隊、提供語音技術解決方案的公司,以及像菜鳥這樣試圖填充某幾項物流環節的公司。

對前者來說,產品經理要關注的是公司的產品,以及公司團隊的整體協作方式。產品的所有價值就是讓團隊的工作更加高效、快捷和方便。比如原本客服團隊都用最笨拙的手工記錄方式處理問題,客服系統可以讓效率提升十倍,這就是價值。比如,原本發布各種版本(正式、灰度、強更、A/B)都要讓工程師去手動完成,後來做一套可視化的後台發布系統,發布由產品或者運營就能完成,這也是價值。

對後者來說,產品經理要關注的則是整個產業鏈的情況、整個 to B 市場的狀況。自己公司的產品在行業內是處於什麼位置?價值產生在什麼地方?威脅最大的會是什麼?說白了也就是 SWOT 的分析。

關注點並不一定只在要讓甲方滿意,他們說什麼就做什麼。還要關注,甲方對自己的態度是如何的。這也是一種潛在的用戶訴求,只不過對方不會明白告訴你。舉個簡單例子,如果有一個專門做 to B 演算法技術的公司,給很多公司提供大數據演算法解決方案,技術好也來錢快。不過,核心的演算法對某些公司來說很敏感,可能甲方用你的產品只是前期人員不足的折中方案,早晚都要自己親自做。這樣就不能高枕無憂,萬一現在對接的甲方都是這種心態呢?就要想其他的出路了。

總之,這樣的產品經理要對付的不是成千上萬、並不那麼具體的用戶群,而是一個個形象具體的甲方。他們的問題都明擺著,需求也明擺著,你不需要做什麼麻煩的用研,也很少要做需求分析。最重要的就是用最好最快的方法把他們的問題解決。

to B 的產品經理,更需要:

  • 關注產業鏈和公司所處行業的位置
  • 能察言觀色,了解甲方、需求方的背後訴求
  • 關注信息化、結構化和流程化,讓產品足夠高效(在我看來,to B 產品就是剝去了華麗外衣的 to C 產品,只關注最實際的價值)
  • 有強大的邏輯分析和描述能力(to B 產品經常有複雜的數據結構和邏輯關係)
  • 要比 to C 的產品經理有更好的項目推進能力(甲方都有 deadline 而用戶沒有)

個人意見。希望能幫到你。


【商業媒體禁止轉載】四個月前我回答過一個類似的問題,今天看到這個問題,忍不住一答,再次和大家討論。

---分割線---

曾經在UC做過2年to c的app,現在在騰訊做to b的產品。

做to c產品的時候,我很瞧不起做to b產品的同學,認為他們不過是做支撐的。
後來,我參與了一個to b平台級產品的完整構建過程,當完成大部分重要功能構建後,公司部門調整,我調整去一個新的to c產品線,工作交接的時候,我突然覺得:

to c產品賣情懷太矯情,整天跟用戶扯細節,千方百計騙用戶充會員買道具,很庸俗的生意人好么。
to b產品才是真男人,構建生態,小改動就會影響行業格局,還動不動就百億級海量支撐。或者,即使沒機會參與生態體系構建,做的是支撐型企業應用,那釋放了多少人力,提高了多少效率呀,沒有企業應用支撐,根本沒法辦公好么。

噢,實際上不管是b還是c,因為經歷過,都是我的深愛。貶低c不過是為了安慰苦逼的b同學罷了好么,做to b的同學,你們的貢獻不比c低,抬起頭來~

轉崗後,我還時常會和小夥伴們回憶,原來我們曾經做的to b產品也那麼牛逼呀,構建了一整套的系統化體系,騰訊手游百億級的業務,都靠我們支撐好么,你們天天酷跑飛機大戰傳聞拿60個月年終獎的,好意思不分我們么。。。

好了,回到正題。

to c和to b端產品價值體現最大的區別:

to c產品是發現用戶需求,定義用戶價值,並準確的推動項目組達成這一目標。
to b產品是根據公司戰略或工作需要,構建生態體系,或者推動將流程系統化,提高效率。

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

從工作特點上來說:

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

很好的用戶嗅覺,能準確提煉用戶真實需求,為產品的市場化方向和用戶利益尋求到一個平衡點。
需要有一定的運營基礎,能根據用戶反饋不斷優化產品。
優秀的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已經將這種方案已經上升到公司級方案了,會在2015年中有所體現,當然,過程一定是很漫長的。

以上,謝謝閱讀。


我覺得這是一個很好的問題,它至少提示了我們2B領域的產品設計和開發中應該特別注意什麼問題。我覺得核心的區別在於這麼幾點:

1)用戶是誰的問題

這是最好理解的差別。2C產品的用戶是非常明確和單一的,就是消費者用戶本身,因此產品經理要考慮滿足的需求也會非常明確,比如導航軟體就是給司機本人用的。而2B產品的用戶是一個更複雜的問題,它即包括了企業員工的終端用戶,也包括了管理決策者,甚至還有一些2B產品會間接地服務企業客戶的顧客(例如客服類產品)。在面對多層次的用戶時,產品經理需要權衡利弊,有時候滿足了決策人未必能夠滿足終端用戶的需求;如果只看重終端用戶,那麼可能削弱了進入企業市場的能力。2B產品幾乎都有2-3個前端用戶層,分別針對終端用戶和管理員。

不同的2B產品,在權衡誰是最核心的用戶時有不同的邏輯。比如我們做的協作品類無論如何會將終端用戶放在比較核心的位置,但是也要考慮在產品結構和管理功能上對決策人的溝通作用。

2)易用性實現的路徑問題

大多數2C產品不存在絕對的易用性問題,至少不涉及任何專業領域,所以大多數易用性問題依靠交互設計本身就能夠完成。2B則不同,一套成熟的HR管理工具必然涉及很多和HR專業工作有關的環節;財務軟體也主要面向的是專業會計人員。在這些專業2B產品中,產品經理必須要掌握的是該領域的專業知識,而且要能夠合理地判斷其中哪些是用戶群具備普遍認知的,哪些是存在一致性挑戰的。軟體產品如何幫助初階用戶快速理解,遇到具體問題,應該如何解決。

2B產品很難用「保持足夠簡潔」這樣概括的目標行事,他們唯一能夠做到的就是建立完善的產品幫助和用戶上手指南。有時候,構築一個功能的使用幫助系統所投入的精力並不亞於開發功能本身。

3)壓力來源的差別

2C產品的需求分析,反饋管理基本可以依靠量化分析或者更多遵從公司的基本戰略。運營者面臨的主要壓力來自競爭者。市場份額會快速反映出產品的競爭力來。2B產品的壓力來源要更加複雜一些,尤其突出的是來自具體的企業客戶。客戶時常會提出具體的產品改進或者新特性需求,但SaaS軟體產品往往又有自己既定的產品路線圖。除了時間和次序上的衝突,有些客戶的需求可能永遠得不到滿足。2C產品的每一個單個用戶創造的單位價值很低,他們並不存在和廠商的議價能力。2B則不同,有時候即使是核心客戶群體中的成員也可能會提出路線圖以外的需求,這時候議價能力決定了2B產品經理所承擔的外部壓力。

這個問題並沒有很好的解決方案。它永遠需要產品經理的選擇決策,除了溝通能力外,還離不開膽識。


廢了好大力氣把2B改成to B....

----------------------------------------------------

@覃浩tommy@秦亞冰 以及其他幾位說的大致贊同,但是有一點我不太認同的是,我從不認為to B的PM做的是「執行」和「實現"的工作。

我一直給團隊的兄弟們說,如果你們只是去實現業務需求,追求的是實現的效率和質量的話,那是沒有前途的,你們永遠只能跟在業務後面,去實現他們的想法,把業務需求」翻譯「成產品需求的話,我不需要找一堆產品經理高級產品經理產品總監,找一堆項目經理就可以了。你們的價值在哪裡?你們的成就感在哪裡?不在實現,而在創造。

to B的PM和DEV都不好找,流失也大,很大程度上都是這個原因。

to B的系統,尤其是支撐類系統,必須要做到走在業務前面,也就是滿足業務線未來的需求,甚至於影響業務的走向,才有價值。to B的PM的發展的一個重要方向,應當是業務架構師/系統架構師。

」這個需求,我們回去研究一下,爭取下周完成「

」這個需求,我們早考慮過了,直接就能支持「

顯然是後者更爽一點。

有時我們還常常調戲業務部門一下

「你們可算想到要做這個業務了」


當然,說著容易做著難。

做to B的產品,執著於」功能實現「是沒有前途的,得看到功能背後是什麼。

要時時刻刻把已經或者將要實現的功能做業務抽象,看看把業務一層層剝離掉之後剩下的骨架是什麼,抽象出業務模型,建立底層的數據模型和業務架構。那些UI上的功能,都只是浮雲。

(前端UE的兄弟們估計正在趕來殺我的路上)

當你逐步建立並且不斷完善了這個骨架之後,你會發現,絕大部分情況下,所謂業務需求,只是這個骨架上一塊兒沒長出來的肉而已。

然後你還會發現,某些業務線/事業部的系統似乎和你的骨架格格不入?ok,你影響業務線的時候到了。


我覺得,要做一個好的to B的PM,除了大家提到的那些外,還得注意幾點

1.要深入到業務中去,了解業務的重要性就不用說了,除了對業務的深入了解之外。即使手頭有要做的工作,也要時常在業務部門附近溜達,聽聽他們說什麼討論什麼,甚至把自己的座位就搬到業務部門旁邊。第一時間了解信息是最重要的。

2.願意干臟活累活,to B的系統往往要和業務系統對接,一到對接,邊界上扯皮的事情就多,尤其那些臟活累活,你干還是我干?你乾的越多,就意味著你的支撐系統向業務系統滲透的越多,業務系統對你的依賴就會越重。

3.絕不啟動單獨的」系統重構「」基礎架構「這樣的需求。系統要不要重構?當然要。基礎架構要不要建設?當然要。但是所有的基礎需求,都是伴隨著解決具體問題去實現的。也就是說,上面提到的那些骨架的實現,得確保每次都得帶著肉一起來。這就需要PM在心裡對這個骨架非常清晰,這樣,當聽到一個業務的想法或者需求或者問題的時候,能敏銳的感覺到在實現這個」功能「的時候,可以搭車實現自己的基礎需求。


至於to B的PM需要的協調能力、推動能力,這些大家都提到,就不多說了。

to B的產品不好做,也不容易做好。但做到了,也是很有快感的。


分別做過to c 和to b的產品,說下自己的理解:

首先無論to b 還是to c,都是面向很多不同的用戶,to b的用戶聚焦在某一行業,為工作、業務需求而來。to c 用戶沒有普遍的共同特點,為個人需求而來。所以既然是面向用戶,那好的產品體驗都是必要的,所以拋開產品體驗、交互美感等等,談談其他的不同。

b更關註:

目標:如何賣出更多的產品

1. 行業趨勢和業務模式

2. 功能壁壘以及和競品功能差異

3. 客戶資源以及售前售後能力

4. 客戶需求的技術實現能力和周期時長

5. 對客戶需求和自身產品邊界的把控

c更關註:

目標:如何獲取更多的用戶

1. 用戶需求深耕和挖掘使用場景

2. 核心功能的競爭力和不可替代性

3. 產品所需資源和內容的獲取

4. 商業化

舉個栗子簡單的說明下:

一款殺毒產品,b和c涉及的一些關注點:

to b:

需求背景:為保護公司信息安全,公司it管理員需要給每個員工的電腦配置殺毒產品,並定期集中殺毒,部分公司需要限制上網時間、訪問網站等。

產品模式:一套後台管理系統可供公司it管理員操作、員工電腦上的殺毒客戶端

售賣模式:後台管理系統單獨定價,殺毒客戶端按量定價,或者打包售賣,售前售後如何收費等等。

產品競爭力:殺毒的技術能力以及企業在行業內的品牌背書

客戶需求權衡:每個客戶的需求不一,a客戶想增加設備定位功能,b客戶想增加設備鎖定功能,那需要評估客戶需求的成本和收益是否值的滿足,又是否合入標準化產品,還是單拉出分支形成定製化產品。

to c:

需求背景:對於安卓手機,殺毒並不是一個高操作頻次的需求,那如何提高用戶使用產品的頻次和時長

產品模式:例如現在比較成熟的360殺毒,也會提供手機管家類的服務,例如垃圾清理、系統瘦身、應用下載等等

盈利模式:廣告、應用分發等等

產品競爭力:殺毒能力、產品功能、產品易用性和交互,例如360在桌面設置的安仔懸浮窗,通過拖動安仔彈跳的力度進行垃圾清理,這個功能就給230殺毒帶來很多用戶。

以上是自己一些淺顯的理解,歡迎討論~~


謝邀。原阿里雲飛天平台初創員工、日誌服務產品經理,在阿里雲歷經開發,測試,項目經理,產品經理。現在與一群志同道合的夥伴在為生命計算,負責GeneDock產品工作。

沒有做過To C的產品經理,前同事有幾個離職後創業做To C產品的,在各自的領域做得有聲有色,有時候會一起聊天,我覺得To B和To C在需求分析、產品設計、UI設計的方法論上並沒有什麼太大區別。

這兩類產品面向的群體都是人,可能B面向的更多是專業人士,C更多的面向普通人,然而所有的產品都不是脫離人的需求臆想出來的。最初,我們開始做某個產品的時候,往往是已經嗅到了市場中、行業中有這樣的需求。在第一版產品出來及產品後期迭代的整個生命周期中,我們會從用戶那裡聽到需求反饋,這個時候需要挖掘用戶真實的訴求是什麼,去理解用戶場景並抽象。在程序員的世界裡,有種不好的coding style叫麵條代碼,在產品經理這裡,如果用戶說什麼你就做什麼,我把他稱為麵條產品。從產品設計上來說,抽象才能使得各類不同場景、複雜場景用簡單的模型來滿足。

從我之前的工作和現在的工作來說說To B產品經理日常做的事情。正如上段說的,當我們開始立項一個新產品的時候,前期已經做了足夠的調研來預估未來這個行業的市場規模和需求。

最初我們會有個產品Demo。接著,找到第一個天使客戶、兩個客戶、三個...當有十幾個客戶時,你會發現Demo不work了,總有這樣那樣的坑,需要人肉去填,同一類型的客戶,場景也並不是完全一樣的。這時候,你需要坐下來,去分析並抽象用戶場景,定義產品模型,寫PRD,找架構師和研發討論,這樣的產品模型下,現有的架構是否能夠滿足,是否需要重構,如果重構是否有盡量不影響用戶的過渡方案,過渡方案是什麼。

首先,大家要在產品模型定義上達成一致,接下來,產品才開始定義介面。介面定義細節很多,例如,這個介面的請求是什麼樣的,有沒有參數,參數的類型如何定義,返回結果是什麼,是什麼格式,各類錯誤信息的定義,然後繼續寫PRD。GeneDock最近剛對外開放了部分API,有興趣的同學可以去官網看一下。

以上都完成後,可以基於API進行SDK、命令行工具、Web的開發,來滿足不同用戶的需求(此處應有PRD)。例如我們有些用戶偏好用圖形化工具來上傳下載數據、在Web上進行生信流程開發和運行;也有一些用戶在實驗階段用本地工具調試,當生產穩定後,希望直接調用API來自動化生產;還有的用戶偏好用命令行工具來寫腳本。

一分鐘變小白,在不同的用戶場景下並不是相同的。例如,如果你的用戶是程序員,介面易用性設計的好,那就夠了;如果你的用戶是科研人員或者醫生,那麼頁面交互設計的友好性則是重要的。To B的產品同樣會去關注用戶交互設計帶給用戶的影響,例如,可以去記錄用戶在Web上使用產品的行為,來思考為什麼用戶在這個操作上卡殼了,沒有再往下操作,怎麼改進來使操作流暢。To B的產品同樣關注UV、PV、轉化率,只是統計方式與To C不一樣。

我曾在知乎看到過一個問題:「產品經理怎麼與團隊建立信任和信服感?」。我的理解是,首先保證自己在這個領域認識是不斷提高的,平時有時間可以多看書,類型不限,能跟不同的人聊天;其次,在與研發溝通的過程中,你不知道的東西一定要問清楚,只有在了解細節的情況下才能做出正確的判斷;第三,產品的閉環盡量自己想清楚,如果你總是讓別人幫你善後,那就沒有然後了;最後,跟志同道合的人做志同道合的事,把合適的人放在合適的位置上 :-)。

在我的認知範圍里,產品經理並沒有To B,To C之分,只有好壞之分。朋友圈裡不少低調資深優秀產品經理,To B和To C的兩個階段同樣優秀。(說實話,回答這個問題感覺有點班門弄斧呢^_^)

GeneDock產品研發團隊的小夥伴們是群很有意思的人,兩個創始人曝光率較高,就不說了。生信團隊的負責人,為了來創業博士不讀了(說起來好多輟學的名人呢^_^)。還有學醫的小夥伴,有醫人的,還有醫動物的,近期又入職了幾個主業碼農、副業說相聲的小朋友。

好吧,我其實主要是來招產品經理的,也歡迎各位投其他崗位。誠摯邀請:https://www.genedock.com/joinus/.

以上。


做過B也做過C
B和C 的PM最顯著的區別是,B的用戶沒有C那麼多。

傑出的產品經理像著名的導演或者編劇,等待一個機會,一炮而紅,到底是市場勝利還是藝術上的成就沒有那麼重要。
合格的產品經理是一個反應迅速的需求分析師,找到用戶的問題。什麼是用戶的問題,不是客戶讓你加了1你就加了一,而是用戶在什麼場景下遇到了什麼樣的問題,為什麼有這樣的操作。提出解決方案,衡量場景出現的價值,然後決定和排序。
合格的產品經理至少有和團隊和老闆溝通的能力,有時候老闆提出的細節,客戶提出的細節,你可以像諮詢師一樣發覺核心問題,然後決定解決問題的路徑(roadmap出來咯)

為什麼B的產品經理沒有C的產品經理容易做,為什麼B的PM一定是客戶說怎麼做就怎麼做?
無法接觸到B的用戶正在使用的情況,只能假設(特別是工業品),如何提高,跟著技術支持銷售等等一線人員接觸一些客戶,或者申請到對方的團隊託管一下。
面對C端客戶,如果來了一大群像豆瓣一樣非常反對改版的用戶,改還是不改,也是個問題吧?

推動的事情越多,努力成為事實上的關鍵人物,title又何妨。


該問題是筆者正在研究實踐的領域,一個不小心就把所有回答全部讀完。

拋開』產品經理』的概念不說,看得出很多回答者的內容都來自於實戰,很有價值。

先謝謝諸君的分享了。但有些概念混淆以及一些本質問題(決策模型)暫無人指出。在此補充,順便體系化梳理下概念,相信能讓想從事To B產品經理的朋友們能有更完整的認識。

(-----------最後更新:2015年5月25日------------)

體系化梳理之後,按下面三個段落回答題主問題:

一. 理清概念(許多回答把面向企業的項目經理與To B的產品經理搞混,而題主想問的是真正意義上的產品經理,而非項目經理)

二. To B與 To C 的本質區別;

三. To B 產品經理的價值(外界認定)的體現;


*******理清概念:何為To B產品經理*******

沒把「為企業做項目系統(Project Manager)」的項目經理與為企業級市場做產品(通用)的產品經理(Product Manager)搞混亂的童鞋們請自覺忽略本段內容。

因為看得出題主問的是To B的產品經理的問題,不少儘管有價值但文不對題的答案看著有點累。


正解:

To B產品經理:為某一類企業客戶進行產品設計的負責人,即產品的最終成果能夠「通用」於此類的企業(們)。


大部分回答提到的是指為企業客戶做個性化系統開發的項目經理,這類PM的價值與技能與產品經理差異還是比較大的。


舉兩個例子設計淘寶的商家平台的負責人是To B 的產品經理,因為平台服務於所有的企業客戶;另外如我司移動辦公口袋助理產品服務的客戶是所有的企業客戶,因而我們的產品負責人也是To B的產品經理(如果沒理解錯,題主想問的是類似我司這種的產品經理吧);


舉個反例:設計中移動BI平台的負責人是項目經理,因為該平台主要是服務中移動內部(哪怕是不同的分子公司,但其屬性均是中移動);


******* To
B與 To C 的本質區別*******

用戶屬性:B的客戶與用戶絕大部分是脫離的,C的用戶與客戶(*這裡的客戶不是指為產品對外服務買單的客戶)是一體的。


由於用戶(客戶)屬性的本質不同引出下面一個暫時為大部分回答者所忽略的關鍵因素——決策模型

決策模型基本上主導了產品的設計、商業模式的設計、市場營銷戰略的構建,因此筆者認為To B 與 To C的本質區別源自於此


決策模型:B 是群體決策模型(*筆者自創詞語,非權威術語,引用請慎重)

, C是個體決策。


為方便理解,此處以口袋助理(面向企業的移動辦公軟體)作為例子:要銷售To B的一個產品,必須客戶(企業主)認為口袋助理有價值(提升公司業績及效益)、此外,還需要用戶用起來爽,一旦用戶體驗不好,內部推動困難,也沒轍。此外,產品的運維管理或者定價也會涉及到更複雜的決策博弈因素,除了老闆、廣大員工、IT主管,財務也會影響到產品的決策,產品不好維護管理,IT主管肯定不樂意,財務超過公司預算,財務這關也過不了。


而To C的決策非常簡單,例如,小紅聽說哈根達斯好吃,就直接買了吃了。她不需要問男朋友這玩意吃了會不會長胖,也不用問老媽這玩意兒有沒有營養,她的錢包她的嘴她自己說了算。

兩者區別附圖:

商業模式方面,TO B 產品無論是免費或者收費,在產品客戶看來,他就是付費客戶。

這跟企業級產品的信息化負責人的心理邏輯相關:習慣了高高在上的甲方角色,外加羊毛出在羊身上,導致了他們不會因為你的產品是免費模式而寬恕理解


一句話總結,To B 的群體決策模型是To B難做的根源(也可參考筆者在另外一個問題的回答:面向企業的互聯網產品有前景嗎? - 李少加的回答),騰訊等公司沒真正意義上發力企業市場不是沒理由的。

其實真正意義上的To B產品的群體決策研究還比較少,目前也是筆者本人深入研究的領域,對此方面有研究的同行歡迎私信與我聯繫。


*******
To B產品經理的價值體現*******

對To B決策模型的深入認識基本上就可以準確答覆題主的這個價值體現問題:

1. 讓你老闆認識到To B市場的複雜,以及相應產品形態的複雜。不然動不動用To C思維考核你,很容易讓你變得一文不值。


2. 梳理你所在行業的產品的決策群體,產品設計的時候充分權衡各個群體的利益、剛需(很多時候決策群體的內部是充滿矛盾的)。


3. 卓越的To B產品經理與卓越的To C產品經理的能力是包含關係,如其他一些回答所言,To
B產品經理除了要具備To C的產品敏銳度、用戶體驗,對於推動企業級商業鏈條、運作、跨界思維、宏觀局勢觀的要求都特別高。但目前業界對To C產品經理的定價整體還是略高於To B

&<繼續加班,有空時再更新……&>

對個人如何加速成長,規避彎路,突破職場瓶頸,也可關注本人的公眾號:少加點班
有問題直接詢問,必回。

(個人轉載請註明出處,商業轉載請聯繫本人)


雖然騰訊產品經理 @覃浩tommy 已經說的很好了 @秦亞冰 寫的也非常好,我這裡還補充一點個人看法。

提問者說TO C才會像一個產品經理。因為你需要去「挖掘」和「創造」需求這我不太認同,我做的TO B的時間比TO C長,認為兩者區別並不在此。

如果說TO B的更多的是滿足需求,我認為TO C跟多的也是滿足需求,兩者是一樣的,只有滿足客戶需求了,你才有精力去「挖掘」和「創造」(創新)需求,客戶基本的需求都未滿足,你就談「挖掘」和「創造」(創新)需求完全是在耍流氓。


你說淘寶在「挖掘」和「創造」需求那也是他滿足了客戶基本需求,你看阿里旺旺07年左右也沒有誰說他不能滿足自己需要,到後來千牛出來體驗比旺旺好上一大截,大家才吐槽阿里旺旺聊天,訂單處理,手機端卡各種問題。就像iphone推出,用戶很多時候並不知道自己要什麼一樣。

B端客戶更多的情況下是企業累積下來的客戶,可能說你老闆或領導會傳達一些更具體的想法給你,意思是穩點,別輕易瞎搞。而C端客戶,企業一般需要你去開發,所以產品的權利很大。

區別:除了大家提的這些區別,我想講一個就是權重區別。你的產品同樣是1000個用戶,你認為1000 C(消費者)客戶,跟1000 B(企業)客戶他們的權重能一樣嗎?

1000個C你可以去大膽去折騰「挖掘」和「創造」,讓更多C客戶購買,即使丟個500損失也不太大。如果是B客戶丟了500,後果怎樣你應該也能想到。

說的好像面向企業客戶的產品的產品經理就不是產品經理了,就容易了,就不用去去「挖掘」和「創造」需求,我認為是及其可笑的。如果按層級來分,這就像做高端品牌法拉利、賓利的產品經理比豐田馬自達產品經理容易一樣。做上一層客戶就不像產品經理了? 你現在是沒接觸上層客戶,如果接觸了你就會明白,上層客戶維護好,保住企業品牌價值有多重要。未來你會知道的,做B端的客戶你要對你B端客戶群了解非常深,甚至要當自己就是其中一個供應商,但你又不能任性的說改就改。

個人經驗「穩」字是做B端的核心。


我看了所有人的回復,很多同學都同時做過ToB和ToC的工作,所以比我更有發言權。

但是,我看到這個問題的第一個困惑是:究竟什麼是ToB,什麼是ToC?

很遺憾看到最後沒有一個人給出答案,大家都想當然的按照自己的主觀判斷去回答,這樣就會發現有些回答之間是矛盾的。

比如有人理解ToB是面向企業提供商業產品,如ERP、CRM等產品,有的人理解是面向企業內部提供企業管理工具,如報銷、考勤等系統,還有人的理解是用戶產品的後台和策略產品,比如搜索、廣告、計費等。

所以不先把這個定義明白了,很多結論都是錯誤的,至少是不全面的。

我斗膽區分一下ToB和ToC:面向普通用戶的、實現個人需求的產品是ToC產品。其他,包括面向企業的、面向團隊的、面向企業內部的、面向其他產品提供服務的,統稱ToB產品

由此得出:
1. 微信、微博的客戶端,都是ToC的產品
2. 用友、金蝶、Salesforce等企業管理軟體,是ToB產品
3. Teambition、Worklite等協同產品,是ToB產品
4. 微信的公眾平台、百度的計費系統、京東的促銷策略,是ToB產品
5. 企業內部管理的考勤、請假、報銷等流程或者系統,是ToB產品

如果不明確這些區分,我們直接得出的結論很有可能是不合適的。比如有些同學說ToB的產品價值不好體現,顯然只是對於企業內部管理的產品和為其他產品服務的產品的價值才不好體現,對於以企業為客戶的產品來說,如用友的暢捷通,其價值通過銷量或者實施項目的金額是很容易衡量的。

----------------分割線-------------------

在這個區分的基礎上,我再來補充一下ToB和ToC的產品經理有什麼區別。

1. 在發現需求的能力方面,兩者都是必須的。

大部分ToC產品經理髮現需求可能根據對人和人性的了解,如上面所說的馬斯洛需求金字塔;而對於不同方向的ToB產品經理,要求會更高一些,比如對於企業管理軟體和企業內部管理產品的產品經理來說,沒有足夠的管理理論基礎,是不可能發現管理上的問題的,也就不可能對流程進行優化;還如一些策略產品經理,如果不是對這個商業模式和競爭對手了如指掌,基本上是手足無措的。

概括說,ToB產品經理首先應該是「業務專家」

2. 對於用戶體驗來說。有些同學說ToB的產品不重視用戶體驗。這只是現象,不是事實。事實是,用戶體驗越來越重要,而且大家都意識到了。

比如Teambition和Worklite的用戶體驗就很不錯。給大家留下用戶體驗不好的印象的更多是我們用的傳統ERP軟體,其實ERP廠商和企業信息化部門也想讓體驗好一些,但是這不是動動嘴皮子就能好起來的。第一,這些項目工期是一個重要的指標,功能都做不完呢,哪有空優化體驗?第二,做ERP的PM大都是從實施顧問轉型的,沒有產品思維,更別提交互、視覺能力了;第三,這類產品功能太過繁多,架構過於複雜,有時候真的是心有餘而力不足。

概括說,懂用戶體驗設計的ToB產品經理才是「稀缺動物」。

3. 相對與ToC產品經理來說,ToB產品經理需要更高的邏輯思維能力。把一件事情有條理的描述出來,已經很不容易了。更難的是,在產品設計中,要考慮到各種異常,不能有任何疏漏。從我做項目的經驗看,再好的產品經理,也遇到過沒考慮到的場景。但是,思維當然越縝密越好。

概括說,ToB產品經理思維要更加縝密。

先說以上幾點吧,想到了再補充。


----------------分割線-------------------

下面說說我認為產品經理應該具備什麼能力:

1. 業務能力:從戰略高度去理解業務;了解業務方向的理論知識;了解業務方向的行業動態
2. 邏輯思維(尤其ToB):考慮儘可能多的場景,設計出盡量周密的方案
3. 溝通能力(尤其ToB):要能和業務方談需求、講方案,要能忽悠團隊成員高質量達成目標
4. 產品能力:找到真正的用戶,找到真正的需求,產品規劃、設計能力,運營也要會一些的
5. 學習能力,我認為是最重要的能力。要在這個變幻莫測的互聯網世界永葆青春,只能不斷學習、快速學習


以上個人愚見,歡迎大家拍磚。


廢話不說,直接乾貨。

To B,做了7年的To B的產品經理。
其實對於To B來說,叫做項目經理更恰當些。因為你面對的是明確的客戶,你主要工作是滿足客戶所提出來的需求,然後制定計劃安排人員開發,後續的培訓和推廣使用。
說白了,你更多就是個執行者,因為項目周期都是固定的,需求是客戶提的,你是不太可能自己給自己找事,非要把客戶的需求完善創新的(這麼做的多半都沒好下場,因為優化工作是無窮無盡的)。

To C,下一階段準備轉換的方向。
對於To C,產品經理才是名副其實的創造者,需求來源於老闆、自己思考以及從各種渠道搜集來的信息反饋。你需要去主導控制整個產品的走向以及定位,從而調動所有資源去實現這個目標。

對於To B的深度價值體現建議:
1、給予客戶專家級別的建議。
因為你做過的同類行業所積累的經驗非常多,當客戶提出需求時你要更加深刻的剖析他的真正本質需求,結合你以前的經驗給他專家級的建議。讓你來主導整個需求的內容,從而可以讓開發需求量控制在你手中,並且可以讓客戶信服你。
但這裡面有個度的把握,不是讓你開刀闊斧的改變客戶公司的管理格局,那就是找死了。而是要將客戶公司比較混亂的管理格局進行梳理,而且是在對方確實有意向想要梳理的基礎上。而且梳理完的結果要隨時向對方最高負責人進行彙報,讓他來進行推行。
這樣一是可以像企業最高負責人表現你的專業性,讓他信服信任你,這對後期的項目推進以及要款都有無窮的幫助。二是這種事情本身也不是你所能推動的,這是要觸動各方利益的事情,所以交給他們內部去做最合理。

2、不要參與對方站隊格局討論。
如果對方接頭人員和你聊這個事情,你和他說說笑笑即可。這件事到此為止,你可以在自己公司說這事情,但是千萬不要和客戶公司的其他人聊這個話題。
好事不出門, 壞事傳千里。一旦傳到某些人耳中,給你找麻煩簡直太容易不過了。無形中給自己找麻煩不是聰明人的做法。

3、注意整個形象素質。
&<未完待續&>


做過to B的產品,也做過to C的產品。

對於to B的產品,道理上我認為 @yell huang同學說的大致不差,但是感覺上更傾向於贊同 @韓曖昷。我認為to B產品更能鍛煉人,要求更高,因為:

1、to B的產品,一般而言,邏輯較為複雜,不管是商業邏輯還是產品邏輯,需要考慮的問題很多。一般to B產品的立項,肯定必須要有非常清晰的盈利模式和能經過嚴格的演繹,雖然也會有一些毫無用處的功能出現,但是整體來說功能的改進和迭代確實更加拳拳到肉;另外,我並不同意to B產品不需要太好的用戶體驗,可能對用戶體驗的認識不同,交互設計顯然並非是用戶體驗的唯一要素。

2、to C的產品除非非常成熟,用戶量非常大,一般而言試錯成本還是比較低的;在to B產品里,客戶都是拿的真金白銀來支持你,一旦出了錯,壓力要比一般to C產品大,銷售經理和客戶打電話吼人的滋味很怕怕。

3、據我所見(可能限於眼界),大部分to B產品都是盈利的,而大部分to C產品甚至是不需要考慮盈利的。做to B產品對商業邏輯的理解可能會更深刻,更貼地氣的。

但是因為目前的互聯網投資熱潮,to C產品熱度非常高,發展也很快。加上對互聯網產品非常感興趣,所以我也在做to C的產品…lol。


效率,數據,賺錢


我們一直是2B的, 我們的客戶拿Coremail運營是2C的. 我看到的需求差異:

1。2B產品設計需要考慮「領導的體驗」, 尤其是客戶領導體驗, 領導的Email價值更高, 會決定it採購預算。2C產品, 即便是馬化騰, 也只是一個Email賬號,產品經理可以等同abcd視之。

2。2B產品客戶中, 有一些企業CIO, 真正站在企業管理層面來看it產品應用, 因此客戶在企業管理上的需求水平非常高,而如果沒有實踐過管理經驗, 是不可能靠任何數據分析出來的管理知識, 比如企業中的密級與可見性問題, 管理靈活需要, 虛擬部門等。需求理解與設計的人, 需要非常好的邏輯分析能力, 用更全面的技術知識實現。 2C市場在Email來說, 用戶就是一種黏度比較高的工具使用者, 甚至不如打遊戲的, 聽音樂的, 看電視劇的更有價值。 163和QQ的個人Email都是沒有管理關係的鬆散個體。

3。其實1和2都不重要, 我最想吐槽的是這個: 在中國, 企業工具的價值長年被低估, 被盜版佔領, 企業採購行為中魚龍混雜, 很多國產軟體活不下去, 買IBM和Microsoft可上千萬, 買國產軟體幾十萬還要砍價。 國家的軟體管理部門沒有什麼技術鑒別能力, 政府部門從財務制度上不支持買軟體服務按年支付(日本美國都鼓勵),法律上沒有保護。政府自己的採購行為曾經搞死某同行, 把該公司老闆徹底逼上了賣公司自救的道路, 後面開發了個產品叫微信。 上市企業軟體的龍頭用友和金蝶的財報讓人看了想哭, 比較賺錢的要麼給銀行運營商外包打工, 一個項目幾個億做幾年, 要麼做海外外包開發。


2B的時候:「為了順利完成調研,煩請貴司管理層完成以下問卷內容,限時60分鐘,中途不得交流,不得使用通訊設備,望能重視。(行政小妹發水,低頭看看錶)如果沒有什麼疑問我們現在開始吧。」
「你們編碼怎麼這麼混亂!」「入庫流程一定要規範」「返倉是重中之重」「不行不行,這個活動設置靈活性太大了」「沒事,應該的,只有幫你們做好了我們才安心。」


2C的時候:「X總,這是2015SS的面料、顏色、版型預測,您看一下。」「媽的,每年都是這些玩意兒,騙誰呢?」


我感覺最大的差別是:好的2B產品真心難成長起來。
相對於2C,2B的PM可以交流的人少,可以交流的東西少。
2C的東西網上搜搜可以搜出一大堆,慢慢看,再理論結合實際,可以學的很快。
2B的最重要的就是邏輯能力和推動能力,但這玩意兒交流學習提高都太難了。。。
感覺只能一點一點地悟。。。


先聊聊2C和2B產品經理的差別。

2C產品,通俗地講C端產品它的直接用戶是個人,主要解決個人使用需求。比如,想了解網路新聞諮詢可以使用網易新聞客戶端,享受高音質的音樂使用網易雲音樂,學習世界名校的公開課使用網易公開課,學習職場技能可以使用網易雲課堂以及找翻譯我使用有道詞典等等。所以2C的產品很注重人性,強調剛需、痛點和高頻及體驗。

那何為「剛需」?因為目標群體是個人群體,用戶量龐大且分散,缺乏組織性,需求也比較模糊性,所以需求需要去挖掘。

何為「痛點」?2C產品的更換成本非常低,用戶的決策時間非常短,所以能否在極短的時間內抓住用戶痛點非常關鍵。比如就我個人而言,在玩遊戲方面就有一個痛點,玩遊戲的目的是為了打發碎片時間,不會把玩遊戲這個事情佔用正常工作時間,所以選擇遊戲的時候目的非常明確,耗時的遊戲肯定不會看,哪怕遊戲再好玩,那麼這就是痛點。其實在現實生活中,很大的一個群體會有相同的痛點,比如享受高品質的音樂肯定是絕大多數喜歡聽歌的人的痛點,再比如音樂是一種情感的東西,那麼在抒發、交流情感的時候就需要一個交流社區,所以網易雲音樂做了評論功能,一下子火了,很快趕超蝦米、QQ音樂等APP,成為國內最大的音樂社區APP。

何為「高頻」?指的是用戶的黏性,而付費率往往跟用戶黏性、使用頻率相關。如果「體驗」很高,在滿足剛需、痛點的前提下用戶使用率自然會起正向作用。

說到2C產品經理,我們稱作為「用戶產品經理」,他的核心價值是「發現、挖掘用戶需求,定義用戶價值,並推動項目組達成這一目標,是一個從無到有的過程」,他經常要做的事情如跟用戶扯情懷、扣細節、拉會員、事件營銷吸睛、變現等等。除了提煉用戶真實需求、數據分析反饋產品、樂於分享、擁有較高的交互設計和用戶體驗能力之外,還會一些運營的技能幫助產品快速成長。對於2C產品經理來說,他的考核指標一般都是DAU、MAU、ARPU、用戶增長率、營收指標等,指標量化都非常明顯。但是他們卻很容易進入一個誤區,比如在某些交流平台,產品經理在交互設計、用戶體驗上投入過多的精力,但卻忽視了產品本身的方向和整體把控力。

說完2C產品經理,2B產品經理究竟如何呢?

何為2B產品?通俗地講2B產品背後用戶是企業、組織等團體,比如說網易企業郵箱是為了解決企業內部溝通、彙報、通知等辦公需求,有道雲協作是為了解決企業或團隊的資料管理和即時通訊等需求,提高了企業的協作效率,企業OA、ERP、CRM等系統本質都是為了改善企業業務流程以提高企業核心競爭力。所以2B產品更偏向業務,強調功能、流程和效率。

為何注重「功能」?一個功能多、大而全的產品往往代表很牛逼,例如網易企業郵箱除了通用的功能之外還有語音輸入、郵箱觸點、即時通等很多功能,屬於業內頂尖的企業郵箱產品。而用戶不會因為功能的增多導致學習成本提高,相反會覺得掌握了這些技能和知識實現了自身價值的增值。

為何注重「流程」?優秀的2B產品經理必須能夠貼合組織用戶的業務流程才能正常運行,而不同企業的流程又是不同的,所以對2B產品的流程設計是一個非常大的挑戰,同時也是至關重要的。

為何注重「效率」?2B產品經常會涉及海量數據,所以在2B產品中,效率要遠遠比用戶體驗重要。舉個例子:用戶想上傳1000個視頻文件,那麼批量上傳等高效率的功能體驗遠比優化上傳界面的用戶體驗重要得多。另外,我們經常看到商場裡面的收銀系統,很多是基於DOS平台開發,這些系統非常老舊、而且體驗比較差,但是由於使用時間長、效率非常高,依然保持著旺盛的生命力。

下面,我們再來看下通常的產品分類,2C、2B的產品其實都可以分為技術驅動型、業務驅動型及產品驅動型這幾種。

技術驅動型,技術為產品的驅動因素,由技術推動業務發展,可以不經過市場調研、產品設計決策階段等,直接面向創新者和早期採用者,快速的交付產品如廣告系統、搜索演算法系統等產品,比如淘寶直通車、鑽石展位等廣告演算法系統。

業務驅動型,也叫市場驅動型,用戶很明確知道他需要什麼,以及市場基本已經出現很多類似廠商參與競爭。它注重短期、低需求風險,與競爭對手差異性不大,價格和服務是主要的市場競爭工具在國內非常普遍。

產品驅動型,需要根據公司戰略整合技術和業務能力,並做好整體規劃、完成需求系統化,然後再設計、包裝並提供對外產品,配套運維及售後服務等,推動研發團隊做好管理。這類產品對產品經理的考驗最大,而前兩類的產品經理相對來說容易很多。

2B產品經理,我們也叫「商業產品經理」、「行業經理」、「品牌經理」等,那對於產品驅動型的產品經理而言,需要哪些能力和素質及如何考核產品經理呢?

首先,核心能力就是產品規劃、需求梳理、業務理解和整個以及項目推動能力。在考核指標方面,主要包括非量化指標,重在系統建設、效率提升、工作能力、營收指標等。他們與2C產品經理較大區別:2B產品經理目標比較難一致,需要對團隊灌輸和推動。同時,2B產品經理對業務的理解和行業的經歷要求更高,需要更加縝密的邏輯思維能力甚至理性過頭

那麼,明確了能力目標後,2B產品經理應該如何開展實際工作呢?就產品整體規劃來說,我暫且把它拆分為產品定位、目標願景和路標規劃。

什麼是產品定位:產品定位是指企業對應什麼樣的產品去滿足目標消費者或目標消費市場的需求,這是工作中非常重要的一環,直接關係到產品最終能否成功。舉個例子:一家創業公司看到視頻雲很有前景,BAT也都在做,於是老闆決定開始做,然後就開始招兵買馬乾起來了,結果發現理想很豐滿,現實是很骨感,由於各種原因,最終不得不放棄。因為他在工作的開始就錯了,沒有做對產品正確的定位,那如何做產品定位?首先我們需要做背景分析和現狀調研,深刻了解公司或部門背景、現有資源、競爭層次;然後通過市場分析:SWOT分析方法,分析業界標準,市場發展趨勢,新技術的發展趨勢和差異化等。最後還有環境分析:PEST分析,從政治、經濟、社會、技術宏觀分析,識別關鍵機會和威脅。

記得曾經在做教育錄播系統產品的時候,由於產品業內剛起步,教育部門沒有對應的政策法規來制定行業標準,然後我們找了業內幾家大的企業聯合邀請相關部門發起了對該行業的標準規格書,之後的產品功能、設計基本都根據這個標準來實現,因為標準就是基於它而來。又比如,今年年初,國家工信部要求所有直播平台必須把直播打上水印,並把直播過程錄製、存儲下來,存儲時間必須不小於15天。所以,在網易視頻雲的功能特性中,我們及時調整並上線了實時識別功能。

明確了產品定位,接下來需要樹立目標願景。

首先要明確產品核心價值,只有知道了最終想要的是什麼,才能明白如何一步步走向這個願景,最終的願景,是所有產出的價值所在。其次是樹立產品願景,建立一個3~5年的中長期目標,通常可表述為:幫助了【什麼人群】通過【什麼方式】做成了【什麼事情】,自己成為了【什麼】。可能會有很多人覺得願景都是虛的。但是我們發現,大部分成功的企業都會有很明確的目標願景,比如阿里早期的願景是「讓天下沒有難做的生意」,在過程中堅持不懈地圍繞這個願景一步步實現了價值。騰訊的願景是「通過互聯網服務提升人類生活品質」,百度的願景「讓人們最平等便捷地獲取信息,找到所求」。當然,好的願景不是一味的畫餅,而是能夠將「爆發的價值」與「可觸及的執行」相融合。

在做完產品定位、樹立願景後,就需要對實際的工作目標做拆分,也就是定一些小目標。首先拆分產品路線:統籌考量研發技術資源和市場運營計劃做階段規劃,定義階段里程碑,產品研發必須敏捷開發、短周期迭代,應對變化和調整。然後進行財務規劃:產品戰略、商業模式、盈利模式分析和規劃,以及資源投入計劃也需要都需要定義里程碑。做好各個階段的產品規劃之後,我們就可以具體的執行起來了。

最後,再分享下2B產品經理的職業發展問題。做2B產品經理工作時間越久,行業標籤也會越明顯,但實際上2B產品經理的工作範圍和職能非常廣,感覺就像是個萬事通,什麼事情都需要懂,2B產品經理可以參考的一些職業發展方向,比如需求分析師、業務架構師、系統諮詢分析師,也可以選擇做部門leader或者企業CEO。總體看來,產品經理的發展前景是非常廣泛的。


我講一下我的經歷和思考。我做的是大數據行業,產品賣給的是企業,但是產品要思考的是面對C端用戶,經常要思考的不僅僅只是客戶的需求,還要思考如何影響C端用戶做決策。我負責的產品可以說是幫助客戶做營銷,直接提升企業的收益。

tommy講的大部分的情景是正確的。B端的產品經理需要更穩,需要懂得靈活變通的跨部門推進工作,所以非常磨練心智,因為每一個時間節點都非常重要。B端的產品經理要求邏輯,邏輯清楚的規劃好產品,邏輯清楚的開會、推進事情;B端非常重視產品方向和收益。當然,我現在在負責的是一個處於初期的產品,關於tommy講的按照客戶需求來做事,這個公司所處的情況不一樣具體情況也不同。因為我現在大部分的時間一是跟B端用戶溝通,一是思考C端用戶的需求,不斷的去挖掘梳理需求,公司文化也比較靈活,做的時候也自由很多。B端產品經理並不是做外包的項目經理,挖掘、創造需求是產品經理必須的品質。帶我的老大產品總監無論是在產品上還是在領導人格魅力上都分分鐘讓我信服。

產品經理,並不是就是交互或者設計師。新人入行了就懂了。至於說C端產品經理更注重UI,這我是同意的。但萬物終有起源,源頭還是收益。不是說B端不想做UI,而是從收益來考量,並不需要UI多麼好看。但我自己還是非常注重UI的,也在學習這方面的知識。你能說B端產品經理不懂UI,我想這是片面的,一個沒有強大求知慾和不斷學習能力的人是當不好產品經理的。哦,不是,不僅僅只是產品經理。

我講過創業精神。一個人不能以二分法來看待問題,很多東西都是相通的,你能把一個方向的產品經理做精通,最後也就知道殊途同歸,踏實和求真很重要。

產品經理沒什麼,做市場、做銷售、做藝術....某個方向做精了,最終的方法論都殊途同歸,至於術上,比如對安卓、對ios等等的理解,浸淫時間久當然會有優勢。但以後如果安卓、ios被淘汰了呢?什麼都是可以學習的。

功不唐捐。


之前一直是做2C的產品,今年偶然機會去了家2B的公司,才工作6個月,說下自己的感受。

在2C的公司做產品,產品需求一般來源於產品團隊的創造、上級領導(懂產品的領導)、以及用戶的反饋,偶爾也有一些問卷調查之類的;
在2C公司,產品的權利很大,可以直接拒絕各種自己管轄範圍內認為不合理的需求。我們算的上是整個產品的把控者。

在2B的公司做產品,產品需求基本都是來源於B客戶和市場部或者業務部門的反饋,也有高層的需求。我們要做的要麼是將他們的需求轉化為產品方案,要麼是按照他們的想法直接設計產品,說白了,我們更多的時候是一個執行者,而不是一個思考者。
在2B公司,產品的權利相對較小,很難將自己的想法強加到對方身上。如果你們公司是甲方,可能上述問題還不是很明顯,但如果是乙方,上面的問題就很突出。

樓主所說的如何體現自己的價值,個人認為:
首先要站在客戶的角度考慮,客戶的核心需求是什麼,如何在自己現有的資源和平台下,幫助客戶滿足他們的需求,
其次,2B公司的用戶,他們的最終目的都是賺錢,你的產品必須要以這個目的為核心,至於產品功能好不好用,用戶體驗好不好使,真的不如C端產品要求的那樣苛刻。能使他們愉快的賺錢,這就是你的最大價值。


to b 要解決產業鏈的問題 工具型屬性更強
to c 要解決用戶的需求 很多時候是顛覆產業鏈 親民的屬性更強

to b 的產品經理要體現自己的價值 就要讓自己成為這個行業真正的專家 不是屌絲的思維邏輯


推薦閱讀:

土雞蛋是否營養價值比洋雞蛋營養價值高?
一個優秀的產品經理如何去真正了解用戶需求?
程序員怎麼和心儀的妹子搭訕,求教?
我是做销售的,怎么才能讲好这类故事呢?
你見過最優秀的 logo 是什麼?為什麼?

TAG:互聯網 | 產品經理 | 產品運營 | 產品策劃 | 產品經理入門 |