行銷里長伯

  前言：最近公司突然吹起了【峰值體驗】這股旋風，從頭開始狂風暴雨，身為下面的我突然警覺到，要來看看這本書，起碼了解一下這股旋風要講什麼，突然一個同事塞給了我這本書，原來她們部門每人都讀完了，當下想說，好! 我周末來把它看完，順便幫部門同事分享一下讀書心得，所以我寫下了這篇文章，先說好作者大陸耕耘很久，裡面很多大陸用語我盡量轉成台灣用語。 充滿各種經營學、行銷學、心理學、體驗設計、經濟學等理論，透過作者揉合而成這本書 峰值體驗 作者有兩位分別為汪志謙跟朱海蓓，這邊比較有名的是汪志謙，台灣人，政治大學EMBA客席副教授，香港大學SPACE中國商業學院客席副教授、台灣真觀顧問、上海真觀顧問創始人、得到App《汪志謙．MOT 體驗設計課》主理人。 書中提到不少理論，但大部分主軸圍繞在2002年諾貝爾經濟學獎得主，丹尼爾·康納曼Daniel Kahneman博士提出的「峰終定律」以及他寫的「快思慢想」這邊書的理念為核心。 那....峰值體驗在說什麼? 2002年諾貝爾經濟學獎得主卡尼曼（Daniel Kahneman）的「峰終定律」，裡面有說消費者最記得體驗流程中的最高點、最低點和終點，這3個時刻最容易進到心智、留下印象；本書中說的「峰值體驗」（Moment of Truth），就是在高點和終點創造最佳體驗。 目的是品牌方不會希望客戶對品牌的印象是在最差的低點，所以去除最低的那個時刻，那麼第一印象（最初）、體驗中最完美的時刻（最高）、加上結束前最後印象（最終），這三個時刻，就是書中稱之為體驗設計的「黃金時刻」。 在規劃體驗設計的黃金時刻時，必須從消費者洞察中找出三種你必須了解的人並且在消費者四大維度(進店、轉換、回購、推薦)中去結合 消費者洞察中 三種你必須了解的人 1.不愛你的人 也就是新客，沒買過、沒註冊、沒到網站/門市的人。 這些人要去了解為何沒有買過，是不知道所以沒買還是知道但不買，這兩個情境的目的不一樣。 不知道所以沒買：那就是曝光度不足，根本沒人知道，不知道無法曝光給消費者，基本上就是沒有交集的人，要打破這現況，才能從陌生人開始認識，目的就是提高進站/店率。 知道但不買：打了一堆廣告，開了一堆店，怎樣都讓人知道了，但為何沒有轉單，如何能夠讓人願意首購是個很重要的點，目的是提升轉換率。 2.愛過你的人 買過一次或者幾次就再也不買的人....這些人要去了解為何不再買

