剛入行產品經理，一定會在網路看到各種產品管理框架，像是北極星指標、User Journey Map、Persona、RICE 評估法、雙鑽石模型，這些框架看起來都可以套用，但實際工作後才發現不是每個框架都可以導入，有些是流程不適用、有些是文化不適用，這篇想記錄我目前產品工作中的框架。
一、產品理論框架為什麼不一定適合
⠀⠀
以下先舉最常聽到的 3 種框架，但根據近期參與的 PM Coffee Chat，真的有導入的產品團隊沒有想像中多。⠀⠀
▍ 北極星指標
北極星指標的概念是「找到一個產品核心價值的關鍵指標，讓整個團隊圍繞這個指標進行產品決策」，以電商相關產品為例，通常會是營收、客戶數、會員數等。
但實際執行時會發現幾個問題：
- 公司做決策有各種情境需要考慮，包含投資人關係、公司內政治問題、客戶問題等，不容易以單一指標作為產品決策準則
- 定義了北極星指標，日常的產品決策仍然會受到各種短期壓力的影響，例如老闆突然要求先做某個功能，或是客戶提出緊急需求。
- 有些公司的產品決策是業務主導，而不是由某個北極星指標主導。
⠀⠀
▍User Persona
用戶畫像是產品課程常見的經典內容，透過 Persona 描繪用戶的年齡、職業、需求、痛點等。
但實際執行時會發現幾個問題：
- 公司很少有資源進行深度的用戶研究，大部分時候你只能依靠有限的數據和假設。
- 滿多用戶輪廓是自己想像出來的，真實的用戶輪廓比想像中複雜更多，且會隨著時間變化。
⠀⠀
▍RICE 評估
RICE（Reach, Impact, Confidence, Effort）評估法看起來很科學，先針對每個指標打分，再計算出優先級。
但實際執行時會發現幾個問題：
- 業務為了要讓某個功能往前排，Impact 會打得特別高分。
- 不同的人對同一個功能可能會給出完全不同的分數，反而花費大量時間在計算和討論上。
- 分數計算後，有些老闆會有最終否決權或決定權，導致可以瞬間推翻計算結果。
⠀⠀
二、公司內部產品評估方式
⠀⠀
在參加了 10+ 場 PM Coffee Chat 之後，發現不同產品團隊的產品評估方式其實大同小異。
⠀⠀
（一）老闆/主管的直覺判斷
在中小型公司或新創企業，產品決策的最終決策權主要是 CEO，通常基於行業經驗、對市場的直覺，以及對公司未來的方向。
這種決策方式雖然很主觀，但根據產品經理們的回饋其實也滿兩極的，很有 Sense 的決策就會帶領公司往好的方向，且因為很果斷，也減少內部大量來回溝通的成本，但缺點是底下的產品經理會變得很像單純執行者。
但也會遇到老闆決策常常一直變，可能對於公司或市場的焦慮，而這類型的產品團隊就會相對辛苦。
⠀⠀
（二）業務需求導向的優先級
B 端 / SaaS 產品的產品方向多半是由業務需求驅動的，業務在面向客戶時，可能會遇到「客戶缺少某個關鍵功能以至於無法簽約」，這時產品藍圖很高機率就是按照業務情境量身打造。
在這種情況下，產品經理的角色更像是一個協調者和執行者，確保時程順暢、且確保開發方向符合業務需求。
這種方式雖然缺乏長期規劃，但能確保產品開發的方向與客戶實際需求保持一致，畢竟產品最重要的商業價值是要有客戶願意付錢買單。
⠀⠀
（三）特定公式的產品評估法
雖然上述提到有些框架不一定適合，但實際上也是有些公司仍透過一些估時的框架在評估需求。
例如 RISE、或是「KA 客戶指標」等，通常都是依照重要程度、技術難易度、影響效益等幾個關鍵指標來綜合評估出一個分數。
⠀⠀
三、常見的產品開發框架
⠀⠀
那各產品開發團隊到底有什麼框架嗎？
⠀⠀
（一）OKR：每人提交關鍵任務
OKR（Objectives and Key Results）之所以是主要的框架是因為它符合多數公司管理的需求，透過大目標的設定，讓各執行者都可以分配和認領底下的任務。
特別是針對產品經理這個角色，KPI 較難公平制定出每個人的指標數字，而 OKR 則相對可以訂出每個人各自目標。
⠀⠀
（二）Scrum：敏捷開發框架
Scrum 也是部分公司會導入的框架，將每個產品線的 BU 化，各自拆成獨立的開發小隊，讓 Product Owner、Scrum Master 帶領團隊往前進。
並透過看板工具以及常見的敏捷會議（Planning、Retro、Refine、Standup）來持續衝刺，達到小步快跑、快速驗證的方式。
可能有些人會疑惑，產品經理到底要學哪些框架？有沒有可以一套帶著走的工具？這也是我目前正在思考的。
⠀⠀
以我目前待過的 3 個產品團隊中，最後落實到真實工作中其實就是：
「需求拆解 → 情境撰寫 → 設計規劃 → 進場開發 → 上線追蹤」
並沒有什麼太高大上的產品流程框架，而是針對每個公司都有自己一套產品 SOP，每位產品經理最後也會收斂出一套自己的工作方法，若真的說不同公司有什麼差異，可能在於：
- 需求進件的權重：有些公司的業務話語權特別大
- 開發團隊的分配：有些產品經理會有專屬開發團隊，有些則是需要共享工程師
- 產品提案的方式：有些產品經理針對一個功能需要層層提案才能通關
- 需求拆解的方式：有些公司對於需求效益要抓的很嚴格
⠀⠀
四、總結
⠀⠀
剛入行產品經理時，一直被各種理論框架吸引，某些框架給人一種「只要掌握了就能成為優秀產品經理」的錯覺，但進到公司才發現都不是這樣使用。
更重要的是培養對商業的敏銳度，深度理解用戶真正的需求，掌握市場動態，具備基本技術概念，建立良好的利害關係人連結，這些「公司內的軟技能」往往會比掌握複雜框架更有價值。
產品管理的本質仍是「解決問題」，包含用戶問題、業務問題、技術問題、市場問題，因此產品經理最終目標是能持續識別真正重要的問題，並找到可行的解決方案。
在工作中要時刻提醒自己：我正在解決什麼問題？這個問題對誰重要？有什麼更好的解決方式？這種問題導向的思維比框架導向的思維更實用。
⠀⠀
如對這系列文章有興趣可以再觀看：
