【PM總動員】B2B 產品該注意的入門心法，讓 Zendesk PM 用簡單案例現身說法！
【PM總動員】是產品三眼怪的每月定期客座單元，挖掘邀請海內外業界產品開發相關領域的大大們和大家分享！本月邀請到的是目前在 Zendesk 新加坡辦公室擔任產品經理的 YuHsuan 來跟我們分享 B2B 產品的入門心法，她用簡單案例介紹在產品開發上的特殊之處，與身為2B產品經理所觀察「適合2B產品」的PM特質與必備能力。什麼是 B2B 產品？以醫院病例與掛號系統為例
B2B（Business-to-business）軟體即是由本身身為企業的開發商開發供其他企業來使用的軟體。與直接把產品賣給使用者本的 B2C （Business-to-consumer）產品相比，購買 B2B 軟體的企業往往是用這些產品來服務它們自己的客戶（如：面對消費者的電商網站建置服務 Shopify）、或是解決企業內部的需求（如：公司的會計系統 Xero、或是供員工使用的辦公室軟體套裝 Google Suite 等），也因此 B2B 產品客戶方的利益關係人 （stakeholder）與使用者類型（user persona）往往數量眾多。
舉個簡單案例，假設我們做的產品是一個醫院的病例與掛號系統，我想像這個「產品的使用者」將至少有以下幾種：
1. 病患本人（外部使用者）
當病人掛號的時候，這個系統會根據輸入的資訊比對診間的忙碌程度與當班的醫生來決定掛號的順序、並將掛號的結果與看診進度即時顯示給病人。
2. 掛號櫃台的行政人員（內部使用者）
當病人來掛號的時候，這個產品會根據病人的看診資訊來顯示注意事項或任務予行政人員（是否初診？近期是否有危險旅遊史？是否尚有未結清的款項？）。但為了病人隱私，病例的詳細內容與診斷結果不應在此顯示。
3. 醫生（內部使用者）
當病人進入診間之後，醫生必須要能從系統看到病人過去完整的病例、也需要有病例寫入的權限來記錄當天的診斷結果與處置方式。系統應根據醫囑自動分配並通知病人在出了診間之後應該要接著去哪（比方說：醫生決定病人必須接受 X 光檢查，則系統應查出本日最早的 X 光檢查是下午 3 點在本棟的 501 室並通知病人）。
4. 醫檢人員或藥事人員（內部使用者）
當病人來到 X 光室，醫檢師應可從系統檢視醫生剛輸入的本日的病例，並確認今天的檢查範圍與目標為何；如是藥劑師，則他們應該要可以檢閱病人今日的處方與劑量，但無論是醫檢師或藥劑師皆不應直接更改醫生所寫的病歷紀錄，而是應以在系統裡創建新的記名欄位為之。
5. 批價人員（內部使用者）
最後病人來到了批價區，系統應從今日的處置項目來計算總花費，並依病人的保險給付項目或特殊身份補助來計算病人本日的自付額。
5. IT 與行政管理者（內部管理者）
這套系統也需要技術上與行政上的管理。比方說，IT 人員應該要有系統安全與權限管理的功能（如設置院方人員密碼輸入錯誤次數的限制與重設機制、或者是創造與移除新進/離職人員的帳號），而行政管理者則可以在管理員頁面看到使用統計的報表（如本日到院人數、尚未批價完成人數等等）、並更新或建置使用人員的功能與內部流程。
而當一家開發商要把他們的產品賣進一家醫院，在銷售過程中所需要說服的相關的利益關係人（stakeholder）應該至少有以下幾種：
1. 預算來源單位代表（budget holder）
掌控本次購買系統預算的單位，如：財管室的採購主管。
這類型的利害關係人往往最在意安全性與採買正當性的問題，如：你的產品是否有通過使用者隱私與資料安全性的憑證標準？你的資料儲存方式、位址、與災難恢復（disaster recovery）流程是否符合政府或機構內部的法規？本筆採買與參與決策的人員是否有可能的利益衝突？你的產品功能與市面上其他產品相比如何、價格上又相差多少？是否符合本單位的預算編列？
2. 產品購買後的管理單位代表（administrator）
通常是「本產品的主要價值或所要解決的問題」目前的負責人、也往往是本次採購客戶內部的主要推動者。如：醫院資訊室主管發現既有系統維護不易，故主動發掘並推薦取代產品、或提議公開招標。
由於這些人是這個產品日後的主要管理者、同時也是對未來需求的新增與規劃最了解的人，這類型的利害關係人會很在意 B2B 產品的功能性、可擴充性、穩定性、可配置性（configurability）、與可以讓他們用來監測與改善產品使用狀況、以及向上級證明這個產品的確有為內部帶來正向幫助的報表或分析（report & analytics）功能。
3. 使用者代表 （user）
如預算掌管者想要評估本次採買是否確實必要，他們可能會聽取內部使用者代表的意見；採購的提案者亦常聯合內部使用者代表來共同爭取並佐證該筆投資的必要性與迫切性，而外部使用者的意見則常以使用者回饋/評比或是問卷的方式來呈現。
使用者代表可說是最常貼身使用 B2B 產品中絕大多數功能的人，也因此他們對於產品 UI 的美觀與易用性、功能流程的合理性、以及會對實際操作上產生困擾的畫面或存取的延滯性（latency）非常敏感。
B2B 軟體開發的特殊之處
縱觀以上，從產品經理的角度來分析，我認為 B2B 產品最大的特點為：
1. B2B 產品的購買者 (customer)，往往不是買進產品後最高頻率的使用者 (user)
以上述所舉的掛號與病歷系統來說，儘管每天真正在使用這個產品的人是醫生與批價人員等人，真正掌握預算並有權力決定購買與否的利益關係人卻是預算來源的單位代表。這也就造成了在某些 B2B 產品裡，底層內部使用者的 UI/UX 往往並不像在 B2C 產品中般受到重視。
2. B2B 產品的使用者類型有好多種！而產品經理也通常不是自己產品的目標購買者或使用者
從上面的例子我們也可以看到，這裡有超過六種的使用者 persona，而每種不同的使用者都有不同的功能需求與存取權限（這在任何一種 B2B 產品裡都很常見）。身為一位在客戶行業外部的產品經理，我們並不適合、也不應該以自身的生活經驗來當作產品設計的依據，而應該以確實的產品研究與客戶訪談來了解這個產業的客戶想要的是什麼；而針對特定的單別客戶，他們特殊的內部工作流程 (workflow) 與業務邏輯 (business logic) 又是什麼。
3. 非常直覺的獲利模式、與在主產品之外的加值收費
儘管在使用者與利益關係人的部分較多數 B2C 產品複雜許多，B2B 產品的盈利模式倒是非常單純：購買者/使用者付費。
以商用軟體服務來說，幾種常見的收費模式為：
- 賣斷式（outright sale）
產品開發商在針對客戶的需求調整既有產品/量身打造產品之後，以一次性的建置費將產品交付給客戶、並只負責保固合約內產品交付時應包含的功能。 - 產品授權金（licensing）
這個模式最常見於需要下載安裝並輸入產品金鑰的產品。通常合約的價格取決於開發商與客戶約定的授權期間可安裝產品的裝置數量與可使用的期限，並在使用期間提供可安裝的產品更新與改善。 - 訂閱制（subscription）
在可以隨時以網路存取並更新的 SaaS (software-as-a-service) 問世之後，訂閱式這個有趣的商業模式也隨之跟著出現。因為產品的邏輯與使用者的資料都是儲存在雲端、可隨時更新，這也提供了讓客戶可以彈性增減購買的使用者數量、與隨時付費取得更多功能的可能。常見的訂閱制 SaaS 收費模式為「（所選的功能等級價格）/ 每月 / 每位使用者」，例如：入門版的收費為 5 美金 / 每月 / 每位使用者，而功能更多的企業版則每位使用者每月需付 30 美金。
而在產品本身的收費之外，開發商也可提供加值服務來增加收入：
- 針對客戶使用頻繁的某些功能推出「加強版」或「增量版」（add-on），例如：需另外付費使用的特殊 API、或者是超過一定數量始得付費的第三方插件。
- 提供以專案或小時計費的顧問/專業服務（professional service），來滿足客戶對客製化功能或跨系統整合的需求。
- 客戶訓練費用，例如提供課程或工作坊來幫助客戶內部使用者學習如何使用你的產品。
4. 更低的產品更新頻率、更長的規劃與開發時程
B2B 產品不管是在銷售、導入、甚至是在培養使用者的熟悉度方面都比多數 B2C 產品來得複雜且緩慢，而 B2B SaaS 產品最高價值的客戶群往往也是在產品中設置最多複雜的內部工作流程、甚至是客製化功能的群體。
因此，在規劃新的功能時，產品經理除了確保自己的產品藍圖與公司策略一致，更必須審慎考慮自己所設計的新的更動是否會影響客戶既有的商業邏輯？又該次的更動，會不會讓客戶需要對底層的內部使用者提供新的 SOP 與教育訓練？此外，B2B 客戶非常重視產品的穩定性與可靠性 — 該功能在被推出之前，是否有被確實地經過功能性測試與壓力測試的考驗？以上種種都造成了在 B2B 產品的開發上，功能規劃與更新的頻率不比 B2C 產品來得快捷靈活。
5. 產品功能開發完成並不代表事情就做完了
由於對於功能性與可設置性的重視大於對於 UI/UX 的重視，B2B 產品的功能常常並不如 B2C 產品般的直覺，因此在新功能的開發與測試完成之後，我們並不能夠就直接將它釋出到客戶的版本中，然後指望多數的使用者會自己發現並學會如何使用這些功能。除了好好完成開發記錄文件並根據客戶使用狀況與回饋來改進功能之外，B2B 產品經理應該密切地跟產品行銷經理 (product marketing manager) 合作，並確保這些新功能有在各個管道裡被適切地宣傳與解釋：
- 面向客戶的公開管道：產品價格表裡是否有標示這個功能只對哪個特定付費等級的客戶開放？本功能的目的與使用情境 (use case) 為何？客戶該如何導入這個新功能？當他們遇到問題時，是否有公開的文件可供自助障礙排除？
- 面向客戶的非公開管道：開發商的銷售團隊是否充分了解這個功能的使用方式與銷售價值？銷售人員是否能夠回答這個功能與競爭對手相似功能的異同之處？我們是否有已建置好並啟用本功能的 demo 帳號供銷售團隊在客戶開發時使用？開發商內部的客戶支援團隊是否知道這個功能即將上線、且已經接受過如何針對這個功能來進行障礙排除的訓練？
以上種種皆是對 B2B 產品經理換位思考與溝通能力的考驗。
什麼樣的人適合擔任 B2B 產品經理？
我認為，無論是什麼產業背景的 PM，都應該至少擁有以下的基本能力：
- 卓越的溝通能力
- 與工程師、設計師、以及分析行銷人員合作良好的能力
- 了解市場與客戶需求，並用以堆動產品設計與策略規劃
- 擅長設計並執行客戶及使用者研究
- 知道如何以資料來產生假說，並設計良好的實驗與分析來達成結論
- 強大的使命感，與專案管理、寫文件與召開會議的技巧
然而，除了這些基本且通用的產品開發能力，B2B 產品經理的確也需要特別培養以下的能力：
- 一流的提案能力與說服技巧，以達成組織對產品願景及藍圖 (roadmap) 的認可 (buy-in) 與取得執行所需的資源。
- 極為強大的上下游依賴關係 (dependency) 管理、與信心（風險）評估的能力。多數時候，B2B 公司會對客戶分享產品未來幾個季度 (quarter)、甚至是多達 12~18 個月的功能規劃與上線時程。產品經理需要具備極強大的風險評估與執行能力來確保功能如期交付。
- 非常嚴格的優先級策略 (prioritisation) 原則與取捨 (trade-off) 能力，並搭配以強大的論證能力來說服利害關係人什麼事情現在該做、什麼不該做。
- 儘管在公司最大的客戶面前，也有勇氣與懂得如何向不在產品策略、或現有優先級上的要求說「不」。
一般來說，B2B 軟體公司比較傾向招募產品開發經驗較為資深、且有相關背景的產品經理（如：Salesforce 的這個職缺要求五年以上的直接相關經驗），而較少有招募應屆畢業生、或是大幅度跨產業求職的資深應徵者來擔任核心產品經理的情況。但是，對於有心進入 B2B 產品管理的人來說，以下皆是可以逐漸切入 B2B 產品管理的管道：
- 加入公司的內部工具 (internal tools) 部門
例如：儘管身在以 B2C 為主的電商公司，但內部負責「賣家支援」或是「金流系統」的部門與 B2B 產品公司的運作方式會相對接近。 - 加入 B2B 公司的非產品部門，並尋找機會內部轉調
以筆者所在的美商 Zendesk 來說，不乏有從產品分析 (product analyst)、專案管理 (program management)、軟體工程、甚至是產品客服 (advocacy) 部門申請轉調成為實習產品經理、或是助理產品經理 (associate PM) 的例子。而公司內部也有不少厲害的資深產品經理當初是由這樣的背景而來。 - 加入較小型或較早期的 B2B 新創公司
比起產品已經非常複雜、而客戶組織已經太大的企業型 B2B 軟體公司，較早或較小的 B2B 公司產品功能與客戶方的利益關係人 （stakeholder）及使用者類型（user persona）會相對精簡，對於對 B2B 產品管理有興趣但尚無相關經驗的應徵者來說，會比較容易受聘進入。
結語
由於 B2B 的產品非常重視前期規劃與內部產品策略討論，B2B 產品經理對於自身所在的產業趨勢、既有客戶特性、公司產品區位、近期與中期策略、與內部利害關係人管理皆必須有一定的掌握，且應具有在公司內部有效提案及溝通說服的能力。
而 B2B 產品功能的增加與改進來自於深刻的客戶需求分析與市場洞見：產品經理應培養客戶洞察與訪談的能力，並確實瞭解不同客戶內部產品使用者的需求、客戶所服務的客戶的需求、以及客戶內部決定產品採購的權力架構與決策流程（於此，公司的銷售與客戶支援團隊常是你最值得合作搭擋的對象）。
你可能也會有興趣 B2B 產品開發相關文章：
感謝閱讀，如果希望看到其他相關的主題也歡迎留言 📔如果你想看更多海外產品經理的分享，請給我 1–19 個拍手；
如果想看更多關於 2B 產品管理的內容，請給我 20–50 個拍手！
如果文章對你有一點啟發或幫助，請長按拍手按鈕（max50）讓我們知道 👏每週末我們都會在 產品三眼怪實驗室 (◉◉◉) 定期更新產品經理相關文章，
別忘了追蹤才不會錯過！
