上一篇《如何蒐集利害關係人需求，決定產品開發方向｜EP3》提到在從彙整產品需求，到決定產品開發順序的流程，接著我將繼續以一個產品專員的角色，來記錄產品開發的關鍵決策點，這篇會包含 (1) Why 為什麼我們要做這個產品、(2) How 我們要透過什麼方式傳達價值、(3) What 我們要透過什麼功能達到目標。
以下產品需求的舉例，會使用我服務的群眾集資平台為例。
誰適合看這篇文章？
✔ 對於產品開發、產品規劃、產品管理、產品策略有興趣的朋友。
圖片來源：商業思維學院《產品經理學程》
一、Why 為什麼我們要做這個產品
在接收到外部產品需求時，常常會收到各種對產品的期待與想像，例如產品型專案的客戶希望有更方便的購物車、更隱密的隱藏賣場，又或是社會議題型專案，希望有每月定期定額的客製化扣款、更客製化的加購商品流程。上述需求有些會跟我們（產品經理 PM 們）制定的 Roadmap 類似，但更多是 Roadmap 以外的需求，通常是為了滿足當下單一客戶的許願，因此身為產品決策端，就需要時時檢視：
我們是否要做這個功能？我們為什麼要做？跟 Roadmap 方向是否一致？Roadmap 是否要調整？這個功能做的好處是什麼？不做會有什麼壞處？
因為目前平台剛成立一年，變動較大，產品方向有時每一季就會微調，連帶原先規劃的 Roadmap 方向，開發順序也要跟著調整，因此在評估產品需求時，也要確認：
這是少數客戶的需求還是多數客戶？市場的客戶需求是否有更動？
以我現在的狀況，在評估產品需求的階段一直都佔工作不少時間，因為不只是要「確定需求方的最終想解決的問題」，同時也要確認「此功能做與不做的影響層面」，特別是牽一髮動全身的全站式功能，例如修改報表欄位、修改訂單資料檢視欄位、修改查詢功能，這些都會影響到平台上所有的使用者，包含公司內成員、客戶、甚至贊助者。
小結，在初期的 Why，針對一個產品開發與否，我會先確認：
- 真實問題：該需求最終想要解決什麼問題？
- 替代方案：現在是否有替代方案可解決？如果沒有，為什麼其他功能無法先替代？
- 影響層面：該需求會影響到的層面深度？例如下單流程不順暢、無法有效管理售出數量？
- 需求比例：該需求是多數客戶都有抱怨過的痛點？還是因應少數客戶的特殊情境？
- 功能效益：若成功開發完，具體而言可以為客戶、公司帶來什麼價值？與更多類似的客戶簽約？提高客戶營業額？
二、How 我們要透過什麼方式傳達價值
有了第一大點的 Why，接著就要來說明如何執行，以我擔任客戶成功專員的輔導經驗，很多團隊都期待產品開發可以解決所有事，因此很多客戶只要遇到專案操作問題，第一時間都會說「請你們的工程師幫我寫一個 code 來解決」、「這個只要工程師改一個按鈕就可以解決」。
但實際上，工程師不可能幫每個客戶製作專屬的功能，正常平台營運下，應該是先用現有功能來解決客戶問題，除非遇到大客戶、或是發現平台本身就存在的 bug，不然都不應該隨時呼叫工程師協助。
在黃金圈的 How，我的思考脈絡是：
- 解決方式：除了工程解，有沒有其他解法？像是工人智慧、人力拆解、與其他 Google 雲端工具協作。
- 利弊權衡：使用非工程解的方式，是否會讓結帳不順？或是操作流程可被接受？
- 需求多寡：若少量專案才有的需求，用人工拆解還可以負擔，但若很多客戶都有相似問題，就有可能是系統本身需要優化。
- 開發方向：若上述評估完，真的需要請工程師寫 code 來解決，那就準備進到評估階段，確認要製作什麼功能來解決問題。
三、What 我們要透過什麼功能達到目標
思考完 Why、How，最後才是 What，在我過往產品規劃的經驗，有時因為前面思考不周，導致最後想出來的 What 過於突兀，想開發的實際功能跟 Why、How 無法串連起來，導致跟需求方來回溝通多時。
因此在決定 What 時，仍需要不斷跟需求方保持良好溝通管道，時時確認方向是否是對方需要的。
在黃金圈最外層的 What，我的協作方式是：
- 定期檢核：在最初的需求盤點，產品經理開始畫 wireframe，都需要與需求方確認方向，特別在 wireframe，其實就能確認想像的功能和規劃的畫面是否一致。
- 多方訪談：除了原本的需求方，若功能會牽涉到多方利害關係人，也要確認是否會影響到。
- 時程規劃：因為每一季／月都會有功能順序的調換，因此在開發階段，仍需要向原需求方確認期望的時程，確認是否需要提前，或是可以延後。
四、總結
這篇主要也是記錄我在判斷一個功能到底要不要開發的 Why-How-What 流程，剛好套用商業思維學院有提到的黃金圈理論，其實也滿符合現在工作中的流程。
接下來我預計會再分享關於開發的數據判斷、系統性規劃等心路歷程。
如對這系列有興趣，也可以觀看：