過去幾年在電商平台都會去觀測幾個國外網站的年度電商趨勢分享，今年特別作了一篇，寫一下分享給大家我看到幾篇文章後覺得值得拿出來討論的趨勢。 備註：老生常談的我就不特別拿出來說了。 趨勢1：第三方Cookie退場的替代方案 目前針對第三方Cookie退場的取代方案大略有四種 First-party cookies. 第一方資料是目前最夯也最推的資料，唯有第一方domain的傳輸才不會被瀏覽器阻擋，而自有品牌也可控制需要收集哪些資料。 The Trade Desk（TTD）推出 Unified ID 2.0（UID 2.0） UID 2.0打破了第三方Cookie只能追蹤跨網站用戶行為的侷限，而是能 透過Email授權的機制 ，將用戶在不同平臺、網站與App的瀏覽數據串連起來。 這裡有篇文章值得參考： UID 2.0文章 Google隱私沙盒（Privacy Sandbox）：Topics  將所有的網站分類並貼上標籤；接著，系統將根據用戶「過去一週」的瀏覽紀錄，為用戶貼上「最多五個」興趣主題標籤（例如：旅行、健身、彩妝等），並依此作為廣告投放的依據；廣告主投放廣告時，僅能選擇興趣，無法得知受眾群體的具體樣態。 具體來說，Topics 的第一個步驟， 是將所有的網站分類並貼上標籤 ，目前系統將根據「美國互動廣告協會（IAB）」的分類標準，採用 350 種主題來識別網站；接著，系統將根據 用戶「過去一週」的瀏覽紀錄 ，為用戶 貼上「最多五個」興趣主題標籤 （例如：旅行、健身、彩妝等），並依此作為廣告投放的依據；廣告主投放廣告時，僅能選擇興趣， 無法得知受眾群體的具體樣態 。 在 Topics 架構中，用戶可以清楚檢視自己被貼上的主題標籤，並選擇是否要移除特定標籤甚或是關閉追蹤功能，而 主題標籤最多只會保留三週 ，逾時將刪除、重新計算，避免交叉比對、識別單獨用戶的可能。 Digital Fingerprinting. 概括地說，數字指紋是從瀏覽器下載的一組特定於用戶的數據，可用於在兩次訪問網站之間以高概率確認用戶的身份。 分析洞察：我們也一直在追數據的收集重要性，而第一方資料大部分可彌補資料的斷層，但我們也須針對第三方Cookie的退場而提供各種第三方的數據補齊，像Meta推的CAPI就是一種伺服器補傳網頁端傳輸的遺失資料，目的還是能夠補齊更多辨識與資料，讓成效更精準。 趨勢

  繼上一篇  【第一次當產品經理就上手】Part 3 - 不可不知的產品開發細節與上線規劃的策略 產品上線了，總需要知道成效如何?該如何推廣?  整個開發流程是否有需要優化或修正的，避免下次遇到同樣情況可以有改善的方式，接下來我就來解析一下產品流程最後的收尾。 9.產品成效分析與後續相關發展 產品好不容易推上線了，但才剛開始，推上線後有客戶使用且用的開心才是成功，所以我針對下面幾個方面來說明。 確認成效指標與分析工具 產品上線了大家最在意成效跟指標，通常會先擬定要觀測的成效指標，以及可以看到這些指標的工具。 成效指標 ：因每個產品面向跟需求不同，所以成效指標會各自不同，我先針對泛用性的指標來說。 產品使用量 有多少客戶使用該產品，就表示客戶願意去嘗試第一步，以電商指標就是初次造訪的概念，有了初訪才會有回訪，所以初訪非常重要。 週期使用率 平均每個周期每個客戶使用幾次，這個指標有助於觀測客戶對於產品的黏著度與依賴性， 使用率高表示這產品在眾多產品中身受客戶喜愛，有愛才有價值 。 產品帶來價值 這個就非常務實，不是每個產品都是主攻性產品，也有很多是輔助性，所以會分兩個。 主攻型 ：通常類似自媒體的產品，我們會預設一些追蹤參數(如utm)，一來幫客戶節省設定時間，二來我們也可以追蹤其帶來價值，如發了一則簡訊後，透過utm廣告追蹤參數查看帶來多少業績，就可以知道這產品幫助客戶的價值。 輔助型 ：有些產品非自媒體或廣告或者成交流程，例如分析報表或者資料匯出，所以很難知道哪筆訂單是透過這些產品帶來的價值，這時候就不能用訂單金額來觀測，而可以透過使用這些工具後，客戶的行為是否有改變，例如有了分析報表後，客戶是否有因為報表的數據調整他們的策略進而帶來成效，但這一段通常要與客戶溝通才會知道整體效益，所以不是可以隨時檢驗，需要長期追蹤，有時候也會透過訪談知道這產品為客戶帶來的價值，有時候不是金額，而是節省客戶時間或者縮短流程。 我這邊舉一個案例：我開發了一個商品性的分析報表，因為非常的彈性且能提供不同的維度跟指標，而這些是過往客戶可能要從很多功能分別擷取彙整後才能知道這成效，但現在只要透過一個報表就能知道成效，對於客戶來說非常方便也非常實用，這種客戶的評價就是這產品的隱性價值。 分析工具 ：當成效指標訂出來後，就要去看哪些工具或平台可以去看到這些指標，最常發生的情況就是RD自行撈取D

 繼上一篇  【第一次當產品經理就上手】Part 2 - 需求如何排序與規劃以及專案啟動會議(Kick-Off Meeting) 說明當接到需求後如何去排序跟規劃與對焦，接下來要進入產品開發的階段了，也就是後續的流程拆解。 6.產品進場開發 當專案啟動會議(Kick-Off Meeting)拍板後，接下來就要將會議內決議的重點跟方向，跟團隊佈達並開始進場開發了，首先要邀約開發團隊做進場前的會議說明。 與團隊說明跟需求方取得的共識與目標 當專案啟動會議(Kick-Off Meeting)確定後，目的就非常明確，需求方到底期望達到哪種目的與預期效果，要能夠與團隊說明，通常我會與開發團隊簡報的內容如下 需求的來源與目的 ：開需求的時後要讓團隊知道前因後果，很多時後PM會避開需求的根本原因以及產品要解決的問題後面實際的目的，而我自己覺得PM要能夠將需求的來源與最終結果 "收攏"精簡說明 並給予一個 產品的詮釋 ，避免團隊收到不必要的資訊而錯誤解讀，或者沒有收到完整資訊而忽略了產品的目的。 我這邊舉個例子： 例如我某個需求雖然是客製專案，是某客戶的需求，但我們卻要花超過客製專案等級的資源，釐清後才知道其實公司背後的目的是希望能藉這客製專案與某第三方達到地區性的策略合作，所以需求來的又急又火，然後排擠了目前的專案，當我收到訊息時，我必須清楚地告知開發團隊為何插件然後又急又火，這時候把需求拉高到公司層面會是比較適合的，因為跟公司策略有關，就是每個開發的團隊必須配合的，若我只是告知某客戶的客製專案，那開發團隊就會提出很多質疑，例如排擠了對公司所有客戶都有幫助的產品排程，或者是花了很多資源卻只為了一間客戶使用卻得不到該有的價值，這時開發初期就會遇到很多阻礙，如無法說服開發團隊全力支援等；但如果我明白告知公司的策略就會拉高了開發團隊的共識與意願，通常我會補上這開發後除了主要目的(策略合作)外，還會有其延伸價值，如該客製的專案其實可以幫助客戶帶來GMV，也可以將該客製專案裡面的泛用性功能開發時與目前既有類似產品或服務去進行迭代優化，幫助團隊提高效能與降低維運，而這兩點其實對團隊來說是最有感的，通常團隊也願意讓這又急又火的專案插件並且全力協助。 UX版的產品Prototype示範 還記得與需求方的專案啟動會議時，DEMO 產品的 Prototype，這時候產品Proto

