創造價值,持續交付:B端產品經理的方法論

1 評論 6059 瀏覽 51 收藏 92 分鐘

編輯導語:產品經理這個崗位的出現也順應了市場的需求,隨著市場的不斷發展,不同的行業分布明確,產品經理也在不同行業都設立了崗位;在如今這個大背景下,產品經理以創造價值為宗旨,產品經理也需要掌握多種方法;本文作者詳細介紹了B端產品經理的方法論,我們一起來看一下。

一、市場和產品

只有在市場經濟體系下才會有產品經理這一個角色的出現,這樣的經濟框架下,市場的活動主體、企業,通過與其它企業交易所帶來的價值來維持本身的存在和擴張需要;而交易的載體就是產品——通過產品在雙方或者多方之間的交換,所有的參與方都在交易中獲得了各自追求的價值。

那么如何在實踐中,洞察能觸發各方交易的需求,轉換能滿足需求的解決方案為可交易的產品,從而促成交易的發生和價值的創造,則成為產品經理所有擔負的使命和工作范疇。

產品經理不是一個新鮮的職業,只要有市場、有交易,就會有產品經理。

在互聯網產品經理出現之前,這種發掘市場需求、整合資源、設計方案、研發產品的訴求就一直存在;所以第一位產品經理出現在傳統的快銷行業也就不足為奇了。

時至今日,不同行業(例如家電、通信設備、機械制造、金融行業等)都誕生和逐步設立了產品經理這一崗位,而不在是將此角色的權責分散在企業里的不同組織當中。

在工業時代,受制于信息傳遞方式、技術成本和科技普及率,以及市場需求的局限;大多數時候產品經理這一職責實際上是被在不同職能部門中的人員共同完成的。

而信息時代的到來,互聯網和信息技術徹底改變了以往時代的生產要素的分配和市場需求。

先進技術的發展,大大拓展了企業的生產能力和信息獲取能力,市場需求從簡單單一轉為快速多樣和碎片化;這樣的外界商業環境,促使了產品經理職能需要被獨立抽取出來,形成一個獨立的職位來整合產品各個要素,貫通整個產品的生命周期。

1. C端產品經理

科技的發展無論在廣度和深度上都極大改善了信息的傳播,借助這些信息渠道的形成,單個自然人作為交易消費主體的需求被放大和關注;滿足這些需求的、針對個人(Customer)的C端互聯網產品被不斷推向市場。

在“人人都是產品經理”的號召下,借助于信息技術的普及和研發成本的下降,C端產品經理這一群體逐步壯大,不斷延伸業務范圍。

結合各類學科的理論和實踐,C端產品經理對個人的需求進行徹底和深入的研究與探討,以期尋找新痛點,創造新的產品;社交類型的互聯網產品就是這一類型產品的代表,例如抖音、陌陌。

2. B端產品經理

伴隨著個人流量紅利逐漸退潮,ToC互聯網產品和為之服務的C端產品經理開始邁向了飽和狀態;但是借助國家推出“互聯網+”的概念和積極的政策引導,各行各業都開始對接互聯網企業的先進技術和最佳實踐,希望通過“行業+互聯網”的方式來實現改革創新和產業升級。

在當下的市場環境里,企業需要結合科技來支撐自身已有業務的運營;同時,因為借助于科技的發展,新的商業模式不斷涌現,新的市場需求被挖掘;如此快速多變的業務需求,需要企業在市場捕捉、運營體系、管理機制上及時響應來保證企業的生存和發展。

因此,必須有這樣一批具備以企業為服務對象的產品經理,通過結合行業知識、業務運營、技術和其他相關要素來針對業務訴求;快速合理的設計企業應用產品,及時落地實施,敏捷迭代優化。

B端產品經理的產品交付物因為離大眾用戶有相對的距離,而且職能活動有相對的專業領域門檻,所以在一段時間內關注度和曝光率相對較弱;產品經理需求的大環境改變,給B端產品經理的發展和壯大,帶來了巨大機會,同時也帶來了挑戰,特別是在B段產品經理自身的業務能力和技能體系上。

B端產品服務的對象和需求來源是企業和組織——相對于C端產品需要針對個人用戶的心流和痛點,來研發設計相關產品;在B端產品經理的工作范疇里則轉變成了針對企業這個有機體的需求、組織行為、流程阻礙,以及業務模式與市場快速變化的不匹配等這些企業經營問題來設計和思考產品。

以企業運營架構和業務目標為背景,一個個業務團隊或部門被抽象出來,通過觀察和分析它們之間如何處理業務分工、規則設定、流程執行等事務;產品經理需要調動自己的商業分析能力和邏輯思維,從企業組織行為和組織目標來設計產品和定義功能,以期能解決企業的經營問題。

在此之外,B端產品經理還需要時刻觀察和分析外部行業動態和內部運營數據,從而有預判性的和準確的對企業經營現狀做出評估,通過B端產品的研發和迭代來驅動業務效能的提高、激發企業活力、實現自我提升。

B端產品的使用者也是個體自然人,類似C端產品,也會考慮交互體驗;交互的界面享有相同的設計邏輯,也僅此而已;界面之后的產品驅動力和服務對象的不同,決定了產品經理所考慮的優先級,產品價值創造的邏輯大相徑庭。

更進一步,B端產品所支持的業務訴求是依靠一系列使用群體共同協作通過產品來完成;產品經理需要在產品之外平衡各方利益訴求于產品生命周期內,從而達到共同的內在產品驅動。

因此,能否達到預期業務效果,并非僅僅局限于B端產品本身的研發,還有太多的其它核心但非產品因素會影響產品對業務目標的效果;產品成功和業務經營成功是分離的情況并不少見,這一點上B端產品不如C端產品同相關業務效果之間那么直接和緊密。

市場和行業的大環境需要更多的B端產品經理,它的工作范疇需要跨領域的全面綜合能力, 對產品的全生命周期驅動能力,和各項專業商業和技術能力。

本文試圖介紹B端產品生命周期和對應的能力在各階段的匹配實踐落地,通過案例的闡述來描繪出一個產品經理的工作范疇、職能足跡和技能使用,希望為B端產品經理的產品方法論和能力框架提供一個模型。

二、B端產品經理的工作理念

1. 產品經理的工作和意義首先在于創造價值

彼得·德魯克(Peter?F.?Drucker) 曾經說過“價值只能由企業外部的客戶來定義”。

Womack 和Jones 在 《Lean Thinking: Banish Waste and Create Wealth in Your Corporation》一書中也強調價值只有在在正確的時間、滿足合適的價格的前提下交付給客戶才能產生。

外部商業環境的易變性、不確定性、復雜性、和模糊性日益增強,創造價值本身和它的時效性逐步凸顯,這深刻地影響到了產品經理的工作原則和具體實踐;市場迅速的變換,當大量的時間和資源針對最初企業經營需求被投入,等產品功能全部開發完整后,市場的趨勢已經轉移,企業的經營需求也已經變換。

2. Womack和Jones提出精益思想可以指導價值的創造

清晰界定價值,把創造價值的活動按最優方式來組織執行,且不受任何雜事所擾,有效的執行,排除浪費,一次比一次更優化。

Eric Ries 在《精益創業》里提出最小化可行產品(Minimum Viable Product, MVP)概念;簡單地說,就是指開發團隊,在新產品的開發過程中,通過提供最小化可行產品獲取用戶反饋;所以這樣一個版本的產品能夠用最小的資源投入來獲得最大可能的被用戶驗證的反饋;通過執行這樣一個概念,以期望有時效性地驗證產品的價值。

在精益的思想下,擁抱變換、聚焦價值創造、精簡快速地落地產品,成為產品經理所具備的思路。

與此同時,正如市場本身的變化,價值的創造不是靜止的,產品的生命周期也不是線性不變的。

當一個MVP落地運行,開始滿足企業經營基本需求的時候,產品本身對業務帶來的效能和運營影響也開始被可以被衡量、評估和驗證;通過獲取真實反饋,分析業務數據,驗證業務問題解決效果等一系列活動,新一輪的產品創造過程被啟動,以用來矯正、優化或增加新的產品功能來解決新的業務問題。

