初階產品經理的產品決策：風險控管與項目拆解｜EP44
產品經理規劃產品功能會經過哪些流程？要如何制定產品決策？過程會有哪些顧慮？這篇想記錄我近期在工作時的產品心路歷程。
誰適合看這篇文章？✔ 對產品經理、產品企劃、產品策略、產品規劃有興趣的朋友一、公司的產品決策
⠀⠀
在每個開發周期的初期，通常公司都會布達每季、每年的產品走向，並訂出每一條產品線要做哪些功能／專案，再由產品經理認領來規劃。
以下圖為例，產品經理收到需求是「Epic 專案」維度，接著再由產品經理往下拆分成各項 User Story，最後由開發團隊／工程師們協助拆成具體的 Task。
⠀⠀
但往往執行過程中，會不斷收到新的產品需求，以 B 端產品來說，常見的新需求來源像是：
- 潛在客戶需求：潛在客戶就是有意願簽約，但可能希望產品有 x、y、z 功能才會正式簽約。
- 現有客戶需求：現有客戶就是簽約中的客戶，但因為商業情境轉變，導致新的需求是現有產品無法滿足的。
- 業務部需求：業務們根據開發經驗、以及收集各項客戶建議，綜合提出最大公約數或符合最大效益的需求。
- 客戶服務部：客服收到第一線使用人員的反饋，提出的使用者優化建議。
⠀⠀
根據上述的產品需求來源，每個產品線會再加入很多產品代辦清單（Product Backlog），這時會加入決策因素：
- 大客戶需求：AM、Sales 確認是否至少解決某個大客戶或多個中小客戶的需求，要確保做這個功能是有足夠大的效益。
- 使用者場景：AM、Sales 確認客戶想解決什麼問題？是什麼情境會需要的需求？
- 時程急迫性：AM、Sales 確認這個功能需要在什麼時候完成？是否有特定檔期要使用？
- 可行性評估：PM、RD Leader 進場確認技術上是否可行
- 顆粒度評估：PM、RD Leader這個功能要花多少工時、Sprint 才能完成？
- 風險性評估：PM 評估是否會排擠到現有安排的開發進度？會導致哪些功能延後？
產品決策：凡事都有代價，做決策前做好風險控管，投入 A 就代表 B 會暫時被延後。
⠀⠀
⠀⠀
二、產品經理的產品決策
⠀⠀
準備要開始規劃時，產品經理還會有更多細部決策，如下圖，像是一個專案收到後，會拆成 3–10 個使用情境。
接著要先確認這些使用場景是否都有滿足客戶需求，因為有些場景列完可能會跟客戶原本提出的期待有落差、或是誤解客戶意思，因此 PM 需要不斷與 AM 確認。
若每個情境都確認完畢，以我目前的工作經驗，開發順序會依照「功能相依原則」來進行，先確認哪些功能有前後相依，例如一定要做 A 的後端需求才能做 B 的前端需求，這個過程會不斷和工程師確認，才會正式定下每周的開發內容。
⠀⠀
收斂到每天的工作內容，PM 會需要：
- 確認場景目標：列出一個個 User Story 後，先確認要解決使用者的哪一個情境。
- 確認客戶需求：列出 User Story 後，不斷和 AM 確認需求是否滿足客戶需求。
- 確認流程畫面：自己畫出使用者操作步驟，確認從 A 點到 B 點的路徑是否順暢（有些公司會是交由 UX）。
- 確認執行細節：和 RD 確認每一張 User Story 、每個流程的開發工作項目，並確認是否有技術不可行的地方，或是前後端開發順序問題。
都確認完畢後，就會進到產品規劃階段，一步步將需求落地。
三、總結
這篇主要先整理過往我在參與產品決策的心得，有些還不完整，但我期望能陸續將成長心得記錄下來。
好的決策力，代表要盡可能每次都做出正確決策。⠀⠀
但沒有人會故意做錯決策，所謂「不那麼好」的決策通常是執行了一陣子，大家才發現方向似乎偏離，這時根據偏離角度進行調整。
因此除了訓練決策力之外，我認為身為產品經理還需要加強的是當機立斷的判斷力，當發現產品怪怪的要馬上舉手，確保產品時時保持在相對正確的方向。
會說「相對正確」是因為我也還不確定什麼是「絕對正確」的產品路線，實際上產品決策也會夾雜各種價值觀、生活體驗、工作經驗，偶爾我也會對使用者操作方式感到困惑、對自己的產品知識感到匱乏、對客戶的認可接受感到驚喜，或許這也是近期喜歡做產品的其中一個原因 ：在一個不確定的環境定義方向。
⠀⠀
若對這系列有興趣也可以持續觀看：
你可能也想看
