【第一次當產品經理就上手】Part 4 - 產品成效分析與推廣跟檢討反思
繼上一篇 【第一次當產品經理就上手】Part 3 - 不可不知的產品開發細節與上線規劃的策略
產品上線了，總需要知道成效如何?該如何推廣? 整個開發流程是否有需要優化或修正的，避免下次遇到同樣情況可以有改善的方式，接下來我就來解析一下產品流程最後的收尾。
9.產品成效分析與後續相關發展
產品好不容易推上線了，但才剛開始，推上線後有客戶使用且用的開心才是成功，所以我針對下面幾個方面來說明。
- 確認成效指標與分析工具
- 產品上線了大家最在意成效跟指標，通常會先擬定要觀測的成效指標，以及可以看到這些指標的工具。
- 成效指標：因每個產品面向跟需求不同，所以成效指標會各自不同，我先針對泛用性的指標來說。
- 產品使用量
有多少客戶使用該產品，就表示客戶願意去嘗試第一步，以電商指標就是初次造訪的概念，有了初訪才會有回訪，所以初訪非常重要。 - 週期使用率
平均每個周期每個客戶使用幾次，這個指標有助於觀測客戶對於產品的黏著度與依賴性，使用率高表示這產品在眾多產品中身受客戶喜愛，有愛才有價值。 - 產品帶來價值
這個就非常務實，不是每個產品都是主攻性產品，也有很多是輔助性，所以會分兩個。 - 主攻型：通常類似自媒體的產品，我們會預設一些追蹤參數(如utm)，一來幫客戶節省設定時間，二來我們也可以追蹤其帶來價值，如發了一則簡訊後，透過utm廣告追蹤參數查看帶來多少業績，就可以知道這產品幫助客戶的價值。
- 輔助型：有些產品非自媒體或廣告或者成交流程，例如分析報表或者資料匯出，所以很難知道哪筆訂單是透過這些產品帶來的價值，這時候就不能用訂單金額來觀測，而可以透過使用這些工具後，客戶的行為是否有改變，例如有了分析報表後，客戶是否有因為報表的數據調整他們的策略進而帶來成效，但這一段通常要與客戶溝通才會知道整體效益，所以不是可以隨時檢驗，需要長期追蹤，有時候也會透過訪談知道這產品為客戶帶來的價值，有時候不是金額，而是節省客戶時間或者縮短流程。
- 我這邊舉一個案例：我開發了一個商品性的分析報表，因為非常的彈性且能提供不同的維度跟指標，而這些是過往客戶可能要從很多功能分別擷取彙整後才能知道這成效，但現在只要透過一個報表就能知道成效，對於客戶來說非常方便也非常實用，這種客戶的評價就是這產品的隱性價值。
- 分析工具：當成效指標訂出來後，就要去看哪些工具或平台可以去看到這些指標，最常發生的情況就是RD自行撈取DB或者Log資料，但資料整理或者梳理通常很麻煩又耗時，導致無法隨時可看到成效，我們團隊通常會用幾個方式。
- Google Analytics
很推這產品，但需要RD一開始開發產品介面時就需要埋設Code，但埋設後就會有很多自動收集的數據幫忙分析，因為是免費產品所以實用性跟推廣性很高。 - 在操作使用上，會於產品上埋設GA的code，這樣產品的開啟跟瀏覽數據都可以隨時看到，另外針對主要功能的按鈕埋上事件code，就可以知道點擊事件的數據，就知道產品的操作狀況以及使用量。
- 在產品成效上，如果該產品是數於主攻型，可以透過客戶自己的GA報表查看預設的utm廣告追蹤參數看到期待來的成交訂單金額或者轉換事件(如註冊、加入購物車等)與價值。
- DataStudio (現在改名叫做LookerStudio)
這產品也很棒，簡單想成是Excel的樞紐表加強版，只要有數據來源就可以隨時幫你轉換成需要觀測的指標數據與報表，但前提是RD需要把要觀測的數據擷轉到BQ的Table上讓你可以串接數據呈現在DataStudio上，好處是只要分享方便隨時可查案，缺點是數據多的話查詢會有相對應的費用。
- 觀察指標與使用狀況
- 當你預設的指標數據可以看到後，就可以定期觀測其產品成效。
- 產品使用量：如果數據很低就要思考如何跟客戶推廣產品使用。
- 週期使用率：如果使用率低就要思考該產品是否沒有找到爆點，通常是核心痛點沒解決或者是與客戶期待有落差。
- 我這邊舉個案例：我有個產品推出後，因為功能僅有幾個我們觀測過需要的核心條件，所以開發完就先推出，後續發現使用率沒有想像中高，經過訪談後才知道我們每個客戶需求不太依樣，變成還有一些次要功能或者長尾功能推出後才會願意使用，後續就需要持續優化迭代來提升使用量。
- 當預設指標數據成效達到甚至超越預期後，這時記得鼓勵團隊，分享戰果提升團隊榮耀，並將該成功的經驗能夠延續下個產品，團隊才會越做越好。
- 產品推廣方式討論
- 一開始推產品時一定需要一些成功案例說服其他客戶使用，所以推廣方式通常會採用Pilot客戶先行，收集使用情境反饋跟數據後，擬定出產品的溝通方向與推廣價值，進而向客戶說明與宣導，主打產品最有價值的一面(解決主要痛點)，並且與客戶窗口、市場推廣單位開會，針對產品成效、情境研擬取得共識後，統一推廣口徑後，後續就由客戶窗口與市場推廣單位接棒協力推廣產品(這時通常會搭配Sales Kit或者說明簡報跟客戶分享)，並且後續收集回饋後優化，才能讓產品走得更遠。
- 商業模式驗證、關鍵指標數據的分析與洞察
- 商業模式驗證這一段層級比較高一點，通常產品經理對於產品的商業模式有其想法，但主管層或者有更廣的思維，因為產品經理大都思考自己範圍內的可行性，而主管層是思考多單位多面向甚至跨公司的策略執行，所以通常會分兩段。
- 產品經理的商業模式：這一段屬於產品經理或者團隊自行推演的商業模式，所以可以透過後續產品發展來驗證其商業模式是否符合市場，多幾次後就可以知道團隊與市場的距離，這樣未來產品的商業運用就會更直接更有效。
- 主管層(公司面向)的商業模式：可以觀察後續主管層預期的效應是否有發生，例如某產品的開發是為了與某集團合作的契機，所以可以觀察後續與某集團的合作是否更深更遠，又或者某產品是為了帶來其他產品的收益，這時候就可以觀測產品推出後，其他產品的效益是否提高。
- 關鍵指標數據的分析與洞察
- 我們通常會埋設主要事件，除了觀察成效後我們也可以透過數據去查看產品的隱藏價值，我這邊舉幾個案例。
- 案例1：某產品需求方說一定要有10個功能才能推，但其實上透過數據發現實際上客戶大部分僅用3個主要功能，那這就有兩個方向。
- 方向1：產品推廣針對3個主要功能去收集價值與數據跟使用情境，透過這3個主要功能就可以解決大部份客戶的痛點，避免客戶看到太多功能無法聚焦或理解，這樣可以縮短客戶的使用門檻。
- 方向2：其他7個比較少用的功能，後續針對需求方的類似需求可以提出數據作證，或許需求方的需求是假需求，或者需求方的需求不是大部分客戶需要的功能，這時候可以把資源評估去開發比較重要的產品。
- 後續擴充與應用延伸
- 產品推出後一定有團隊預計開發但尚未開發以及後續收集客戶反饋時的優化功能，這時候就可以評估產品後續要先擴充的是哪些既定要開發的功能以及後續產品可以延伸的應用。
- 開發排序：產品開發後還有3個主要功能待資源去排序開發，這時候收到回饋後知道某個功能的需求比較強烈，開發的排序就會出來了，以現場的客戶需求為主。
- 應用延伸：我們有個產品開發後客戶要到另外一個產品才能看成效，所以我們將兩個產品透過一個連結串接起來，將A產品的關鍵成效字帶入B產品查詢，將主攻型的產品串接輔助型的產品，讓客戶使用起來更方便。
- 定期與需求方收集產品回饋並討論優化項目
- 產品只要有人持續使用就有無止盡的需求，這時候需求就是收整濾除，並與團隊定期討論優化的項目，可以幫助產品走向更正確也幫助客戶。
- 產品公司策略、主產品、其他產品延伸或串接的可行性
- 產品經理層級低一點通常只負責自己範圍的產品，這時候可以思考其他產品經理正在開發的產品，透過產品的策略合作延伸幫助客戶，也可以一同思考公司策略，開發的方向都以公司策略為主。
- 公司策略案例：各單位都有產品經理要開發報表，但每個人取得的資料源或者數據的邏輯不同，導致看起來很像的單位(如會員數跟訂單數)因為源頭或者邏輯不同而不一致
- 案例：A產品的會員數是有效會員數，B產品的會員數是有效+無效會員數，但因為名稱都是會員數，所以常常造成客戶的困擾。
- 後續公司為了避免這樣的情況推出了一個會員的中心資料源跟邏輯定義，後續大家開發時都取同一資料源跟同邏輯定義，避免再次發生不一致的問題。
- 產品延伸串接案例：我們開發的產品，其他單位希望能夠使用，所以產品後續為了相容其他單位而擬定了一個規格與API，其他產品可以透過同規格與API使用我們的產品，讓產品間串連起來不用重複開發類似的產品，也幫助雙方的產品使用推廣與降低產品開發時間。
10.產品開發檢討與反思
產品開發過程中常會發生很多沒預料的問題或者現實狀況導致無法如預期開發，我們通常會在開發後或者每次迭代優化後做個檢討跟反思。
- 開發過程產生的問題
- 通常產品開發遇到的問題大概是人、事、物，這時候會列出來針對這些問題討論如何解決跟避免
- 人：如關鍵開發腳色離職，後續接手的人如何銜接其開發KnowHow，如何在離職前(最多一個月)交接工作避免影響開發進度(其實這一段一直是我們痛點且無法有效的解決)，通常團隊需求很多，一個RD會負責很多專案，這時候隨便一個人離開都造成大的影響，而另一個交接的人就要吃下兩倍的工作，通常PM會有個考量，要嘛延期產品交付，要嘛捨棄另一專案讓主要專案準時交付。
- 事：某個隕石專案插件導致產品資源移轉無法如期交付，通常這只能摸摸鼻子先完成隕石專案，然後延後原本預期專案的交付時間。
- 物：缺少某個服務或者設備或者其他團隊資源，這部分會針對補齊的時間重新調整開發排序與流程，通常是延期交付，但後續類似產品開發前就需要將這些問題提前梳理避免再次發生。
- 阻礙產品進展的原因與分析
- 通常分析原因後，會有可避免跟不可避免，但分析的目的都一樣，如何避免或者優化，可避免的就是後續要能避開，不可避免就是勇於面對優化其流程或細節使其更好處理或者根本性解決問題。
- 這邊舉個案例：上面有提到各產品的會員數不一致原因，因過往大家都不太面對導致客戶抱怨，但每個產品都會遇到，最後公司政策就是根本性解決問題，開發了一個統一的資料源與定義，後續產品都需要改到正確的資料源與定義，實際上解決這問題。
- 產品商模的未來與優化
- 產品開發時，通常市面上已經有類似的產品跟商模，但因為公司屬性跟策略不同，商模都不一樣，這時候開發前可以先針對市場上的商模與公司策略整合後分析未來的商模，以及市面上產品的走向去擬定優化的目標。
- 團隊內部或跨單位協做的卡點或流程優化討論
- 團隊內部卡點：通常一個RD手上有多個專案又分別是不同產品經理負責，這時候資源卡住了就需要將相關人等一起討論其優先排序與相依性問題，並且針對未來遇到時擬定一個SOP，這樣除了產品經理發現卡點外，RD可以更快知道卡點跟回報，降低其風險。
- 跨單位協做：這一段很複雜，每個單位都有其開發排序，而你的排序跟別人的排序絕對不一樣，別人也不可能符合你的需求延緩自己的開發而造成卡點，所以這時候通常會跨單位擬定協作流程來避免遇到類似問題，而後續產品要開發前也可提前評估跨單位協做資源的時程與相依性，避免延期產品交付。
- 取得團隊共識，將檢討與反思的重點列入下次產品開發的重點
- 最後以上的產品檢討與反思出來後，都會有其相對應的優化方式與流程，這些都需團隊取得共識，有共識大家才會團結一致降低抱怨與不信任感，後續落入團隊或公司的開發流程中，下次開發時列出來看是否有遇到相對應的風險，才能避開或者順利解決，如期交付。
以上，就是產品開發中最後的流程，很高興我在今年底前寫完這四篇文章，收攏我的經驗，對己有個很好的交代，不枉這幾年的開發經驗有個稍微具體的經驗談與做法。
而每個人作法不同，團隊跟公司流程與風氣也不同，建議參考用就好，其實產品經理最重要的是臨機應變，入境隨俗並優化做法，所以有時候很吃個人特質與思維，產生的結果與流程也會不同，但就提供大家參考，或許有遇到類似情境或者流程少了甚麼時可以幫助你找到一點想法。
最後分享一下產品經理的幾個感想
- 我們都有個願景
- 需求方相信開發方，開發團隊相信產品經理，彼此互相完整產品，協助推廣與優化。
- 需求方知道開發限制，在第一線能協助檔掉不合理需求，減少無謂的開發量能，讓開發團隊專心做有價值的產品，提升公司價值與幫助客戶解決痛點。
- 現實上的問題
- 老實說這很難，現實總是殘酷，不如意十之八九，產品經理的夾心餅乾人設總是無奈，心理建設要到位。
- 相關單位有利益時是另一個態度，沒有利益時又是另一個態度，心態很重要，不能被影響。
- 羅馬不是一天造成的，正向積極面對才能勇於前進，不管是面對需求方或者團隊，不要被負面情緒打倒，正向的思考才會幫助你解決問題。
留言
張貼留言