這種迭代的思維幫助產品經理利用有限的資源快速驗證和解決業務需求,持續的反饋又推進新的價值創造;縱觀整個過程,產品本身的演進和生命周期結合業務需求,形成了完整的產品生命周期閉環,形成了持續交付的內生動力。

總結起來,創造價值、持續交付是產品經理的核心工作理念。

在上述理念中,創造價值是一系列的探索過程,試圖錨定產品價值,解決業務問題,而持續交付則是搭建產品和驗證產品價值效果的過程;在循環的過程中,不斷自我矯正,適應外部和內部需求變化,達到產品和業務經營成功的完美結合。

某些行業對這一理念的實踐并不陌生;比如在石油行業針對頁巖氣區塊所采用的“滾動勘探開發”方法,或是美劇按季來推出新作品,甚至華爾街在幾百年前的金融產品設計發行上都有蘊含這一理念;跨界的學習和借鑒,是產品經理不斷自我提升、拓寬視野、豐富思路、打造適合的工作方法和理念的有效途徑。

三、產品周期和范疇

產品本身的生命周期是一個循環的,螺旋上升迭代優化的過程。

在這一持續的過程中,隨著時間的推移,產品經理需要承擔不同的職能從而推動產品的演進和迭代:

  • 第一階段:需要不斷的洞察業務或市場訴求,尋找和定位產品的需求 (洞察需求);
  • 第二階段:定位、定義和設計產品以及針對的目標 (產品設計);
  • 第三階段:整合資源推進開發落地 (產品開發);
  • 第四階段:最后推廣和宣傳產品,通過運營數據分析和用戶反饋,進行下一輪的產品迭代更新重新開始循環第一階段 (產品運營)。

同時在每個階段所關注的重點事項和優先級也隨之改變。

1. 洞察需求

這個階段的目的是定位企業的痛點,無論是新業務的拓展,或是現有業務的優化和變革,需要的是充分分析和洞察企業需要尋求新價值和變化的動力基礎;在此之上是對企業發展的經濟模型和商業模型的深入分析,從而結合所期望達到的目標來開始設計和定義相關的產品。

企業或商業體的存在就是在不斷創造價值,它的行為也是為這一目的而驅動的;同時,企業作為市場里生存的有機體,隨時需要根據外部環境的變化來做出相應的調整和適應;那么以公司或者商業體為服務對象的B端產品則是為了匹配這些需求而打造。

發現和了解企業背后的需求來源可以通過不同的渠道來獲得,例如業務調研、梳理企業運營狀況、厘清運營阻塞;或是,依照既定的業務路線圖和長期規劃來落實匹配的系統產品開發;也可以是,通過分析市場動態和對比行業競爭對手來尋找企業自身的變革需求。

發現具體業務需求后,產品經理則要立足于企業自身的商業模式和經濟模型來開展工作;深刻理解企業為了商業目的所采取的策略和執行手段,以這些業務經營本質為基礎,針對變革需求來匹配對應的產品設計和開發,從而達到了增加業務價值,匹配業務變化的結果;這樣的結合是正向的匹配,即商業的動態和變化要求系統產品的跟進式匹配,是業務驅動的產品開發和價值發掘,動力方是在業務部門。

產品需求的渠道也可以是上一周期效能反饋;在系統產品搭建后,通過具體的數據收集、歸類和洞察,然后提煉出無效率、資源浪費或需優化的地方;這些反饋也可以轉化為企業變革的需求,這類需求以數據為基礎,提出優化需求,讓數據來驅動業務的變化,從而落地數據驅動的價值發掘。

無論是業務渠道還是數據渠道,在這個過程中,業務部門需要定義清晰業務目標的成功標準和衡量體系,于此同時是產品經理開始構思產品與之匹配的數據運營指標和衡量體系;例如,業務目標是落地一條新的業務線,那么這條業務線在企業組織里的成功搭建,和在預計時間內的啟動運轉會是業務部門這一階段的業務目標。

那么與之匹配的在產品構思就需要考慮,如何通過梳理新業務線的業務流程和運作模式來設計新的企業應用產品,以及此應用產品和已有的其他產品間的關系;同時,需要設計相關新產品抓取和衡量產品本省是否能支持業務目標的數據點。

通過數據點的數據收集,會為之后的產品運營打下基礎,同時也是驗證應用產品本身的有效性,和未來提出新的產品改進思路的數據理論基礎;從而推動和形成產品進化閉環,雙向流動,互為推手,已更高價值和更優效率為目的,交替驅動,不斷提升。

另外,需要關注的事項是決定業務需求的優先級和重要程度——在業務洞察需求階段,總是會有紛繁復雜的訴求和問題需有待解決;在此過程中需要反復權衡利弊,根據企業自身的特點和基礎,決定優先級,判斷做哪些和不做那些,先做哪些和后做哪些。

2. 產品設計

產品設計階段有兩條主線橫跨整個進程,互相驅動和支撐;其中一條相對于產品經理比較明顯,是匹配業務需求和痛點來設計產品方案;而另外一條更強調的是和具體開發工作所需厘清的事項,例如軟件架構、技術選型、測試策略等等,為之后產品開發階段的產品具體實現落地,和適合的技術方案選型做前期技術準備。

產品總體的設計思路是從自頂而下,整體到細節,逐步細化,層層推進;通過業務訴求分析和運營診斷,產品經理從具體的業務事務和流程當中抽象和演化出具體產品功能模塊和設計產品的效果。

在開始一個產品解決方案時,首先需要的是評估是該方案的所針對的業務和現有的企業解決方案之間的關系。

這個新的業務問題需要的是對已有的系統平臺進行改造優化,還是有全新的技術方案需要開發,或者是兩者的混合模式;好比你要在一個裝滿點心的盤子里要在放入一塊新的蛋糕,它的放入不可避免的會對已經在盤子里的其它糕點造成影響;也許要挪挪位置,從新排列組合,騰出點空間給新的蛋糕,或是把一些不想吃的點心挪出盤子。

一個新的系統產品的出現必然會影響到已有的企業軟件架構和組織,如何有序和有規劃的安排,是產品經理和受影響的業務部門需要探討和決定的;而這一過程中,需要平衡各方面的訴求和利益,但是必須以業務整體優化目標為結果導向。

在這樣的一個基礎上,產品經理和相關業務、技術人員開始梳理整個產品解決方案的業務核心流程;在這個過程當中,相關業務參與人員描述現實工作當中處理業務問題的步驟,方法和涉及的操作方等;通過這些信息,業務的主干脈絡被用業務流程圖繪制出來,從而進行分析和改進,形成最終解決方案的基礎依據。

在業務流程梳理過程中,通過對業務的理解和涉及到的業務對象,通過邏輯抽象,歸納整理出來需要服務或使用產品的對象,及其在整體方案中的功能定位和實現目標。

接下來就是將分類出的對象下所需要執行的業務工作,本質訴求和目標,進行提煉和歸納為具體的商業功能模塊——這需要產品經理具備基礎的企業管理和商業知識,配合具體企業業務部門的領域知來進行規劃設計;在這個步驟當中,各種的功能需求會被建議和提出;當匯總完成后,就形成了整個產品的路線圖(Roadmap);如之前所討論的,企業的訴求多樣和市場變化十分迅速,不可能一次性完成所有的功能點,這也不適合現在提倡的精益和聚焦價值,快速迭代的理念;產品經理需要幫助業務部門定義產品的MVP,逐步推進路線圖的落地。

從整體到局部,下一步就是具體的產品細節設計;這一部分的工作是把一個個抽象的功能模塊概念、可視化成為一頁頁可以同用戶交互的界面,以及設計界面背后的數據模型、權限和邏輯等的事項。

另外非常重要的一點就是對應的功能和頁面交互的數據埋點和收集工作,需要在整個階段定義清楚;為之后的產品運營打下基礎,也是形成產品閉環、聚焦價值所需;一些具體的技能要求,在接下來的章節里有相關的介紹。

