上一篇《
產品管理的首要任務,重視每位利害關係人》提到各種利害關係人的應對,這篇將接續分析這些利害關係人會如何影響產品策略、產品定位,包含,包含 (1) 產品定位、(2) 產品開發目的、(3) 產品需求順序。
這次的紀錄比較不一樣,因為我主要是列出思考的難點,但不一定會寫出答案,有些正在內部討論中,因此無法對外公開。
誰適合看這篇文章?
✔ 對於產品開發、產品規劃、產品管理有興趣。
一、產品定位
以我目前所在的群眾集資平台來說,平台的使用者分成 Business 端的提案團隊和 Customer 端的贊助者,第一個問題來了。
問題:請問平台首頁應該要以 B 端提案者為主?還是 C 端贊助者為主?
如果是提案者為主,首頁就需要更多廣告曝光版位,讓各個提案團隊都有更多機會被曝光;壞處就是贊助者會覺得逛首頁很有壓力、很促購導向。
如果是贊助者為主,首頁就要以最符合瀏覽的版面去排版,有可能會更精簡,甚至加入一些內容,像是文章、影片等;壞處就是能給提案者的直接購買的廣告版面就會變少。
上述剛好是團隊內部常會遇到的問題,以業務層面的話,會希望有越多廣告版位當籌碼,在洽談比較有招可以出;以行銷層面的話,會希望以首頁流量、轉換率、整體品牌視覺為優先。
這時通常會有個疑問?難道不能取個平衡點嗎?讓首頁剛好滿足 B 端想要的廣告版位以及 C 端消費者體驗。
理想上應該可以,但目前還在抓兩邊的平衡,同時,現階段因為成本考量,沒有特別做 A/B test ,因此在開發功能時還沒辦法用測試的方式去看 A 版本(多一個廣告版位)跟 B 版本(少一個廣告版位)到底會不會影響贊助者瀏覽意願。
如果有數據,就會遇到下一個難題:
問題:請問贊助者在首頁的跳出率,要以幾 % 為基準,若因為多了 OO 版位,掉到 Y %,接不接受?
二、產品開發目的
上述僅是首頁的版面,以開發目的來說,其他兩難問題包括:
問題:B 端提案者專案後台功能、和 C 端贊助者的前台結帳優化,哪個優先?
前者可以讓提案者在規劃專案時,有更便利的串接方式或是顯示功能,後者可以優化消費者旅程地圖,讓瀏覽專案、結帳更順暢。這裡可以挖深:
問題:要以 B 端獲客優先?還是提高頁面的 C 端留存率、轉換率、客單價?
但以單方面角度其實也無法判斷,因為我們並沒辦法 100% 確定功能一定滿足目標。
問題:如何確定功能做出來就一定會獲客(功能開發完成,就會讓 B 端潛在客戶簽約嗎),另一方面,我們又如何確定 C 端優化做完,就會提高頁面轉換率?
沒有數據的話其實無法直接判斷上述問題,因此可以再繼續挖:
問題:開發一個 B 端的功能,實際可以有效換成多少客戶簽約?開發一個 C 端功能,可以提高多少每月銷售額?
上面連續挖了 4 個 Why、How、What 等問題,都是我現在面臨的難題,也正在一步步拆解中。
三、產品需求順序
目前已經聊到產品定位、產品目的,接下來要分享的是產品順序,誰的功能先做。假設下方先以 B 端為開發目的:
問題:同樣對 B 端提案者有利的功能,要如何排序 X、Y、X 三種功能?
在開發功能時,我會考慮到:
- 時程:有哪些客戶、利害關係人,會立即需要、受益於這項功能?(要避免做不緊急的功能)
- 範疇:呈上,以客戶的專案時程,對比現在開工要花費的工時,來不來的及趕上?(要避免做客戶專案時程根本無法接上的功能)
- 資源:現在有哪些工程師可以投入?(避免沒有分配好開發狀態)
- 犧牲:做這個功能之後,哪些功能會被延後開發?(避免過度擠壓到重要功能)
問題:排序完之後,遇到更緊急的功能需求,接不接受插件?
在開發過程中,難免會遇到更臨時的需求,或是臨時的 Bug 要修復,這時就要再判斷原本的功能要不要停,是否有 buffer 緩衝時間可以接受插件。
四、總結
以上是我整理這一陣子的產品管理心路歷程,不斷與各種利害關係人議價,同時也在反覆摸索產品的判斷準則,該做/不該做、急/不急、影響大/影響小、B 端導向/C 端導向 … 等。