從上一篇  【第一次當產品經理就上手】Part 1-產品開發需求的來源與釐清跟對焦 我們知道了 需求的來源 以及 釐清跟對焦 ，這次我們要來講一下，當目標很清楚時，我們如何針對將需求排入開發時程以及拆解需要開發的內容並且拍板Kick-Off 開始進行開發。 接下來將針對產品開發10個步驟中的這三個步驟做說明 3.需求在Roadmap的優先排序 通常當我們收到需求就可以馬上進場開發嗎?  當然是不可能，因為同時間已經有其他專案再進行，團隊的Roadmap也有其他專案等著開發，一般來說起碼三個月內的開發排程都是確認的，除非需求很小，就會找專案跟專案中間的RD資源空檔插入開發，不然就是要跟其他專案PK了，而這時流程大概就是產品經理去評估接下來的專案與目前的需求輕重緩急，然後擬定一個順序回報主管，由主管決議是否調整排序或者協調資源，更甚者可能因為跟其他專案一樣重要就要往更上層大老闆們去協調了。 所以我的流程大概會是這樣 梳理目前已排序的專案輕重緩急 開發中：專案盡量不能斷，避免無法收尾。 排序中：看影響層面，如果跟營收有關就盡量不動，如果有取代方案的就可以先協調。 初步釐清開發需求的資源與時程 通常我們收了一個需求，會跟團隊的RD主管或者關鍵職能RD初步討論一下需要多人資源跟人天，大概知道一個需求的Size多大多小需要哪些職能的RD，這時候就可以往下排序或盤點。 盤點手上的資源 因團隊的RD職能包含前端、後端、數據資料處理等，不盡相同，也不是每個專案全部RD都要下去，一定是同時間多專案進行但RD人力不衝突，也可能某個職能的RD剛好不用加入專案或者剛收尾等QA驗證修Bug，這時你大概知道哪些需求可以跟團隊中的RD主管討論資源怎麼規劃跟安排，RD主管會告知相關細節與建議規劃。 判定需求方是誰 老闆需求： 看到老闆就要想到一件事，是誰付你薪水? 是老闆! 而且他是付所有人薪水，拿人錢財替人消災是非常合情合理的，一般老闆是不隨便插手各團隊專案開發，所以當老闆提出需求，一定就是要盡快處理，因為老闆背後可能會有很多目的，至於後續專案被排擠，通常拿出老闆的令牌，其他人大都不會吭聲 (職場潛規則就是這樣)。 例如該需求完成可以拿到別的資源去談判或者執行另一個需求或目的或資源，這是很多相依性的，也可能某個股東大會或者某個公開型曝光會議或演講中需要有這功能才能有其話題或者達到某個目的。 跨單位

延續上一篇 【第一次當產品經理就上手】我的產品開發之路 這次要來講一下產品開發10個步驟中的細節 1.收到產品開發需求的來源有哪些? 2.需求始末與細節的釐清與對焦 產品經理主要工作就是開發產品，而每個產品的需求提出，都有其背景與目的還有後續延伸的商業模式，所以一開始收到需求就要很仔細地盤一下。 為何而做? 為何而戰?  千萬不要盲目的開發然後弄錯產品方向跟目的。 這邊要注意幾個點 需求提出通常背後有一些原因，要能找到原因才能確認方向，別被表面的需求迷惑而無法得知背後的實際原因，尤其要小心公司內的政治考量 。 需求通常是個人觀點，可能是需求方沒想到其他方式就提需求，但如果用現有的方式也能解決問題，那這需求就是假議題。 設定產品邊界，別被模糊曖昧的需求無限擴大了產品範圍，要先從目的限縮產品範圍，不然只會做不完。 這邊說一下幾個情境跟拆解分析 情境1：老闆要開發未來的主力產品 當你收到全新的主力產品需求，這決策大部分都是從天廳下達命令，通常老闆已經有了一些想法，可能是講起點的雛型或者直接跟你講終點的結果，但都差不多，因為你必須一條龍的從頭到尾開發完成。 第一件事，先跟老闆或者有利益關係的人 (Stakeholders) ，聊聊他的想法跟討論目的，很多時候老闆會給願景，或者只是某個點要完成，這時就要好好評估一下有無可完成目的或找到願景的方向以及開發的可行性，有時候是天馬行空，但很多時候老闆跟現場有點距離，這時候就靠產品經理把這距離拉近，不管是把老闆拉進現場，還是把現場拉近老闆，都是產品經理該負責的工作。 舉個例子，我是在B2B的產業，老闆跟我說，我們收了一堆行為數據，為何不能有類似GA的報表，我們應該要能展現我們的價值，讓客戶為了看正確完整的數據只能選擇我們家，透過數據報表把客戶綁定。 好了，收到這個需求就要拆解一下 願景：我們擁有完整行為數據，要展現其價值幫助客戶。 目的：透過數據報表綁住客戶，宣示公司在市場上的競爭力。 這時我的疑問就會來了，提出需求的是老闆，但使用者除了老闆還有誰?　 答案是業務，因為每個產品業務都須跟客戶說明推廣，而業務就是你第一線的推廣員，以這情境為出發點，我必須思考三件事件。 有無達成老闆的願景？ 畢竟這屬於老闆心裡的期許跟預計對外佈達的方向，方向跟願景還是要對齊的。 老闆通常都會跟客戶高層接洽，願景通常都是老闆跟客戶高層言談間建構出來的虛擬願

前情題要：最近上了一些產品相關課程以後有很多感觸，加上之前也上了Google產品經理課程跟考了證照，想藉此分享一下我踏入產品經理的路，並分享我如何規劃產品。 踏入產品經理的第一步 在前公司時，公司因為一些政策要開發CDP產品，找了一堆大廠報價，都因為太貴買不起，最後找了一個小間的公司比較便宜，而該外包公司只有開發DMP的經驗，並沒有開發CDP的經驗，所以想當然爾公司需要一個跟外包協作的窗口，而該窗口需要有CDP的相關商業模式與運作使用的經驗，而公司放眼望去，因為我對於GA非常的熟，加上GA本身就是一個CDP產品，而我也擅長使用數據分析使用者行為跟流量成效，最後派了我去當作窗口，本來以為就是個顧問角色，沒想到外包對於GA或者CDP完全不熟，加上很難跟我們公司內的RD討論埋Code跟資料取得需求，最後公親變事主，我就慢慢地變成了該專案的產品經理(但其實我是行銷單位)，而從此展開了產品經理之路，後續也接了幾個產品專案，也因為如此我換工作時才能順理成章地從行銷轉職成產品經理。 產品經理的實踐之路 接下來進入到真的產品公司，B2B的乙方世界加上複雜的跨單位與跨部門還剛跑Scrum的公司真的是要重新調整心態面對，而且進公司時正是單位兵荒馬亂，我被草草交接工作，也沒人帶領的情況下獨自面對新工作跟新團隊，我花了半年才慢慢習慣產品經理的工作模式，真的是土炮練成的產品經理，老實說沒有基礎觀念下，真的是步步為營的處理每件事情，還記得我遇到一個資深的需求方跟我說了一句話讓我永生難忘.... 【我不會因為你是新來的就對你客氣喔!】 當下雖然笑笑帶過，心裡可是覺得這些需求方也太強勢，但任何工作都有一定的脈絡跟處理事情的邏輯，而這些的基礎我算是打得蠻扎實的，可以透過個人經驗來完成產品經理的工作，加上產品經理有50%是靠溝通能力，我一貫的理性溝通讓衝突減少很多，最後才漸入佳境可以自稱產品經理了。 備註：公司因跑Scrum，所以都稱做PO （Product Owner），但我覺得比較像是 PM（Product Manager），所以文章內都用產品經理來稱呼。 產品開發的流程分享 接下來我會針對這幾年我開發產品時的流程來拆解，來說明我自己是怎麼做產品的。 【第一次當產品經理就上手】Part 1 - 產品開發需求的來源與釐清跟對焦 1.收到產品開發需求的來源有哪些? 公司政策或老闆願景 客戶對於產品新的