在整個產品方案設計過程中,業務流程圖是一個非常核心和關鍵的工件;它是連接現實業務和系統開發工作的橋梁,讓業務、產品和開發團隊使用同一個語言背景來討論問題和推演方案。

在設計當中,業務流程圖自身的不同層級對業務流程步驟的描繪、邏輯的細節,具體操作交互等的深入和細化,不同職能的參與方(業務、產品、技術等)都可以在相應的層級主導和提供支持方案的最優設計。

另外一條工作主線則是相應的技術方案選型和準備工作,這部分的工作主要是開發技術人員來主導,產品需要了解過程和提供對應的信息支持;首先是應用技術架構和新的產品解決方案之間的適配性的思考;例如,現存的軟件架構是單體式架構(Monolithic),而新的業務形態和方案需要使用微服務(MicroService)來支撐;然后是一些具體的技術選型(例如,前端開發技術語言等)和開發策略問題的討論;需要如何匹配產品設計方案來更加準確,高效的達到產品目標——這是一個反復討論和平衡利弊的過程。

3. 產品開發

當產品路線圖和具體的產品開發時間規劃確定后,接下來就是具體的產品開發執行階段;在有些企業,產品經理可以放手讓開發團隊的負責人來相關的工作,只需等待驗收結果;而有些情況下,產品經理還需要參與到日常的工作當中去,支持具體的開發工作。

這種情況下,產品經理將要擔負起項目經理的職責,對產品進度的推進落地進行把控。

首先是,針對之前規劃的項目時間表計劃的執行完成度的把控,確保開發人員能夠按計劃執行和完成相關的工作;在此期間,隨著開發細節的不斷深入,一些之前未考慮到的產品設計盲點將會浮現出來,需要產品經理的分析和確認。

其次是對產品項目相關者的溝通和把控,持續和業務部門溝通進度,把握業務部門的脈搏,讓當下的產品交付結果滿足業務的需求和時效性。

根據市場的變化和業務價值的優先級,產品經理還需要動態的調整產品功能交付的優先級和范圍,在項目管理角度把控下一步的計劃和安排;與此同時,階段性的開發成果需要積極邀請業務方參與驗收評估。

雖然整體功能不能全部展現和貫通,但是結合一些技術措施 (例如使用Mockup來表示未來實現后的效果),把已經開發出來的功能點給予展示,可以及時收到業務的反饋,保證目標和方向的正確性和一致性。

這個階段,產品經理更多是在項目管理上起到主導作用。更多的是輔助開發團隊高效落地方案;積極溝通業務相關方,同步進度信息,匹配業務動態。

4. 產品運營

基于精益思維,產品本身都具有階段性,仍然需要不斷的迭代和優化;所以在產品運營階段,運營事項里面不但包含了業務在產品上日常的運營、監控和管理等事項,還包含了產品經理會往外對產品進行游說、推銷和積極搜集反饋、主導或輔助一切能讓產品本身被更廣泛使用增長和優化的事項。

與此同時,根據之前在需求洞察階段定義的績效指標和數據埋點,這個階段可以用于從不同的角度來觀察和分析產品效果。

關注的重點從分析產品本身是否解決企業業務問題著手。

如果是從0到1的產品線搭建,那么需要考察的是,這條產品線是否已經通暢運行,業務部門在上面執行的關鍵業務環節是否有異常和阻塞;新業務線的搭建,是否幫助企業獲取到了規劃的目標市場,業務部門和用戶有多少人開始通過產品來執行新的業務,以及在此產品上的業務成交量的大小。

因為是新的功能和業務,產品經理需要提前準備和積極參與功能的推廣宣傳和業務培訓事項;充分結合和調動業務部門負責人的資源和參與度,從而獲得更好的用戶接受度和使用率;如果涉及到重大企業組織結構級別的變動,還需要提前制定變更管理計劃;產品在被使用過程中,也會涉及到邏輯答疑、業務數據分析和解釋、系統Bug修改等支持活動,需要產品經理參與和幫助協調資源解決問題。

如果是優化迭代性質的產品,那么需要觀察和分析的是,根據產品的使用數據反饋,是否能帶來之前針對業務痛點的改善,是否可以進一步提升了業務整體目標,不論是營收規模還是運營效率的提高。對于迭代優化類型的產品來說,更多的是關注其對業務目標的幫助。這個階段可以引入OKR的框架來衡量產品價值。

在與業務日常運營的交流中,該階段產品的局限性和故障被總結,業務部門的反饋和新要求被收集,從而形成下一個階段的需求池;同時,系統記錄的績效數據和數據埋點可以從客觀上提供不同的分析視角和改進需求。

例如,在某維修公司,業務部門提出把屬于一個上門點的所有維修工單統一歸納到一個服務請求下來;這樣可以做到一次請求,多個工單同時解決,從而避免多次上門和重復業務流程的目的;該產品功能上線以后,業務人員確實在使用,也提出了不少的改進建議;但是數據分析發現,大部分的服務請求下,實際只包含了一個工單,沒有達到預取的效果,維修人員還是多次上門服務,重復流程,這些發現是通過系統數據發掘的;客觀的指出了——產品的使用層面的成功并沒有帶來預期的業務效果,這些運營數據就可以成為產品功能優化和改進的參考。

另外一方面就是參考用戶行為數據的分析;用戶旅程地圖(User Journey Map)的數據埋點和熱力圖等來驗證用戶和產品之間的交互是否是按照設計來執行,從而推演出產品的實際業務效果數據和用戶使用行為之間的關系;如果效果不好,那么是否是因為用戶沒有按設計的交互場景來使用,或者是效果很好的原因是因為用戶使用的方法與設計有高度的吻合。

總之,運營階段需要關注的是產品功能運營工作和對應的產品數據運營工作。整個階段也為產品下一個周期優化升級開始做準備。

匯總上面所述的產品的生命周期,那么在產品經理需要在周期的各個階段需要關注的重點如下:

四、B端產品經理的能力

1. 商業洞察能力 (Business Insights)

產品經理的使命是創造價值,商業洞察能力能夠幫助產品經理準確地定位價值在企業當中的所在;通過分析企業商業信息,了解業務規則和具體的執行,才能搭建出與之匹配,適合業務的系統產品。

產品經理的商業洞察能力是一個很寬泛的范疇,包含了經濟學、組織行為學、經營管理、市場營銷、金融財務等等;這些基礎學科和領域知識給予產品經理對應的通識能力和批判性思考框架,從而可以透過事物紛繁復雜的表面現象來定位核心問題,錨定企業變革需求的實質問題。

例如,在許小年的《商業的本質和互聯網》一書當中就充分的闡述和分析了各類商業模式和和對應的互聯網企業的案例;透過這一系列的案例,各類互聯網企業的盈利模式和經濟效應模型被剖釋,讓讀者明白助力這些互聯網企業發展壯大的商業本質是什么;同時也揭露了一些企業的偽經濟模型和其為何無法盈利,哪怕當時這些企業意氣風發,風頭正盛。

這些解析后的思維,正是產品經理所需要具備的商業洞察能力。俞軍曾經在一次發言中也提到,產品經理實際是從總經理這個崗位上剝離出來的角色,那么作為這個角色就需要具備總經理一樣的商業洞察能力,做市場定位,洞悉人性,像總經理一樣考慮周全,不斷打磨迭代產品。

1)商業經濟模型

這里利用一個案例來討論經濟模型和剖析企業的商業模式,從而反映出這類能力如何能幫助產品經理更好和更有效地針對企業的變革需求來打造對應的產品,使之與業務目標匹配。

T公司是一家運營了多年的2B類型汽車維修企業。企業從一家小維修公司開始,發展自己維修服務業務,與此同時逐步通過打造自己的IT業務平臺,慢慢演化成了專為企業級客戶提供車輛維修業務的服務外包商。

T公司首先和大型運輸企業客戶簽訂維修商業外包合同,使得客戶可以在系統平臺上提交車輛維修工單;另一方面,T公司在全國各地招募汽修企業入駐到系統平臺上,每當客戶企業在某區域有維修工單產生,平臺會通過算法匹配分發給在該地區適配的已簽約入住系統平臺的汽車維修公司。

