上一篇《
如何蒐集利害關係人需求,決定產品開發方向|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 流程,剛好套用商業思維學院有提到的黃金圈理論,其實也滿符合現在工作中的流程。
接下來我預計會再分享關於開發的數據判斷、系統性規劃等心路歷程。
如對這系列有興趣,也可以觀看: