【第一次當產品經理就上手】Part 1 - 產品開發需求的來源與釐清跟對焦
延續上一篇 【第一次當產品經理就上手】我的產品開發之路
這次要來講一下產品開發10個步驟中的細節
1.收到產品開發需求的來源有哪些?
2.需求始末與細節的釐清與對焦
產品經理主要工作就是開發產品，而每個產品的需求提出，都有其背景與目的還有後續延伸的商業模式，所以一開始收到需求就要很仔細地盤一下。
為何而做?
為何而戰?
千萬不要盲目的開發然後弄錯產品方向跟目的。
這邊要注意幾個點
- 需求提出通常背後有一些原因，要能找到原因才能確認方向，別被表面的需求迷惑而無法得知背後的實際原因，尤其要小心公司內的政治考量 。
- 需求通常是個人觀點，可能是需求方沒想到其他方式就提需求，但如果用現有的方式也能解決問題，那這需求就是假議題。
- 設定產品邊界，別被模糊曖昧的需求無限擴大了產品範圍，要先從目的限縮產品範圍，不然只會做不完。
這邊說一下幾個情境跟拆解分析
情境1：老闆要開發未來的主力產品
當你收到全新的主力產品需求，這決策大部分都是從天廳下達命令，通常老闆已經有了一些想法，可能是講起點的雛型或者直接跟你講終點的結果，但都差不多，因為你必須一條龍的從頭到尾開發完成。
第一件事，先跟老闆或者有利益關係的人(Stakeholders)，聊聊他的想法跟討論目的，很多時候老闆會給願景，或者只是某個點要完成，這時就要好好評估一下有無可完成目的或找到願景的方向以及開發的可行性，有時候是天馬行空，但很多時候老闆跟現場有點距離，這時候就靠產品經理把這距離拉近，不管是把老闆拉進現場，還是把現場拉近老闆，都是產品經理該負責的工作。
舉個例子，我是在B2B的產業，老闆跟我說，我們收了一堆行為數據，為何不能有類似GA的報表，我們應該要能展現我們的價值，讓客戶為了看正確完整的數據只能選擇我們家，透過數據報表把客戶綁定。
好了，收到這個需求就要拆解一下
- 願景：我們擁有完整行為數據，要展現其價值幫助客戶。
- 目的：透過數據報表綁住客戶，宣示公司在市場上的競爭力。
這時我的疑問就會來了，提出需求的是老闆，但使用者除了老闆還有誰?
答案是業務，因為每個產品業務都須跟客戶說明推廣，而業務就是你第一線的推廣員，以這情境為出發點，我必須思考三件事件。
- 有無達成老闆的願景？
- 畢竟這屬於老闆心裡的期許跟預計對外佈達的方向，方向跟願景還是要對齊的。
- 老闆通常都會跟客戶高層接洽，願景通常都是老闆跟客戶高層言談間建構出來的虛擬願景，所以下次見面能否將虛擬願景變成現實，就是一個很重要的時刻，一個能能幫助客戶且獲得信任感的產品。
- 業務是否買單？
- 先溝通老闆的願景與業務期待是否一致，如果沒有一致就要尋找共通點或者切入點，讓業務也能認同。
例如老闆願景是公司能夠推出一個第一方數據產品，但對業務來說是這第一方數據能夠做什麼?
如果加上第一方數據比第三方更完整準確，讓客戶能更準確分析，且全盤觀測，對於客戶的行銷操作或SEO都能帶來幫助，那就是延伸的認同與實用性，老闆的願景路上找到讓業務能認同的點，才能達到雙贏。 - 然後要考慮一點是門檻跟教育成本，一般業務不懂數據，如何讓客戶簡單明瞭看到數據成效好入門，降低門檻。
- 再來要考慮溝通成本，訪間最常用的數據工具就是Google Analytics(簡稱GA)，GA本身產品線豐富，分析數據的層面廣又深，當客戶拿GA來比較時就會遇到很多問題，所以首當其衝要先理解一般使用者用GA，最常用跟最直觀的功能是哪些，起碼能對標其核心功能，這樣兩邊才好溝通。
- 最後要考慮業務的溝通情境，試想當業務窗口跟客戶說明新產品時，要用怎樣的故事跟說法去取得客戶認同並願意使用該產品?
這一段PM就要透過很多訪談跟經驗還有來回驗證去營造一個情境，一個讓客戶聽了覺得這是平常都有的情境但透過該產品卻解決或優化了痛點，進而感同身受而買單，而業務就是要有一個對外的說法跟套路去引導客戶理解並體會其產品實用性。
- 是否是開發團隊能負擔的範圍?
- 通常需求來，PM有經驗就會先評估一下範圍，團隊是否能承接，不能承接就要需要資源，能承接就是排序問題，通常第一手會先有個底，後續流程才會好推進，若沒有經驗，就要研究一下同類型產品，讓產品有個具象化的觀念才比較好進行規劃。
情境2：客戶希望在原有產品加上新功能
產品越多客戶使用，對於產品的迭代跟優化會有很多期許，俗話說嫌貨才是買貨人，當有一個窗口來，客戶自己就順便把期待全部傾瀉給業務，當然聰明的業務會先梳理找到最痛的點去幫助客戶，但一般的業務大概就照單全收往後(產品團隊)送。
舉個例子，我們有一個能匯出會員資料的功能，但客戶想要在會員資料的匯出欄位上多一個指定區間的消費金額，也就是匯出時希望可以在資料上看到這會員上個月的消費金額，客戶可以去找到上個月消費金額在某個區間帶的會員去再行銷曝光新產品或活動。
這時就要開始整理一下需求
- 目的：找到上個月消費金額在某個區間帶的會員去再行銷曝光新產品或活動。
- 需求：希望透過匯出會員資料功能新增指定區間消費金額的欄位。
我通常會想一下
- 該需求在該產品上開發適合嗎?
- 這是正確的解法嗎? 還是有更好的方式?
- 有沒有其他方式可以快速解決，不須另外開發?
與業務討論了一下需求後如下
- 產品適性：
- 會員資料匯出的功能屬於會員的現況非歷程，所以指定區間的資料不適合放在這功能，畢竟指定區間是無法彈性調整日期。
- 正確做法：
- 客戶的目的是要溝通再行銷，只要能快速解決的可以，所以我們有另一個篩選會員的功能很適合開發該需求，正解應該是在這篩選會員的條件上新增指定區間消費金額。
- 快速交付：
- 若進開發客戶要等待，不可能一蹴可及，所以現階段有沒有短解，盤了一下目前有個報表可以看指定區間的消費金額，剛好有個自訂維度是會員編號，就可以透過該報表匯出指定區間的所有會員消費金額，雖然客戶要下載檔案還要過濾跟排序找到會員編號，然後透過會員資料再次匯出會員編號的手機號碼或Email做再行銷溝通，多了不少流程，但還是可以達成客戶的目的。
情境3：客戶希望開發一個客製需求
這幾年Martech(由Marketing與Technology結合而成，意思是行銷科技)很流行，因為投入廣告的品牌越來越多，廣告量就這些，所以成本只會越來越高，這時候亂槍打鳥已經無法達到效益，必須精準溝通，此時Martech工具通常號稱能幫客戶精準行銷，提高廣告成效等，但客戶本身沒有RD人員可以埋設Martech工具的程式碼，這時就會請系統商客製非系統商提供的模組服務，而該客製需求也只限這客戶使用，但客戶因為被產品話術吸引加上大環境的廣告成效越來越低，就造成很多的客製需求提出。
我這邊舉個案例，某品牌客戶因為想要做長期CDP資料收集跟個人化行銷，故購買某牌的行銷工具，但希望我們客製符合該工具的需求去開發，但該工具有幾十個功能，每一個都可能動到原本的系統架構或者重新開發，如果要全部功能串接開發，該客製專案可能沒有收尾的一天，因為只要有新功能我們又要重新配合動工，而這開發成本非常難估算，我猜也根本不會賺，尤其還有維運問題。
這時候就要靜下心來思考幾個問題
- 客戶透過該工具想解決的痛點是什麼?
- 該牌行銷工具跟公司提供的模組服務有哪些相容?
- 解決痛點需要串接的功能即可，去限縮開發範圍，避免無止境的需求延伸。
所以請客戶邀請與行銷科技工具的窗口、我們的業務與PM做三方會議的需求釐清。
先了解一下客戶的痛點跟目的還有行銷工具哪些功能可解決?
- 主要痛點：降低購物斷點，提升轉換率
- 客戶情境：
- 客戶的其他競品也有類似同質性產品，所以很容易因為比價或者回饋而跑去競品買。
- 行銷工具對應功能：
- 工具中有個即時溝通功能，符合指定條件即可觸發推廣功能，如加入購物車未結，離站前或指定時間內未結帳都可觸發推播或者跳出折價訊息廣告挽救購物車放棄率，提升結帳率。
- 系統服務架構：
- 評估後要能夠串接即時溝通功能，就需要開發兩個項目。
- 收集行為事件：剛好一些進站、瀏覽、加入購物車、結帳等關鍵行為我們都有類似追蹤模組，所以評估同模組觸發事件的參數跟值轉譯成行銷工具的規格應該可以達成。
- 推播功能：這需要串接APP的Push系統，所以這一段會需要開發團隊評估。
- 訊息廣告：該功能可透過GTM完成，故僅開放GTM權限給行銷工具的RD窗口執行埋設即可完成。
最後整理一下
需求來源大概分四個類型
- 公司政策或老闆願景
- 客戶對於產品新的功能需求
- 客製專案
- 公司跨單位需求
(通常來至於維運單位、財務或行銷單位等不同單位需求，這邊案例太雜太多我有空再分享)
需求的釐清與對焦有幾個要點
- 與公司政策/願景是否一致方向
- 在產品使用情境上找到切入點滿足業務需求
- 需求是真需求還是假需求，是否現有產品即可解決
- 需求的背後原因要釐清，政治因素還是策略因素或者是資源排擠因素
- 限縮產品範圍，解決主要痛點
- 評估現有資源能否承擔，要思考接單後的規劃與資源策略
以上大概是這幾年的心得，接下來會就是找時間再寫其他流程，敬請期待。
留言
張貼留言