基于這樣一個商業場景,在解決業務訴求和運營痛點的時候,到底是以什么經濟模型來評估產品的價值和業務目標呢?

它的底層經濟模型是和滴滴或者Uber一樣,遵循梅卡夫效應(Metcalfe‘s Law),通過正向推動刺激來擴張經營業務的么?

Uber為消費者提供了匹配服務,它幫助乘客找到司機,同時幫助司機匹配乘客;隨著司機不斷加入和服務覆蓋區域的擴張,這一商業模型的內在增長動力開始出現。

乘客越來越多,隨之帶來的越來越多的司機,這樣叫車等候的時間又進步一步縮短,司機空載的幾率降低,單位時間內可以達成更多的交易;這樣供給雙方的互相正向刺激形成了良性循環,爆發性地拓展了業務的邊界和經營規模。

還是說,它是基于雙邊效應下的商業模型?

梅卡夫這一效應的強大在于每個節點間的互動與活躍,在此前提下的商業模式才具有更高的經濟估值;而對與某一類網絡商業模式來說,交互只存在特定種類用戶之間,比如AirBnB上的房東和房客之間,跟誰學上互動和交易僅存在于學生和老師之間進行。

在互聯網的平臺商業模式中,用戶分為兩大類是常見的現象;同時,供應商同供應商之間鮮有往來。消費者之間大體也是“雞犬之聲相聞,老死不相往來”;是正如郭德綱所說,同行是冤家。用一個簡單圖形表示,如下:

而這類互聯網平臺的價值來源于供應方和需求方的相互吸引和相互促進。在交易平臺上,不同類型用戶之間的正反饋、交互所產生的價值就是雙邊市場效應。在這個經濟效益模型下,平臺企業所需要針對的是如何刺激交易和吸引更多的入駐用戶,從而放大該商業模型給企業帶來的價值。

也許T公司的這個商業模式,沒有列在這里所說的經濟效應模型當中。它只不過是做著傳統生意的買賣,無外乎是遷移了經營場所而已。實際上的使用的是以下經濟模型

在這樣的經濟模型下,T公司簽訂客戶,把汽修工單交給維修公司,居中阻斷了企業客戶和維修公司的互動,實際上是削弱了梅卡夫效應和雙邊市場效應;而企業的盈利來源是從這些交易中獲得提成收益。

在這樣的業務模型下,企業的盈利是靠降低單個交易成本,提高交易數量和流轉速度來達成的;那么與之匹配的產品設計的核心目標就是要圍繞這個商業邏輯來打造,提高單個工單的處理時間和效率,降低單個工單的資源成本,推動企業拓展和獲取外部客戶的能力就成為產品經理在考量系統產品價值時所針對的優先指標。

而拓展外部客戶這一事項,有需要產品經理具備行業的基本知識,能夠分析行業動態和業務的定位,針對需要拓展的客戶開發相關的產品;比如說,如果之前的T公司的客戶都是大型公交系統客戶,那么在產品平臺上所處理的配套的汽修工單都是針對這類型客戶的車輛特性來設計的;那么如果企業現在需要拓展出租車維修市場,那么現有的產品特性和處理邏輯是否匹配,有何需要改良,就是產品經理需要提前預判和研究的問題。

產品經理的商業洞察力也會針對業務形態和成熟度有不同維度的運用;通常是通過設計和實施應用產品來推動和支持業務運營目標的實現,從而達到業務驅動型價值;另一方面,在已經處于運營階段的產品系統,產品經理可以通過數據的運營和發掘,或者新技術的引進,引導企業改善運營現狀,提高企業現有商業模式下的效能,從而實現產品驅動型價值;產品經理需要清晰的了解業務所處的狀態和產品本身的能力,從而預判不同業務痛點所需要的產品方案。

這個分析能力的運用貫穿整個產品的生命周期,雖然在不同的階段的密集程度不一樣,但是對于產品從概念到落地都有十分重要的意義。

在洞察階段,解讀商業模式,確定產品的目標和定位。設計匹配業務目標市場和行業的產品方案MVP。

在設計階段確定業務邏輯和交互原則,讓產品設計邏輯和交互更加貼近業務的特性、優化流程、提高效率、支持核心業務目標;在實施階段幫助開發團隊進行邏輯驗證和迭代規劃,確保交付產品的業務價值,把控投入開發資源和業務效益的平衡;運營階段又重新回到舞臺中央,主導產品的生命周期主要事項,監控和評估產品落地后的效益和運營改善事項。

2)業務組織結構

了解和研究業務組織架構能夠幫助產品經理在工作過程中厘清工作目標,處理好協作關系,從而保證工作的高質量開展和高效完成。

企業的發展階段需要不同的組織架構來支撐其業務形態和發展目標;從某種程度上,組織架構就反映出了業務價值重點的分布和優先級;例如,各大互聯網企業隨業務和市場變化而進行商業事業部調整。通過匹配合理的組織架構搭建,企業可以正確的引導業務部門的運作往規劃的價值方向發展,也錨定了每個業務人員的共同目標。

組織架構決定了匯報關系,進而決定了績效考核方式。同時,匯報關系、績效考核方式會影響人做事的動機、行事的方式,以及個人和團隊的利益;厘清了這些組織結構所反饋出來的業務價值和利益關系,產品經理可以從企業經營的角度來平衡產品價值優先級,優化資源投入和產品組合。

業務組織架構的理解也和之后要談到的產品項目管理能力和產品經理的布道者能力相關。 在執行項目時間表和溝通具體事項時,能夠快速的定位關鍵人員,可以幫助錨定業務對產品價值的評估,解決協調困難,加速推進產品落地實施。借助組織架構,產品遠景和價值也能更有效的傳遞。

在一個理想的情況下,企業組織有明晰的組織架構和共同的價值目標,把企業互相獨立的力量聚集成一股合力;這種環境下,產品經理可以充分發揮和聚焦產品研發本身。

3)商業工具

還有其他理論和工具來引導企業運營和商業因素的分析,這些理論從不同角度對企業經營經行梳理,幫助產品經理有結構、有體系框架的了解產品服務的對象。

以下列舉幾個常用的方法:

4)業務拓展和延伸

除了關心現有的業務經營范圍,產品經理也需要拓展相應的產品思路和全局觀,把握行業脈搏,同時跳出當下,對企業發展的走向有思考。

以上述例子里的T 公司為例。現在的企業經營的業務線只在公交系統的車輛維修,那么如何拓展除了這條業務線以外的其他市場,比如說貨車、的士等? 或者說,目前公交系統這個細分市場里,還有什么可以延伸的客戶?比如之前可能只覆蓋市內公交系統車輛,那么城際車輛和長途車輛呢?

另外的一個延伸是對應的系統技術這個角度;目前T公司是作為服務公司,使用系統平臺來服務客戶和對接汽修公司;那么針對希望自己運營管理維修工單,不愿意使用這種外包服務模式的客戶公司,是否可以提供技術平臺,以SaaS的模式為客戶提供服務。

以上只是從兩個維度來拓展衍生業務。

如之前介紹的,產品經理有時需要已總經理的角度來考慮企業經營,市場定位和產品打造。

2. 產品設計能力 (Product Design Skills)

產品設計能力需要把產品從抽象概念、可視化的、有結構的展示出來;這樣的能力的技巧就涵蓋了信息架構、原型設計、原型交互和用戶旅程地圖、UI設計和各類產品文檔的撰寫事項;例如,商業需求文檔 (Business Requirement Document ),產品需求文檔 (Product Requirement Document ),和市場需求文檔 (Market Requirement Document )等。

1)信息架構

產品經理通過信息架構的設定來統籌和規劃整個產品設計所覆蓋的范疇。同時,信息架構本身也提綱挈領地指導其它產品設計技能的實踐。

一款產品是通過系統與用戶之間的交互,以數據為橋梁推動業務流程的流轉。

