陰錯陽差加入現職公司、成為內部產品的 PM 已滿兩年，但在網路上似乎看不到太多關於 internal product manager 的分享，所以這篇想聊聊 2C vs. 2B vs. internal PM 的差別。
另外，之前已有寫過一篇文章介紹內部產品 PM 在幹嘛，現在回過頭看，覺得依然頗符合現狀，有興趣的人可以先看這篇〈負責內部產品（Internal Product）的 PM 都在幹嘛？跟 to B/C 端產品有什麼不同？〉，對「內部產品」會更有概念。
在深入介紹「內部產品 PM 與其他產品類型 PM 的差異」之前，先分別簡介 to C & to B PM 的工作重點。
註：以下對於 to C & to B PM 的技能重點簡介，原始資料來自於個人經驗、多篇網路文章與某些公司的 JD，可能無法完全符合實際情況，如有任何差異處，歡迎留言指教。
2C PM 技能重點：
- 數據與驗證：A/B testing 與快速迭代
- 差異化：品牌風格、整體視覺、介面功能等
- 市場嗅覺：怎麼吸引潛在使用者、怎麼拿下這個領域
- 同理心：帶入使用者角度思考、自己可以成為使用者
2B PM 技能重點：
- 產業知識：對於特定產業、領域或職能（如：HRtech、Edtech、payroll、CMS 等）的熟知程度
- 專案管理：從瞭解企業客戶的需求，一直到協助企業客戶導入產品，甚至可能還有後續的服務（視公司規模與分工而定）。
- 時程管理：若產品團隊的公司（某方面來說很像是乙方）有和企業客戶簽約，或者有特定壓力（如：該客戶是主要業績來源、該客戶是大客戶，能成為重點成功案例），最後很可能演變成開開團隊的時程壓力。
internal PM 技能重點：
- 產業知識：內部產品也有很多種，以職能或用戶屬性來分，可以粗略分為：人資用的、財務用的、工程師用的、設計師用的、行銷用的……等。以用途來分，則可以分為：公文流程、請假、請款、HRIS、OKR、通訊（比如 Slack 早期是內部使用，後來才對外販售）……等。
- 專案管理
- 時程管理
- 利益關係人管理：正因為內部產品的種類繁多，用戶組成也很複雜。可能有高高在上的老闆、某些不懂技術的高階主管、懂技術所以會給很多想法的其他工程團隊同事。內部產品 PM 需要切換不同的「語言」，找到這些用戶能理解的方式，才能和他們溝通。
- 彈性 / 接受改變：公司之所以會有內部產品團隊，多半是因為有高度客製化的需求，所以不想（或者不能夠）使用外部的第三方工具。也因為如此，需求端開出來的需求千奇百怪，很多時候翻遍市面上的競品也找不到類似的功能。又或者產品終於改版完成，但礙於公司內部的政策或新方針，很可能要隨之且馬上修改，內部產品的開發團隊應變能力要很強，心臟也要很大顆（也要很任勞任怨……）。
身為內部產品 PM，最困難的 5 個挑戰是：
1. 優先排序＆敏捷開發
在網路業鼓吹「敏捷 (agile)」的同時，內部產品卻很難做到這件事。對於變現 / 營利為首要目標的 to C 產品來說，「快速驗證市場需求」非常重要，所以才會有 “MVP” 這個概念。至於後續的迭代，多半也是「先求有再求好」，幾乎凡事都得看使用者反應才好決定下一步，於是也有了 A/B testing 這樣的做法。
但內部產品通常並非如此。畢竟內部產品的用戶可能是 PM 的同事，但更有可能是主管或老闆，怎可能把他們當作測試的對象？所謂的「80/20法則」也難以帶進團隊，即使產品已經顧及了 80% 的使用情境、已經能滿足絕大多數的使用者需求，但只要沒有滿足「關鍵使用者」（aka 老闆或某個高層主管）的情況 — — 不論這個情況多稀有、多罕見，甚至是多不合常理，那這就不是一個合格的內部產品了。
曾經作過 to C 產品的我，也想把「小步快跑」、「快速迭代」這樣的概念帶進團隊，但卻遭遇了「水土不服」。產品在迭代或後續維運時，通常會側重功能的使用效率和實用性，但也常接到來自主管或老闆的反應，希望某個文案要調整、某個 icon 意思不夠清楚、哪邊應該加個 tooltip 加強說明……，並且會要求「盡快改好」(ask ASAP)。
這些小東西並非不重要，但通常被處理的優先順序不該那麼高。然而，在內部產品團隊，優先順序不一定能完全用 impact + effect 衡量，有些東西可以很快做好、做完後絕大多數使用者也會很有感，但這些東西不一定能成為第一優先開發功能。為什麼？因為老闆不是「絕大多數使用者」。
作為 PM，自己以前在做 to C 產品時，有些決策也曾被老闆的指示或偏好干預過；但相較於做內部產品，內部產品的「被影響空間」還是多太多了。
2. 創新 vs. 造輪子
公司之所以要搭建自己的內部產品，而非使用第三方工具，很大一部份是有資安考量，另外也可能是為了後續整合與使用方便。
比如公司有自己的人資系統（HRIS），後續如果要考核、紀錄出缺勤、出差報帳等，員工資料都得從 HRIS 來。這時如果這些系統也從內部搭建，資料整合通常會比較方便，且也較不擔心資料外流。此外，後續若要再做延伸功能或客製化功能，內部團隊一定也會比外部團隊來得方便溝通。
看完上述情境，許多人大概會覺得「那公司搭建自己的內部團隊去做內部產品」，應該是非常合情合理吧？
但若回到產品本身，公司如何定義這個「內部產品」就很重要。有些現在的外部產品，其實是從內部產品起家，比如企業通訊應用程式 slack、OKR 管理工具飛書 OKR，據說 JIRA、zendesk、trello 也都是如此。
「只給內部使用，專注符合內部需求」、「只給內部使用，後來意外發現有擴大成為 to B 產品的潛力」、「先給內部使用，但終極目標是成為 to B 產品」，這三種目標都很合理，但他們非常不同，對應的做法也很不同。
(1) 只給內部使用，專注符合內部需求：
- 優點：團隊的目標清晰
- 缺點：團隊可能較不易有成就感，因為市面上可能也有類似產品，會有種自己在重複造輪子的感覺
(2) 只給內部使用，後來意外發現有擴大成為 to B 產品的潛力：
這個情境比較算是無心插柳，並非刻意為之，所以優缺點得視時間而定。如果是內部使用時期，優缺點與上述類似。如果是後續擴大成為 to B 產品時期，優缺點則與下段類似。
(3) 先給內部使用，但終極目標是成為 to B 產品：
- 優點：團隊較易被這種「挑戰性」與「產品潛力」驅動
- 缺點：若初期沒有明確的產品目標，走到中期很容易迷失
在初期階段，這類產品必然先以符合內部需求為主。但要做到什麼程度呢？內部若有特別客製化的需求，產品應該要做嗎？如果想要推到外部，前期是否需要搭配行銷或業務團隊一起思考產品定位呢？當內部需求與市場分析結果不一致時，該以哪個為主呢？
這都是內部產品若想要轉型或想要「身兼」to B 產品時，很可能遇到的問題。
3. 難以界定產品成功指標
內部產品的北極星指標通常與「人」（DAU、註冊用戶、retention 等）或「錢」（轉換率、ARPU 等）無關，而是得滿足特定使用目標或「降本增效」。比如團隊在導入該產品後，省下多少手動時間、減少多少時間或人力的資源浪費、完成某件事情的時間縮短多少等。
然而，也有產品難以用這個方式定義其成功與否。比如：
- design system：大家都知道若企業內部有一套 design system，設計與前端的工作效率會大幅提升、不用每次都從零開始做某個元件。但要怎麼衡量這個 design system 的成效呢 — — 是元件數量的覆蓋率？（但越多=越好嗎？且這個指標很容易成為數字有增無減的虛榮指標）該系統的使用率？（但如果是公司強制規定使用，使用率就是沒有意義的指標了）導入該系統後省下多少時間？（但誰會真的去計算使用該系統前，做一個畫面要多少時間呢？）
- 通訊軟體：同上。內部之所以想自己做通訊軟體，可能是資安 + 效率 + 整合考量，但這幾個面向又該怎麼衡量呢？資安程度更像是技術指標，而非產品本身的北極星指標；效率也很難計算；能整合的系統數量容易淪為虛榮指標。
- 考核工具：比起前兩者，考核工具重視的是「人資使用時的效率」與「考核結果的品質」。如果一味以效率為唯一指標，反而本末倒置。但又該如何控制品質呢？「品質」真的是產品本身作為平台時，能夠控制甚至優化的指標嗎？
上述這些都是內部團隊在制定指標時，很容易遇到的挑戰。
4. 多工的 PM
作為內部產品的 PM，很可能要身兼以下角色：
- 客服：內部產品團隊不太可能有專門的客服人員，使用者若有問題，通常會直接找 PM。
- 業務：PM 可能要背負「將內部產品推廣到其他部門、增進內部使用率」的目標與責任。
- 行銷：內部產品團隊也沒有專職行銷人員，所以如果要從零到一規劃產品、產品上線或產品轉型等，PM 依舊是主要負責人。
- Account manager：通常中文應該會翻譯為「客戶經理」，可以想像成是第一線面對企業客戶或需求端的角色。在內部產品團隊，人力有限且分工不講求精細的情況下，通常 PM 也會是和利益關係人（主要使用者的代表窗口）對接的角色。
像我負責的某個目標訂定工具產品，從用戶使用指南、上線後的內部宣傳、產品介面的文案，到近期的產品轉型規劃、協助其他事業體導入並試用該產品等，都是由 PM 一手完成。
5. 保持彈性、接受改變
不管是做什麼產品，許多公司對 PM 的軟技能要求之一就是 “Able to deal with ambiguity”，也就是要有處變不驚、面對模糊或全然未知的能力。
做 to C 產品時，自以為已經面對過什麼叫做「瞬息萬變」，畢竟消費者需求與市場趨勢變化萬千，這也使產品需求隨時都可能改變，只要需求一變，對應的作法與時程也會變。
但做了內部產品後，才知道不只這些，另外兩個會大幅影響 PM 工作效率與心情的變因就是「窗口」與「產品」本身。
我的同事到職一年多，對接的需求端已經換了不知道第幾個。好不容易跟第一個窗口混熟，終於搞懂對方的做事方式，也談定了下一季的需求，結果窗口突然離職。第二個窗口到職後，所有前置作業打掉重練，這份工作彷彿經歷過搬家，來到了全新的環境，還得面對全新的鄰居。過了幾週，需求終於再次喬好，但該團隊空降新主管，新官上任三把火，想做出一些成績，所以談好的需求再重來一次。
另一個同事花了大把精神做好某個產品，上線後不久，因應內部組織調整與政策變動，大老闆決定把這個產品砍掉。團隊得知後士氣低落，但對外只能說「階段性任務完成，產品功成身退」；私下聊起，大家也只能苦笑地想說：「當初規劃時，怎麼不先想清楚」。
結尾
綜合以上，身為內部產品的 PM，若要說優點，內部產品可能相對是一個穩定的團隊，畢竟是因應公司需求而生，所以公司在團隊在、公司倒團隊才倒。相較於其他外部產品線會因為虧損而直接滅組，內部產品團隊可能比較不容易有人員上的異動。
但當然這也只是「大致上」，如果碰上不景氣，人員縮減或凍結擴編也是很有可能的事情。
另外，如果做的不是太受老闆關注、老闆並非主要使用者的產品，發揮空間通常較大，PM 可以更不受限制地規劃方向與時程；但這個也一體兩面，畢竟老闆若不太關注，也可能代表 PM 較難爭取到對應的設計與開發資源。
至於缺點，上面應該說了不少，不再贅述。
最後，上述工作經驗一定無法 100% 代表所有網路公司的內部產品團隊，但應仍有一定程度的代表性，畢竟每個案例都是充滿血淚的真人真事……。
相較於外部產品面對的是「市場」（大環境），內部產品顧名思義就是服務「內部」，內部產品既然得面對「公司」（人、政策），那就容易牽涉到公司本身的權力結構、位階、公司的營運政策與方向，因此，不少時候會需要做出（可能）與理性或商業思維沒那麼相符的決策。
不過，整體來說，個人認為做內部產品的 PM 和其他產品 PM 的核心能力並無太大落差，一樣要懂得思考方向、規劃產品、安排時程、調度人力，與人合作時也要重視團隊溝通、分工、發揮同理心、協調與談判。
這篇心得暨觀察文就先寫到這，如果在看這篇文章的你剛好也在做內部產品，歡迎留言分享或來信交流！