那么什么信息應該展示和如何更加有效的展示,從而讓用戶便捷獲取所需信息,方便地執行操作,這都依賴于信息架構的指引;要直接了解信息架構是哪些組件構成是相當困難的,用戶只和部分組件直接交互,而其他躲在幕后的組件,用戶卻沒有感知;在《信息架構 – 超越Web設計》中,信息架構被分解為4個組件。

基于這些組件,產品經理搭建與產品相匹配的信息架構。在眾多信息架構所涉及的領域來說,最直接的一項就是產品/系統頁面菜單。菜單結構本身不但蘊含了與業務流程的映射,同時也兼顧了用戶習慣,讓用戶快速獲取信息。

2)原型設計

接下來的一步就是每個交互頁面的設計。匹配在流程圖所設定的操作步驟,頁面應該提供相應的操作信息。在這一步上,也有相關的框架和最佳實踐可以遵循。

每一個頁面可以解構為一個或多個設計模式的組合,而每個設計模式又是針對某種特定活動提供的設計方案;比如,信息的查看、搜索、下載這些活動都有對應的設計模式;這樣,每個界面上所要承載的各種活動都可以用相關的設計模式來承載;所以通過確定頁面上的操作動作,可以選定設計模式,然后通過把各個模式進行布局和組合,最終就可以形成產品原始表現的頁面。

這個方法,在具體落地設計時,通過分步來實現;首先是采用線框圖粗略表達必要信息的展示方式和布局,采用用戶畫像、親和圖、業務主題錨定、遵循先例等手段;產品經理設計出線框圖,通過可視化的手段、帶入場景、驗證假設和討論效果,從而不斷優化推動下一步開發;接著是進一步在視覺上深化,設計樣機模型(mockup)。

線框主要代表產品的結構,而樣機模型則顯示了產品的外觀;它還不能實現點擊滑動等交互操作,但是擁有更高的清晰度。最后是高保真圖的開發和設計。

此外,一般系統產品都會提前準備一套產品組件,例如,輸入框、按鈕、側邊欄、分頁符等;組件是設計的基本元素,組件的使用可以保證設計上的一致性,方便后續的產品設計工作,同時也幫助提高產品經理的工作效率;產品經理需要了解和靈活使用,避免重復造輪子,或是過度資源投入在新組件的開發上。

在色彩方面有需要注意的是,配合組件的設計,顏色搭配可以適用在可能出現的場景里;比如,一個按鈕的不同狀態下,按鈕的顏色變化也適配對應的頁面整體視覺效果;另外一個需要關注的是法律、行業或其他合規要求對色彩使用的規定;例如,針對視覺障礙用戶,標準字體14px-20px的色彩對比率要達到4.5:1。

3)原型交互

在產品頁面的設計過程中,頁面間的交互設計也已經同時被討論和開發出來。原型的交互設計有各種的理論和技巧被研討過。

最為經典的是Jakob Nielsen 提出的10大可用性原則(10 Usability Heuristics for User Interface Design);產品經理需要在理解這些原則的基礎上,結合具體的問題,靈活使用,參與交互設計工作。

雖然2B類型的產品服務對象是企業組織群體和業務目標,但是它的日常操作是同每個個體經行交互和執行的。用戶使用過程的流暢、高效將會對產品本身成功落地和發揮效能起到推波助瀾的作用。

4)用戶旅程地圖

用戶旅程地圖(User Journey Map)是一個幫助產品經理充分了解和分析用戶使用行為的工具,同時借此可以優化產品與用戶的交互,達到產品使用催化劑的效果;用戶旅程地圖可視化地將用戶與產品或服務之間的互動,按業務流程分階段地把用戶體驗、行為、感受和想法展示出來。

通常,一個旅程圖包括3個部分的內容:

用戶旅程地圖的制作步驟如下:

基于操作流可視化來圈定范圍,搭建數據埋點方案,然后在產品運營階段,可以通過埋點數據來分析旅程每個階段捕獲的交互相關信息( 如操作時間、等待時間、操作步驟和次數等數據信息),來發現其中可能存在的問題,從而提出相應的解決方案,以優化用戶交互來提升產品有效使用。這些解決方案可能是對原有流程的全面改造,也可能是對某個環節的局部優化。

例如,對于一個火鍋店來說,重要的一個業務事項就是如何縮短從客戶開始點菜,確定菜品到最后的客戶買單離店這樣一個過程——針對整個事件場景,我們可以搭建對應的流程模型,對各個環節進行分析;當按照旅程地圖制作步驟,獲得了問題癥結的假設后開始進行對應的優化安排。

當然,同樣的流程和操作場景,也會因為業務關注點和目標的不同而產生不同的優化方案;例如,如果以上的餐飲場景是發生在精品私房菜或者日系居酒屋上,追求的最佳用戶感官和菜品定制體驗上,那么用戶旅行地圖的使用會得到不一樣改進方案和優化方向。

UI工程師基于交互原型進行美工設計,生成切圖;前端工程師拿到切片文件,進行前端開發,包括交互、動作效果等;產品配合UI工程師確定設計質量,同時為銜接前端工程師開始相應的開發。

產品設計能力大部分涉及到和用戶個體的交互事項,所以和2C的能力有高度重合,畢竟2B的產品需要人來操作;抽象事務和概念的可視化過程,結合業務和審美,提高美學的修養和實際工程的結合。

總體來說,這些技巧的使用會因產品本身匹配的業務而靈活運用,但是也有不少的日常最佳實踐可以幫助到日常工作,提高產品經理工作效率和質量。

首先,設計時,需要參考企業內部已經約定俗成的方法;保持新的產品設計和已有產品之間的一致性,減少使用教育成本。

其次,盡量參考的市面流行產品設計模式;比如微軟的office 套件,大家都用,容易識別,沒有過多的認知困難,同時還省開發時間。

另外,如非必要,可以直接采用常用設計軟件(Axure, Visio 等)的標準控件;產品經理需要平衡為產品單獨定制所耗費資源與定制帶來的收益,過度的追求設計上的新意,容易舍本逐末,浪費工作資源。

在交互方面也可以借鑒流行產品的設計,例如用戶操作提供保存提醒可以借鑒Word;在移動設備上,某產品功能希望用戶操作前,能習慣性下拉屏幕已獲得最新的數據更新,則可以參考微信的設計。

B端產品應當簡單直接設計,以解決業務問題和效率為核心指導思想,先落地;在之后的運營階段,各個頁面被使用,通過數據埋點,熱力圖等方法了解用戶習慣,隨后可以不斷針對性的迭代優化。

5)產品文檔

產品設計能力的一部分是對應文檔的撰寫,盡管在敏捷價值里提出了工作的軟件高于完善的文檔;但是文檔在整個產品開發生命周期中,作為信息傳遞的渠道,以及組織和協調相關資源中的重要性不言而喻;眾多的文檔中,最為關注的就是產品需求文檔 (PRD)。

不同企業或團隊,產品需求文檔的定義和形式會有所不同,但是基本的核心內容是十分相似和統一的;產品需求文檔是在產品開發過程中用來向各個參與部門來溝通和介紹相關產品需要包含的能力的工具。

它需要包含的內容會作為其他后續文檔的參考指導,以下是一個基本的內容框架和介紹:

撰寫產品需求文檔是產品經理的必備技能,不但要求產品經理有產品本身全局的概念,還要能夠高度抽象和精煉的把各個事項描述清楚,通俗易懂。

網上有不少的PRD模板可以借用,產品經理需要針對具體的開發項目,適當調整匹配,以有效和準確溝通為目的;同時,對于有些部分,無需急于一次完成,還是有一個不斷優化完善的過程。

3. 開發技術能力(IT Competence)

“不是內行,但必須是行內”這是對產品經理在開發技術上的總體要求。

好比作為建筑設計師,在設計新的建筑的時候,是要對現階段的工藝、材料和項目施工難度有基本把握的;如果設計的建筑沒有相應的落地工程方案,那么這個設計就只是藝術品,而不是真正的產品——這里的道理實際上也是同樣可以應用在軟件產品的開發事項上;產品經理需要對產品實施方案的技術框架和可行性有基本的了解,在一些情況下還要對不同的開發實現方法與產品價值實現之間進行平衡和取舍。

了解開發技術的另外一個益處則是可以對技術難度的開發時間有自己的初步預判,快速調整和響應變化;對相關的時間影響,項目推進有基本的預判和提前安排;同時可以提供非純粹開發人員的角度來給予思路,幫助團隊拓寬解決方案的視角。這個能力同下支持下一部分介紹的項目管理能力、互相支撐。

在紛繁復雜的技術領域,有許多值得了解和學習的內容;針對于產品經理的日常工作,以下初略列出幾個方面的內容可以學習研究來增強開發技術能力。

1)軟件開發元素和團隊分工

軟件開發所涉及的主要元素和對應的人員分工能夠幫助產品經理在宏觀上了解具體搭建落地所涉及的事項。

如同建筑工程,整個建設過程是多個不同專業工種配合完成的,多個工種又會對具體實現的工藝為了匹配設計來平衡選擇,那么對于軟件產品開發也是同樣的邏輯。

首先,是知曉軟件開發編碼需要使用的開發語言;程序開發是用一種計算機語言來表達外界事務的邏輯和處理的事項關系;無論是什么具體的開發語言,例如 C,Java,還是PHP都是為了這個目的。通過學習編程語言,產品可以了解編碼的基本邏輯和所涉及的操作,從而更好的理解編碼開發的原理和日常活動。

其次是了解數據庫和使用SQL 來對數據庫里的數據進行操作,進行數據分析和查詢;簡單來說,數據庫是對數據按一定規則進行組織存儲和管理,同時支持外界對數據進行增刪改查操作的技術。

簡單來分,有關系型數據庫和非關系型數據庫這兩類:

  • 關系型數據庫通過二維表及數據字段和字段類型來表示數據;關系型數據庫中,現實世界的實體被映射成二維表,然后數據之間的關系模型,通過實體關系來關聯不同的表來實現。常見的關系型數據庫就有Oracle、DB2、MySQL等。
  • 而非關系型數據庫是一種新的數據存儲模型,儲存的結構相對松散,可以不嚴格按照結構范式進行存儲;非關系型數據庫沒有關系型數據庫那樣的嚴格數據結構約束,在存儲的形式上也不同;常見的產品有MongoDB等。

兩種數據庫會針對不同的數據存儲需求而選定。了解數據庫和對應的技術使用,能夠幫助產品經理優化功能設計和平衡利弊,把控開發進度。

例如,一些產品功能需要調用分布在不同數據庫技術平臺上的數據,那么相關的技術可行性、實現難度和性能問題和使用影響等,都會需要產品經理參與討論,作為最終方案確定的依據。

而SQL(Structured Query Language)是數據庫操作語言,被用來對數據庫執行指令;SQL可以對數據庫進行各類的操作,包括數據庫表的創建和修改;它本身的語法并不復雜,但是用好它也需要不斷學習提升水平。

SQL的學習和使用,可以幫助產品經理進一步了解表結構和表與表之間的關系,從而從數據模型角度進一步理解產品背后的數據邏輯實現方式;另外,可以提升產品和開發之間的理解,減少信息傳遞間的誤解;問題的討論可以當具體到某個表,某個字段,避免歧義;在數據查詢和分析時,了解SQL可以大大方便產品的工作效率和質量。

了解了基礎的開發技術和工具,接著就是操作這些工具的人員之間的分工和合作;產品經理需要了解不同職能分工,在處理開發事項時,快速定位需要溝通的對象,和調整溝通時需要的背景信息。

簡單來說——從技術角度上開發人員分為前端開發,負責用戶所能看到的展示界面,與用戶交互的部分;和后端開發,主要針對服務端,讓服務器、應用程序和數據庫進行交互;雖然職能分工不同,但是工作都是相輔相成的,所以在一些具體實現的時候,會需要彼此平衡技術難度和工作量,達到最有效且精簡的方案。

開發工作進行和完成的同時都需要質量的把控,所以會有測試工程師(QA)這個角色;從字面理解可以看出,這個角色主要是針對開發質量相關工作的。

這里有幾個重要的理念需要強調,就是質量是誰的責任的問題;好比生產汽車的流水線上各司其職在制作產品,每個環節都需要有質量把控,每個人都要對自己環節的質量負責,確保最后的質量檢測的合格達標。

同樣,在軟件產品開發當中,質量不是靠QA最后來測試來發現和確保合格的,而是每個開發人員的本職工作;在規劃對應的產品測試戰略和方法的時候,需要以此為基本出發點來統一協調團隊的認知。

另外就是——質量容錯的閾值;在敏捷開發,快速迭代的理念下,質量測試的力度需要平衡;不能一味的追求極致完美而投入和占用資源而措施戰機,要達到質量把控,也要避免過度測試。

在開發工作過程中還有重要的一組就是數據庫管理員(DBA)——DBA的職能覆蓋從數據庫涉及、測試到部署交付和運維的全生命周期的管理;產品經理需要和DBA打交道最多的就是對應的數據查詢和分析事項;另外在一些產品性能和設計優化上,DBA也是需要被咨詢和聽取意見的人員。

2)基礎設施

產品經理也要對基礎設施有大概的了解。產品的開發過程中和開發完成后的部署都需要對應的基礎設施來支持。

這里涉及到機房、服務器、網絡、路由器、交換機等等相關的軟硬件的概念;在以往的開發發布的環節上,企業需要把完成的代碼打包發布在公網上服務器上,讓外界可以使用;這種情況下,企業需要自己搭建機房和對應的基礎設施或外界租用這些設施;而現在云的迅猛發展,讓軟件產品的開發和發布成本大大降低。

軟件產品開發出來后,企業可以直接部署在云服務商(例如,阿里云、AWS、華為云等)的平臺上;這樣省去了購置服務器和搭建機房的費用,而只要支付流量使用費用,也無需操行基礎設施設備的維護,升級等事項。

簡單的比方就是——以前是每個企業自己買柴油發電機,自己發電,自己用;維護成本高,而且使用率也不是最優;而現在云平臺類似統一接入到國家電網,按使用量付費。

兩種方法各有優劣,而且隨著企業業務發展需求和具體軟件產品的使用情況而變化;產品經理需要知曉這個領域的知識,參與和推動對應的決策和管理影響。

3)系統架構

跳出具體的開發事項的關注,在更高層面來看,無論是已有產品模塊改進優化還是新的產品模塊的引入,首先要做的分析就是其對現有系統架構的影響和適配性。

好比一棟20年的老房子,房屋結構單一,工藝落后;現在突然一家新的住戶搬家進來,決定要加蓋新風系統和電梯;這個時候就需要考慮已有的建筑結構是否能支撐這些新的建筑模塊。

同樣,如果新的產品模塊需要通過新的技術來實現,或者需要采用新的語言來開發,都需要考慮適配性;例如,在移動APP的開發中,新的產品功能時使用最新的Flutter還是原生系統開發,以及開發的產品模塊是否可以適配老的系統框架,和如何使用。

這些技術上的細節決定和討論不是產品經理的專長,但是需要產品經理有對應的敏感度和基本認知,了解這些問題是需要覆蓋的事項。這個對整個產品項目落地和交付范圍規劃都有影響。

4)DevOps 基礎

以上是介紹了基本開發過程可能涉及的基本元素,無論是技術、流程還是參與人員的職能分工;如之前提到的,產品經理對于開發技術需要有一定的敏感度,了解最流行和廣泛的行業實踐,這樣可以與開發團隊有相通的語境和概念框架來溝通。

軟件工程或者軟件開發的方法和理念的不斷演進,與之匹配交付方式和理論也隨之產生;在過去很長一段時間,軟件產品的開發周期較長,每次發布時間之間的間隔也比較遠;因此,周期中的主要矛盾是在需求變更和研發效率上,而發布部署的時間成本和資源占用的成本相比起來不是那么突出。

但是隨著敏捷開發的理念的廣泛推廣實施,和商業環境對產品快速發布部署的要求越來越高,開發和運維一體化,從而達到運維工程師和開發工程師參與整個服務生命周期的一系列實踐被積極提倡。

在維基百科里DevOps被定義為:“DevOps是一種軟件工程文化和實踐,旨在統一整合軟件開發和軟件運維;DevOps運動的主要特點是強烈倡導對構建軟件的所有環節(從集成、測試、發布到部署和基礎架構管理)經行全面的自動化和監控;DevOps的目標是縮短開發周期,提高部署頻率和更可靠的發布,與業務目標保持一致”。

從核心上來看,DevOps是敏捷開發的延續,將敏捷思想和精益的原則在運維領域來實踐應用。

雖然狹義上DevOps只涉及到軟件生命周期,但是它也是一種 IT組織管理的發展趨勢;力圖通過各種方式打破原有IT職能部門之間的壁壘和合作模式,使之行動更加緊密,從而適配和促進業務迭代速度,解決業務痛點。

如下圖所示,DevOps希望做到的是軟件產品交付過程中IT工具鏈的打通,形成良好閉環,使得各個團隊減少時間損耗,更加高效地協同工作,增加整體的產出。

在這里也有一些DevOps經常被使用的工具需要基本了解:

DevOps 被業界快速接受,內涵和概念也不斷延伸。

在各方專業人士的分析和解讀下,DevOps 概念涉及到的知識內容正變得越來越龐大,模型也變得愈加豐富、深入和細分;與理論并行的就是新的架構范式和工具的出現,來支持DevOps的落地和實踐。其中最為火熱和流行的就是“云原生”Cloud-Native。

2015年,Google聯合其他20家公司宣布成立了開源組織 Cloud Native Computing Foundation (CNCF),并且給出了云原生的定義:“云原生技術有利于各組織在公有云、私有云和混合云等新型動態環境中,構建和運行可彈性擴展的應用;云原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。這些技術能夠構建容錯性好、易于管理和便于觀察的松耦合系統。結合可靠的自動化手段,云原生技術使工程師能夠輕松地對系統做出頻繁和可預測的重大變更。

云原生計算基金會(CNCF)致力于培育和維護一個廠商中立的開源生態系統,來推廣云原生技術;我們通過將最前沿的模式民主化,讓這些創新為大眾所用。

這么繞口難懂的定義,簡單概括為4個要素:持續交付、DevOps、微服務、容器。

云原生是一個概念集合,既包含微服務、容器,也包含更多的管理方法,比如持續交付、DevOps和重組等。

以上是針對產品經理的開發技術能力的一些關注的知識點和領域。

需要強調的是——在絕大多數情況下,產品和產品背后的業務才是驅動價值的動力;沒有產品這個載體,再美好的技術也是沒有用武之地。

技術很重要,但是最終的目的是服務客戶;過度的追求技術的完美和先進,而影響了產品的落實和價值實現,這是本末倒置的行為。

產品經理一定要時刻保持全視角思維,跳出當下技術迷思,以商業目標為導向要做抉擇和驅動產品。

4. 項目管理能力(Project Management)

項目管理事項在一些企業是有專門的項目經理來負責,但是,大部分的企業還是會由產品經理來承擔相關的責任;所以具備一定的項目管理能力是一種剛需;同時,通過項目管理的執行,產品經理可以更好的把控和了解產品的開發周期中的狀態,并且積極參與和干預產品開發過程中遇見的挑戰,從時間和資源管理上更好的推動產品解決業務問題的時效性。

5. 瀑布式開發與敏捷交付

軟件行業在上世紀六十年代末提出了“軟件工程”的概念,試圖借鑒建筑行業領域的最佳實踐,來找到適合軟件行業的多人協作開發高質量大型軟件產品的方法;軟件工程的交付理論隨著時代的變遷和外部市場的變化也出現的多樣性的和各異性,隨著時代的遷移和外部環境的變化,針對不同形態的產品或開發任務,可以選用不同的方法——其中最有名的就是“瀑布式”和敏捷交付。

Dr. Winston Royce在主導完成了一個大型軟件項目開發工作后,描述了一種軟件開發模型;在這里模型里包含了:系統需求、軟件需求、分析、程序設計、編碼、測試和部署運行幾個階段;而且各個階段順序相銜接,類似一個瀑布,從而稱之為 “瀑布軟件開發模型”。

這樣的開發方式在一段時間內相當的流行,成為行業的標準;其中很大一部分的原因在于,曾經的軟件開發活動所針對的業務問題相當復雜;而且因為信息技術的成本,只有大型的企業才有資源和能力對軟件開發進行投入;而這類企業,相對來說保守和穩定,注重審批和決策流程,需要的是成熟可靠的交付和管理體系;更重要的是當時的外部環境節奏緩慢,不需要快速反應,需求單一且穩定。

而在互聯網時代,企業外部環境變化極具加快,業務問題和目標需要更快、更敏捷的解決方案來應對;同時,瀑布模型在指導軟件開發的局限也突顯出來, 特別是在對待不確定因數的問題上。

當下,企業講究的是抓住稍縱即逝的機會,低成本的、精益的去落地實現方案,嘗試各種業務探索和試錯;這樣的環境下,敏捷軟件開發這一理念被廣泛采納,用于指導產品的研發事項。

敏捷開發的核心思路是將復雜的需求進行拆分,遵循業務價值高低來安排交付;簡短的開發周期、按照固定節奏開發、按需發布,逐步迭代來實現和優化解決方案;而且不斷的根據內外因素來自我調整。

本質上來說,敏捷模式較好的匹配了當下快速變化市場環境和商業形態;它的指導核心理念是先解決問題、落地方案,雖然初期不是理想方案,后期可以逐步優化;這就和瀑布式開發模型的內在核心理念不同的關鍵。

但是需要注意的是——敏捷開發不是一種軟件開發方法,也不是一個體系完整的方法論;它是滿足敏捷宣言及原則的一組輕量軟件開發方法的集合,是一種開發理念。

下圖展示的是這組集合中最為常見的敏捷流程框架、Scrum:

圖中包含了Scrum里重要的幾組概念:三個角色,三個工件,五個活動,企業可以按照實際情況來調整周期,落地實施。

1)PMBOK

項目管理最常引用的就是美國項目管理協會(PMI)的理論,其在發行的Project Management Body of Knowledge(PMBOK)詳細的闡述了一套項目管理知識體系。

按照PMBOK的定義,項目是為創造獨特的產品、服務或成果而進行的臨時性工作;而項目管理是為了達到項目要求,把知識、技能、工具和技術應用于項目的活動;在最初的版本中,基于的是瀑布式開發模型,但是在最近的版本中,已經開始引入和覆蓋基于敏捷理念的交付該如何進行項目管理活動的內容。

PMI的理論,針對項目管理由5大項目管理過程組,10個知識領域和49個管理流程;在介紹這些事項的過程當中,有大量的工具、方法和工件被介紹。

產品經理可以參考理論,使用這些工具來處理項目經行當中需要處理的事項和問題;產品經理應該不斷熟悉和理解,增加相應的能力。

2)活動拆分和時間表規劃

在傳統的瀑布軟件開發方法中,工作任務的分解時根據活動階段來劃分的。

如下圖所示,產品的端到端開發被切割成不同階段,只有由上一個階段的全部完成才會開始下一個階段,這使得項目產品直到最后聯調測試階段才知道開發的效果;這樣造成業務無法及時驗證產品有效性,而且這樣一次性所有產品點都做,同時開發,沒有主次之分,通常的開發時間都比較冗長,無法面對業務快速變化;業務的重點價值實現的落地被其他低優先級的開發事項拖延。

而從業務視角出發,將一個項目的所有業務需求劃分為多個小的業務功能模塊,每個功能模塊以業務用戶的視角來描述它形成用戶故事,方便介紹和了解背后的業務價值。

需求的拆分是解析一個產品的構成的范圍和內容實質,這一過程中產品經理可以使用MEMC、WBS等方法工具來輔助進行。

用樹形圖的方式,把每個功能模塊模擬成樹枝,然后把每個用戶故事掛在相應的樹枝上。

那么,每次交付的內容,是以業務價值為中心的;通過選擇在不同樹枝上的,高價值和優先級的故事卡片,組成當下迭代里最有業務價值的產品交付;之后再重復這個過程。

這種方式讓業務人員能夠及時得到可以開展業務的產品,獲得市場反饋;同時,給與產品開發團隊實時的反饋,以便于評估開發效果、調整和優化產品、響應市場變化。

支撐這一操作的基本理念是精益思維和敏捷開發,每次上線的產品點總是某一功能樹枝上優先級高的故事卡;因此,很多時候已經上線的功能模塊的并沒有包含全部功能點,這也賦予了產品各個功能模塊及其特性以時間的屬性。

小批量,持續的交付,盡早的獲得收益,加速價值流動——這樣的方式,也帶來了交付的靈活性;一旦外界和業務發生變化,團隊可以快速處理手中的任務,轉向其他事務,同時還可以保證系統的完整性。

需要強調的是——雖然這種開發方式可以快速帶來收益反饋,但是也有成本代價;除了每次迭代后要將開發完成的產品部署到生產環境,還要回歸測試前期交付的所有軟件功能可以正確進行;驗證成本投入會逐步增加。

從微觀來看,每次迭代,產品經理最為需要注意的是把握每次迭代的產品價值,以此為中心來規劃交付內容;而從宏觀來看,2B類型的產品往往比較復雜,且工作量大,需要多個迭代的持續交付來實現的。

有時還會出現某個最小功能集合依然無法在一個迭代內完成的情況,另外,多數產品功能需要跨團隊的配合來實踐;這樣總情況下,產品經理就需要搭建整體產品項目時間計劃表。預先把所有的功能或故事點,按迭代來排期做初步規劃,通過這個項目時間計劃表來統籌各個參與方的節奏和工作內容。

項目時間表的搭建對產品經理有著非常重要的意義。

第一, 在拆分具體項目活動的過程就是同相關參與人員共同交叉確定產品范圍理解,查漏補缺和預估工作量的過程;在此過程中,參與人員可以同步對于開發事項的理解,充分討論需求的邊界上下文,交流初步技術方案的預想,對開發目標、 質量標準和驗收條件達成一致,建立共識;這里也需要用到上一章節講述的產品經理的技術開發能力。

第二,確定開發活動的優先級和事件之間的依存關系,確保每個事項有對應的負責人和完成時間節點;一個事項一定要有對應的負責人,如果需要拆分成多個負責子事項給不同人員,也需要指定出一個總體協調負責人員,避免“人人負責”變成沒有人負責。

第三,項目計劃表的搭建是個反復優化和調整的過程;首先,項目總體時間必須在預先確定的時間范圍內,如果產品總體交付時間超過預期,那么需要針對整體交付產品的范圍和關鍵路徑,特別時分組合作的情況下,進行分析和優化;其次,初次整體產品項目排期的完成,只是反應了當時的產品功能點所蘊含的價值優先程度;基于整體的項目規劃框,動態的秉承敏捷的理念,可以周期性的根據業務價值調整交付物;最后,MVP和精益思維可以用于指導項目計劃表的搭建和優化

第四,項目時間表還承擔了溝通和協調開發進度的作用,產品經理在負責項目管理的時候,可以使用時間表來監控和控制開發進度;因為所有的需求點都是相關人員共同參與討論過的,所有產品經理針對偏離正常進度的事項更加有信心來糾正;同時也給了開發人員明確的時間框架和開發事項,做到責任到人,獎懲清晰。

第五,項目時間表是“活”的,需要產品經理關注和管理;在具體每日的狀態跟蹤事項上,通常開發團隊可以負責和總協調,產品經理需要支持;但是在一些情況下,產品經理也需要承擔起驅動時間表和事項執行的任務,統籌相關事項——這也需要產品經理需要有對應的IT能力和思維,在遇見具體的技術相關事項和執行問題是,產品經理自己有相關的一個初步判斷;通過事項本身對上下游利益相關者的影響,來推導思路;同時,可以積極借用先例處理方法,遵循先例來調整和規劃方案事項。

有時,產品經理需要跳出項目自身資源配置,積極尋求更廣范圍內的資源來支持,例如公司內的技術負責人或者此專項的專家;以結果為導向,保護時間表,保持強的推動力和執行力,確保截止日期內完成相關事項。

在項目管理和交付理念上,產品經理需要由獨立的判斷能力,平衡不同交付方法的使用,以目的為導向,提升能效,解決業務問題;合適才是最好,無需一味追求流行和時髦。

黑貓白貓,抓到老鼠就是好貓。

5. 布道者能力 (Champion)

在這里使用“布道者”這樣一個詞來形容產品經理所要具備的一種綜合能力;英文單詞是Champion,對應的字典解釋是“一個為了某項原則、理想、權力而全力以赴支持、捍衛和奮斗的人”

產品經理參與和推動整個產品生命周期的過程當中,需要面對和處理各種不同的利益相關人員的關系,同時扮演不同的角色;無論是在事項的主導、負責、咨詢、支持或是被知曉的過程當中,產品經理需要時刻都保持者一份champion的意志和責任心。

在產品設計的初期,產品經理需要經行業務調研和商業分析,以期厘清業務痛點,總結和理解業務現狀,開展規劃;在這期間,產品經理需要組織和協調各相關業務部門負責人、系統架構師、技術負責人等,一起規劃產品的功能范圍、定位以及和公司現有產品體系如何融合。

當然,任何新的事物的引入,必然會引發對應的變革和利益調整;產品經理需要站在更高的角度,平衡各方利益,尋找最大公約數和共同利益;推進各個部門之間的配合,力求達到業務和產品之間的匹配;同時又要對訴求的輕重緩急有深刻的了解,產品經理需要搞清楚,在當前階段,哪些功能可以帶來更高的價值,從而引導資源傾向于最有價值的地方。

在開發過程中,產品經理需要緊密配合開發團隊,有些公司會有專職的項目經理負責協調具體開發事務和項目進度的跟進;更多的時候,產品經理需要承擔這一部分的職能,除了具體設計或開發事項的決定外,還需要對產品的遠景和業務價值準確清晰的傳達給相關人員,調動參與人員的內在動力,共同打造有價值的產品。

產品的開發落地不代表產品生周期的結束。產品經理還需要擔當銷售的角色;產品經理需要積極宣傳和推銷相關的產品,游說業務使用產品。

2C類型的互聯網產品通常通過市場運作、運營活動等方式來讓用戶使用產品,實現推廣;而2B類型的產品除了業務的自主使用外,產品經理也需要在各種場合宣講和推動產品的使用,甚至擔當拉拉隊的角色來激發和贊揚對產品推廣使用有益的事項;唯有產品被使用,真實的產品有效性才能被收集,分析和優化,才能達到給業務創造價值的目的。

在這個能力下所包含的各項軟的技能,需要產品經理在日常工作中去分析提煉,通過實踐去打磨和優化。

五、總結

產品經理的工作具有很強的實踐屬性,雖然產品經理總是以創造價值為宗旨,但是所處的環境和產出物的目的是變化的;即——受當下社會市場環境影響,也受偏好、認知、制度、經濟能力等約束的影響。

企業的決策本身就需要基于社會環境這個大背景,這也是為什么一些產品放在今時今日不一定可以取得現在這樣的成功;因為各類影響因素的變換,復用性受情景約束等。

匯總之前所述的要點,可以用下圖來展示B端產品經理的能力要求,以及其在各個產品生命周期中的參與度。

產品經理需要結合具體案例分析相關聯的關鍵變量和約束條件,而不是簡單的照搬。

“學我者生,似我者死”,總結經驗,提煉通用的規律和準則,作為參考和借鑒分析的材料,為打磨個人能力,提升自我做基礎。

因此,雖然這里闡述了一套B端產品經理的方法論和能力架構,但是如何使用在實際操作中,真正的發揮效果,那就真的是“運用之妙,存乎一心”。

 

本文@流蛋 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自 Unsplash ,基于 CC0 協議

給作者打賞,鼓勵TA抓緊創作!
3人打賞
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 給力!

    回復