您好！我是Iris 。

今年度我想為公益團體，在數位行銷與網站數位平台營運上做出一些協助。

一開始的初心，除了能將所學回饋社會；也希望能幫助對PM工作有興趣的朋友，藉由「實務做中學」，為社會培訓出更多數位產品經理專業人才。

過去7年，我只在企業內部提供這樣的PM人才培訓顧問服務；我希望透過這次公益機會，帶著有興趣的朋友一起進行產品專案、從中學習數位產品經理的專業技能。

希望找的志工，不僅能貢獻自己的時間與熱情投入學習與執行，並且在未來回饋社會，幫助更多人～

為什麼會選擇跟HOVA台灣視覺希望協會合作？

HOVA的創辦人甘仲維（墨鏡哥）是我以前Yahoo同事，也是非常熟悉數位領域的專家。他在28歲時因為重度3C使用突然失明，失明後仍完成交大資管所博士學位。成為第一位交大畢業的視障博士。目前致力於協助更多視障朋友，透過科技的運用，重新找尋人生的意義與定位。

這是我第一次嘗試數位領域的公益協助，因此也希望團隊成員有相近的語言，讓溝通能更加快速。

🍀 HOVA 媒體報導

失明博士／高學歷、年薪百萬人生勝利組 竟一夕之間失明 | 生活 | 三立新聞網 SETN.COM

甘仲維打造App 挪走視障者的人生障礙 | 陳虹瑾 | 遠見雜誌

🍀 HOVA 官網

台灣視覺希望協會・HOVA

志工需求

• 時間：2021年3~6月（暫訂；將視實際狀況調整）
• 2~3人
• 上班族：數位行銷、工程師、UIUX設計師，有數位背景或對數位產品經理有興趣者
• 在校學生：數位行銷資訊傳播等相關科系
• 需經資格審查與線上面談

工作內容與協作方式

• 大多採雲端虛擬團隊運作
• 例行會議：暫訂每週1次，上班日中午 Zoom會議(約1小時)
• 工作項目

1. 公益團體網站需求分析與規劃
2. WIX 系統平台自主學習 (暫定用WIX架設)
3. 使用者訪談（除了學習一般UX/UR能力外，更深入瞭解視障者如何使用電腦手機、操作難度與使用情境）
4. 實際動手做

這是一個共創三贏的方式！ 公益團體獲得更多志工加入；志工獲得專業領域學習機會；我也很開心能回饋社會～

請填寫以下表格報名 👉

HOVA 視覺希望協會- PM志工應徵

2012年離開最後一份正職工作，因為身體與家庭因素從職場退下，休息一段時間後陸續有朋友找我接案，從而誤打誤撞成為自由工作者至今，不知不覺也過了7年時間。

我的最後一份正職工作【在雲端管理跨國產品開發團隊】

在這期間，不發名片、不刻意經營人脈、不參與聚會交際宣傳，默默地一個案子接續一個案子進行，順利生存下來，時薪換算也超過先前在外商公司的水準。

7年中我也不斷思考定位與工作模式調整，有些朋友對於這樣的斜槓/自由工作者身份感到有興趣，也提供他們一些建議。借此低調公開整個心路歷程，幫助有興趣的朋友加入自由工作者的行列～

2013年開始以「數位產品經理」的身份接案，這是一個非常有趣的定位。在未從事這樣的工作之前，我從來都不知道原來產品經理Product Manager也有接案的空間。一般在數位網路領域，最常聽到的接案者是工程師或視覺設計人員，幾乎沒有產品經理PM，所以簡單來說：這個市場沒什麼競爭者！

§ 獨立工作者秘訣一：確認定位與競爭者多寡

擔任產品經理PM工作這麼多年下來，我發覺經營「產品」的能力與技巧，也可以應用在自身的職涯規劃上。每個人在職場上，就是一個獨立的產品。而在產品經營領域，最完美的狀況不是去追求「提昇自己（產品）的競爭力以在競爭激烈的市場上勝出」，而是「在市場上你沒有任何競爭對手」。

這個產品經理PM接案工作，為何沒有競爭對手？很簡單，因為跟我相似背景的朋友，都在各大企業穩定工作，願意出來的人少之又少。（也許這篇文章寫完後，會突然變多了呢！^^）

§ 獨立工作者秘訣二：明瞭市場需求與規模

「沒有競爭對手」有一種狀況，叫做「沒有市場需求」。市場需求是一個很弔詭的東西。大家應聽過一個案例，二個人去非洲開拓鞋子銷售市場，一個跟公司回報：「非洲太糟了，沒有任何人穿鞋」；另一位回報：「非洲太讚了！大家都還沒買鞋」

唯一能判斷是否有市場需求，就是直接下去做！

因此當一個、二個、三個案子接連進來時，就能夠很清楚知道，這個市場的確存在，只是沒有人嘗試罷了！

依照這幾年工作經驗，有幾種狀況下公司需要委外產品經理服務：

1. 公司需要短時間因應專案配合，但從需求分析到視覺設計或工程師溝通上遭遇許多挫折，因此希望有人能協助溝通與專案管理，以及前期需求規格文件產出。
2. 公司已在數位網路領域發展一段時間，他們希望能進一步擴展擬定產品市場策略或進行產品優化。
3. 公司認知到數位產品經理的重要性，但過去大多是土法煉鋼學習數位產品網站/平台專案開發，希望能學習培訓專業的產品經理人才。

當然這些公司也可以聘僱正職的產品經理。但實際狀況而言，有時公司的專案需求並未多到需要一位正職人員，兼職約聘方式是最有效率並省成本的作法。

另外一種狀況是，有些中小企業需要資深的產品經理或者主管，但這樣背景的PM往往都任職於大公司，人力資源聘僱上有難度，因此我會協助內部自行訓練人才。

§ 獨立工作者秘訣三：在明確定位下，強化自身能力的擴充性 （Capacity & Capability）

剛開始接案時，主要是上述第一種專案配合方式。慢慢的，客戶覺得這樣的PM資源「很好用」。特別是數位領域分工愈來愈精細，外在變化太快，客戶很多問題不知道從何著手，產品經理號稱「潛在CEO」，包山包海要會的東西非常多，因此後來找我合作的類型也愈來愈廣泛。從簡單到複雜有這幾種：

・需求訪談與功能文件撰寫

・使用者訪談與使用者測試

・Wireframe繪製

・主導數位產品開發專案與團隊，負責專案執行至上線

・透過數據分析進行產品優化

・為企業導入數位產品開發專案流程與PM人才培訓

・(Google)Design Sprint衝刺計畫工作坊企業內訓(2.5 days)

・新產品市場分析與快速測試（Lean Startup；MVP）評估策劃與導入執行

・公司數位策略顧問

・因應數位轉型/組織調整、各種客制化內部訓練課程以及人力需求協助

・那邊需救火就往那邊去～

合作方式從數月至數年不等，有2個月～1年的專案型合作，也有每年續約的長期合作。

上述工作看起來涵蓋層面頗廣，其實不脫離數位產品經理專業領域。我曾經婉拒過朋友轉來的數位行銷案子，對方好奇問：「產品經理也要懂數位行銷不是嗎？」

對於產品經理來講，要切入數位行銷專業不會太難。但市場上數位行銷專家非常多，已經有點擁擠了，不需模糊自己定位貿然切入不同的市場。

人多的地方不要去！
多花點時間找到藍海定位比搶進紅海市場更省力～

§ 獨立工作者秘訣四：建立無須名片的人脈關係

我所有的案子全是朋友/前同事/客戶轉介而來，這些伙伴們在業界也都是相當專業人士，有他們的轉介口碑，合作洽談相對省時省力。

當然也有聊過後覺得無法協助之處，有時會轉介其他適合的朋友，或者評估後建議對方找正職職缺更為適合。數位領域分工極細、圈子說大也不大，魚幫水水幫魚，正向的善意回饋會帶來更多的善意合作。

另外，千萬別輕忽「前同事」這個圈子。曾經我也覺得我沒有人脈。大部分的人脈經營書都教我們：「中午別一個人吃飯」、「多多參與聚會打進XX圈子」，但我因為家庭因素，所有晚上的聚會幾乎無法參加，中午也幾乎一個人看著書邊學習邊吃飯，跟同事往來也就是工作上的專業合作，沒想到成為自由工作者後，許多案子都是前同事轉介來的。

對現在的同事好一點，他們可能是你未來的人脈！

不過這樣的（佛系）人脈經營模式，有很多前提條件：

1. 是否有經濟壓力需求？

有經濟壓力的朋友，我會建議除非案源穩定，不然千萬別放棄正職工作。經濟壓力會導致你什麼案子都接、甚至削價求售，造成一種窮忙的惡性循環。

2. 經營穩定後，是否要繼續維持現況、或者成立公司追求更大的成長？

如果是後者，勢必面臨更高的人事成本，為了支撐這樣的人事成本，就必須要有更多案源，以及更高的資源投入在行銷宣傳上。這會是一個正向循環還是負向循環，就端看個人操作了。

3. 接案類型是否需不斷開發新客，還是有回頭客或者長期合作？

我們以一般產品行銷與經營來論，如果一個產品需要不斷開拓新市場，它的新客開發成本會非常高。但如果業務範圍有6成甚至8成以上是回頭客，相對省時省力。接案市場也是如此。

§ 獨立工作者秘訣五：為自己價值定個適合的價格

自由工作者如何定價，網路上有許多人寫了各種評估技巧，例如以下這幾篇，就不再贅述。

自由接案者該怎麼報價? 適用各種專業的3種報價原則
https://aslashie.com/3-methods-of-making-a-quotation/
接案！我要怎麼報價？
https://blog.akanelee.me/2017/06/15/how-to-calculate-your-offer/

但這些是原則，而非關鍵點。

從經濟學來講，價格定義無非供給與需求。我談一個新案，大約一杯咖啡（1～2小時）便可確定要不要合作，不需要花太多的力氣去說服對方。所以高價值（價格）的關鍵點為：

1. 客戶需求的強度和信任感：

需求強度在於能否直接命中客戶的困難與問題點，並讓對方相信你能解決。信任感說來模糊但原則簡單，案子轉介前的朋友客戶口碑介紹，過去的經歷和現場傳達出來的專業，都是信任感的建立。

前陣子幫某新創公司救火帶案子，Business Plan 募資完成後4個月系統還沒啥進展。第一次團隊會議，幾個小時內協助擬出MVP策略、產品功能結構、團隊任務分配、最後連幾頁wireframe都順手畫好了。會議結束後團隊成員面面相覷：「怎麼這麼快東西都出來了？那我們過去幾個月都在幹嘛？」

2. 慎選客戶，找到認同專業價值的客群：

這世界還是有明白專業價值的人，但重點要知道他們是誰。我的客戶定位多是已經數位化或自有網站5~10年以上的公司，他們很清楚目前遇到的問題點來尋求合作。但如果是完全數位新手或者是傳產初入數位領域，要花非常多的精力從頭教起，對方才能明白為何要付這樣（高）的費用來找你合作，就很耗時耗力了。

我很喜歡看美國創業實境節目「創智贏家 Shark Tank」，有次創投的話讓我印象很深刻：「千萬別花精力去教育一個新市場。龍蝦最初被大家視為垃圾，到它被市場廣為接受成為頂級食材，這條路走了50年」

獨立數位產品顧問的接案工作，也算是一個新市場開拓。如果我當初選擇先教大家什麼是數位產品經理再來接案，可能早就陣亡。因此走了一個穩健簡單的路：直接幫有經驗的客戶解決困擾已久的問題，讓對方體認到產品經理的專業與重要性，這樣就容易多了。

除此之外，這行是否有其他委外競爭者、自己是否有經濟壓力非接此案不可，都是影響價格的因素之一。因此再次強調不鼓勵大家隨意辭職接案，當你有經濟壓力時，再糟再低價的案子都會去接，網路上有非常多的血淚史，就不多提了！

§ 獨立工作者秘訣六：清楚自己的限制與成長需求，想像不可能的可能

原先成為自由工作者實為誤打誤撞的無奈之舉，為配合家人小孩，放棄了優渥的薪資以及各種升遷機會，回到家中一切歸零。剛開始也有點悶，後來想想，與其花時間抱怨，何不把生活中的種種限制當作必要條件來重新思考：如果我必須4點下班回家帶小孩，那找到一個符合這樣前提條件的工作模式；如果職場上沒有空間，那就自己想辦法搭出一個舞台吧～

成為自由工作者後的第2~3年，案源與收入都相當穩定、甚至忙到需拒絕案件時，我也曾仔細分析未來發展，要擴大規模經營還是維持現況。我不斷問自己一個問題：是否非規模化成長不可？

這個問題我足足思考了一年，當時並沒有《一人公司：為什麼小而美是未來企業發展的趨勢》這本書提供分析解答，後來我得到的結論和這本書差不多。

《一人公司》讀後心得筆記：如何實現理想收入，生活也不忙碌？
https://rich01.com/company-of-one-book/

● 不追求擴張與成長，可以花更多時間專注在每個客戶身上，得到客戶的信任，也更能協助口碑行銷。（書本第10章：一人公司可以真正從口碑行銷中受益，因為一人公司更容易建立這種人際關係，也與客戶保持更密切的聯繫。只專注在特定受眾，親自服務）

● 不成立公司不管理員工，不需花費時間在瑣碎的行政人事處理上。也無須因每月需付出薪資固定成本，被迫需要找更多的專案來養活大家，然後變得更忙碌。（書本第三章：「我每天都拼命賺錢？」好像做更多工作，就代表做得更好？其實更多不代表更好 — 更好才代表更好）

● 建構可擴展的合作系統、可靠的合作伙伴：身邊有許多工程師、視覺設計、數位行銷等專業人員，大家可以彈性合作、組成虛擬團隊共事，完成任務後團隊解散，直到需要再次合作！（書本第八章：可擴展的合作系統；第十二章：別當一匹孤狼）

● 經營模式與服務客群可以維持小而美不需成長，個人專業與思維必須要不斷學習成長，否則總有一天會被市場淘汰。正因為自己仍不斷地成長、所以根本不怕別人學。這樣反映在工作上可以無私地傾囊相授，或者成立Facebook 數位產品經理社團解決大家的工作疑惑，都是傳遞專業核心價值與思維的方式。我常給自己的一句話是：「如果擔心自己的專業被學走而缺乏競爭力，那表示前進的速度太慢！」（書本第九章：教你所知道的每件事；第十二章：累積社會資本）

過去所有的企業經營書籍都教我們要追求成長與規模化，而最好的思維方式，是回歸每個人自身的需求與人生的優先次序，找到最佳的平衡點；透過持續不斷地思考並質疑約定成俗的作法，從中找到自己創新獨特的路。

§ 獨立工作者秘訣七：Have fun ! 享受工作的樂趣

回想當初想法也很簡單，儘我所能幫助大家減少在網站APP開發/數位化過程中的痛苦。維持這樣的初心來工作，遇到許多好客戶，很多事情就無須太計較。對工作的態度，是樂在其中還是虛應了事，客戶都看得出來。每一次良好且開心的合作經驗，也會促成下一次的共事機會。

而接案的每一份工作，並不只是為了客戶，同時也在促使自己不斷成長前進。即便是畫了一千次的wireframe，每一次重新從首頁開始時，也是另一段新的探索過程。這樣不斷地將自己歸零與再出發，就是工作的樂趣～

曾有機會跟位資深的職涯規劃顧問聊天，他的一句話令我印象非常深刻：「當你資歷愈來愈深時，要讓這些資歷成為往前躍進的基石，而非成為障礙你的年齡包袱」

所以，如果你也打算辭職走接案斜槓的路，這幾句話請隨意聽聽～

首先，把網路上所有接案者摔過的跤全部看一遍，讓太美好的幻想回歸現實。接著廣泛嘗試，可以先從書上給的「套路」去試試，撞牆了再轉個彎。最後，廣結善緣，祝一切順心～

歡迎加入Facebook【數位產品經理不想公開的秘密 】私密社團，一起參與我們在數位產品經理領域的工作交流與專業討論！

數位產品經理不想公開的秘密 Secrets Digital Product Managers Don't Want to Disclose

這份問卷內容，來自於Facebook私密社團【數位產品經理不想公開的秘密】的加入申請問卷資料。成立這個社團的目的，是因為數位產品經理是一個非常新興且小眾的領域，希望透過這個私密社團，能夠召集各產業高手共同交流，也為有興趣的新手朋友們解答疑惑。

數位產品經理不想公開的秘密 Secrets Digital Product Managers Don't Want to Disclose

截至發稿時間為止，社團成員共有2870人，另外有600多人因完全未填問卷暫被拒於門外。因人力投入關係僅統計前2500份問卷。

§ 誰是數位產品經理?

彙整各方資料，我再仔細描述數位產品經理的工作定位。業界有非常多種產品經理，在社團申請問卷中，也可以看到傳統產業、科技業等產品經理或專案經理加入。其實這些工作內容與數位產品經理有些差異。為了方便解說，我彙整數位產品經理專業領域於下。

§ 數位產品經理專業領域

簡單來說，數位產品經理專業領域涵蓋四大面向 ：

一、商業目標 Business Goals

【關鍵能力】

1. 瞭解市場潛力趨勢與競爭者分析
2. 建構設計商業模式 (Business Model)
3. 熟悉lean startup 快速測試市場與MVP等技巧
4. 瞭解產品生命週期(Product life cycle)與制訂產品路徑圖(Product Roadmap)
5. 與行銷業務團隊合作市場開拓與增長策略(Growth Hacking)

「商業能力」這領域與一般產品經理專案能力相似，但主要差異在於對於精實創業(Lean Startup)操作的熟悉度。過去我們在商學院所學的市場調查與商業分析，往往需耗費較多的人力與時間投入，才能產出一份商業計畫書(Business Plan)。

但從2011年起精實創業(Lean Startup)一書出版後，迅速席捲網路新創圈，並廣泛引用至各大傳統產業的數位轉型策略。Lean Startup強調快速產出最小可行產品(MVP)，以最少的時間與成本驗證市場需求並快速學習以推出能夠生存獲利的產品。雖然在近幾年新創圈對於Lean Startup也有一些反思，但它仍是個非常好的產品開發思維，是數位產品經理必備的能力之一。

而成長駭客Growth Hacking雖然大多歸屬於數位行銷領域或者數位運營團隊下，但操作Growth Hacking時，有時也需透過產品功能優化來達成流量與用戶增長，因此數位產品經理也需具備AARRR(或是最近改稱的RARRA)相關概念，甚至透過數據檢視與使用行為分析、主動向相關部門提出增長優化策略。

二、使用者需求 User needs

【關鍵能力】

1. 市場區隔策略

2. 目標用戶定義與描述

3. 使用者研究/訪談

4. 需求分析與產品功能規劃

5. 具有基本使用者體驗UX設計能力

許多新手是由這個面向切入數位產品經理專業領域，特別是一些原本從事視覺設計(UI/UX)並具有「以使用者為中心」概念的朋友，在用戶需求訪談以及設計產品的過程中，對於功能設計和運作產品專案感到好奇，因此逐漸學習產品經理知識並轉職。

但這領域對於傳統軟體/硬體業的資深朋友也許會有一些困難。卡關的是必須將整個產品設計思維由「公司想做什麼產品」轉換為「使用者想要什麼產品」，需重新學習各種使用者研究方法、用戶心理與情境分析技巧以及UX相關文件製作，這是過去業界比較少觸碰的領域。

三、專案管理與產品開發Project Management

【關鍵能力】

1. 瞭解基本網站/APP相關應用技術以及具備程式邏輯觀念

2. 能清楚描述產品功能規格 product specs

4. 熟悉產品開發流程：瀑布式waterfall vs. 敏捷式agile

5. 與開發團隊合作並解決潛在風險、資源配置衝突

6. 排定優先次序與時間管理

與前述「使用者需求 User needs」相反的，這是傳統軟體/硬體業專案經理最擅長的一塊。一般主要操作是瀑布式開發流程，但近幾年也有相當多的公司嘗試敏捷式開發；二者各有優缺點，能夠將產品順利開發上線便是好流程。

四、數據分析 Data Analysis

【關鍵能力】

1. 指標Metrics定義與相關數據分析工具使用
2. 訂價策略與成本利潤分析 Pricing & Financial Modeling
3. 制訂數據策略、解讀數據、以及讓相關部門都聽得懂的簡報能力
4. 透過實驗與數據分析流量、轉換、留存，找出問題點並優化產品

這是相當有難度的一個領域。數據分析四字講起來簡單，涵蓋層面除了數位營運與數位行銷相關數字(GA那就不用說了)、還有Business Intelligence(BI)、利潤成本財務、統計與資料科學、甚至運用人工智慧/機器學習進行預測分析。透過這些資料的清理彙整分析解讀，運用在產品策略上。進一步還能熟悉各種A/B testing實驗操作，達成產品優化與用戶流量增長的目標。

所以說，數位產品經理這領域水很深，琢磨個十年以上都還有待學習成長之處。

§ 數位產品經理私密社團 成員分析

歡迎加入Facebook【數位產品經理不想公開的秘密 】私密社團，一起參與我們在數位產品經理領域的工作交流與專業討論！

數位產品經理不想公開的秘密 Secrets Digital Product Managers Don't Want to Disclose

§ 產品經理系列文章

產品經理PM第0講：誰是產品經理?

產品經理PM第1講：專業能力

產品經理PM第2講：從頁面拆解練習IA資訊架構(Information Architecture)

產品經理PM第3講：如何開始一個改版專案

Google UX Playbook — 【給新手的練習題】金融財經手機版

※ 數位產品經理的一天 — 在雲端管理跨國產品開發團隊

※ 數位產品經理的一天 — 以美國大型證券商交易網站為例 ( 奶爸老喬的矽谷觀察 Silicon Valley Old Joe)

「產品經理和資料科學家合作學到的10件事」這個講題，是我的前同事 Anadem在Product Tank Taipei活動上的分享專題。因為內容實在太精彩，我聽過2次還意猶未盡，特別詳記其中關鍵內容，並加上一些個人的工作心得，提供對 AI產品經理 有興趣的朋友參考～

Anadem是位非常資深的產品經理，曾在 Yahoo!參與搜尋和全球新聞平台產品開發，也曾在 LINE 開發電子商務相關產品。這份內容是他之前任職於 KKBOX產品經理時，與資料科學家合作，打造個人化音樂串流體驗的工作經驗分享。Anadem目前為Yahoo電子商務部門的產品經理。

產品經理的專業面向有非常多種，有人強項在於市場產品規劃、有人專攻UX與使用者研究、有人擅長產品專案管理，其中一個領域是資料分析相關產品，其中可再細分成二種：

1. BI（Business Intelligence）領域的合作，進行商業數據分析作為產品優化營運參考：

產品經理協助將企業內的各種營銷、業務、用戶（消費者）各種數據，例如互動、留存、興趣偏好、用戶分群，到營業端訂單、庫存、交易賬目、供應商等數據資料，匯集企業所處行業和競爭對手的數據，進行各項分析做為產品與市場決策參考。有興趣者可以看以下二篇文章：

• 数据产品经理必备技能之BI建设 | 人人都是产品经理
• 一个理想中的BI系统应该有哪些模块？ | 人人都是产品经理 - 阅读 - 掘金

2. AI領域與機器學習工程師合作，透過演算法實驗 / 調整，提供更佳的產品體驗：這就是本篇要談的。

首先，從演算法開始談起～

§ 演算法與機器學習

大致而言，演算法應用有以下幾個常見的面向：

1. Ranking 資料產出結果排序：例如Google 搜尋結果頁，就是透過演算法來做最佳的結果排序，試圖幫助使用者很快的找到想找的內容。
2. Classification 分類：如Google Photos，可針對相簿內不同照片主題自動分類。
3. Clustering 分群：依照相近行為的用戶來分群，最常見的就是電商平台中「買了這樣商品的人也買這些…」
4. Recommendation 推薦：如Netflix「因為你曾看了紙牌屋，所以我們推薦你這些影片」，和第3點不同的是，這是根據你的行為所做分析，而第3點則是比對與你相近族群的用戶行為來做分析。根據國外報告指出，Netflix的分析可以做到非常細膩。例如大部份做分類定義，只會粗分到「你喜歡中古世紀影片」，Netflix可細分到「你是喜歡中古世紀/浪漫/愛情/謀殺的影片」，這樣做出來的推薦就會更為細緻。
5. Prediction 預測：例如訂購機票時，可依據你所需的出發日期、地點來預測何時買機票比較便宜。另外還有常見的應用包含股票投資交易預測等。

所以在KKBox有幾個主要的演算法應用：

1. Serendipity： 「不期而遇的美好」，跳脫同溫層，推薦你沒聽過但可能喜歡的歌曲。
2. Ranking (card) 歌單推薦排序：從上萬本歌單中優先推薦排序出你較有興趣的歌單。
3. Clustering 歌單分群推薦：因為你聽過田馥甄的專輯，知道你喜歡她的歌，所以推薦給你其他類似歌單。
4. Ranking (song) 歌單內的歌曲排序：讓歌單聽起來順暢好聽。

5. Recommendation 推薦藝人：除了推薦專輯 / 歌曲 / 歌單外，還可以推薦藝人歌手。

6. Clustering 專輯/歌單分群推薦：基於喜歡的曲風推薦相關專輯/歌單。

7. Content-based recommendation：依據歌曲的曲風、音訊特徵、樂器等推薦歌曲。

除此之外，還有其他考量可作為推薦的依據，例如不同收聽時間提供不同的推薦；甚至「共用帳號」的辨識與推薦問題，例如媽媽早晨在家放兒歌給小孩聽，但到了辦公室就不想聽兒歌了，演算法能辨識/預測是否是相同使用者但不同情境而調整推薦內容。

要讓機器學習能夠辨識出各種音樂曲風，產品經理和工程師需要外部專家音樂製作人合作，先將曲風做完整的定義。包含透過樂曲節奏、使用哪些樂器、音頻高低、有沒有人聲等音訊特徵分辨，甚至搭配主題等，產出音樂「特徵值」。團隊討論出各種「特徵值」，將歌曲匯進系統後，交由機器學習解析歌曲的訊號、並且透過特徵值來定義歌曲類型。

但這事說來容易做來難，例如光是「搖滾樂」就可分成重金屬、龐克搖滾、前衛搖滾、輕搖滾、硬式搖滾、民謠搖滾、爵士搖滾、英倫搖滾等等，這就需要音樂製作人的協助，一一釐清並具體闡述各個不同曲風定義，例如節奏上的差異、樂器使用偏好等，好讓工程師進一步調校演算法模型，優化分類預測結果。

喜好是一種很玄的東西～

你可以問使用者他喜歡聽什麼歌，但喜歡有時是很直覺/很潛意識的東西，用戶往往僅聽前5秒歌曲，就可以決定他要不要切歌。有時在特殊情境下，例如很煩躁的時候，從未接觸古典樂的人，突然聽到一首小提琴演奏，整個人就放鬆下來。

因此推薦是沒有標準答案的，若要做到非常細膩，就必須不斷進行A/B testing，實際去測試User對這樣的推薦「有沒有感」。

而為了有具體的量化標準，產品經理和團隊會定義「有感」的指標包括如用戶會不會重複播放、加入最愛、加入歌單、觀看歌詞、觀看MV等。

但即便定義「用戶重複播放」代表「喜愛這首歌/歌單」的指標，這項指標也會有要注意的地方，例如我們可能會在短時間高度重播某首歌，然後就膩了不想聽。所以推薦機制不能僅考慮滿足標準就得出結論，還需思考後續整個體驗的調控，才不會讓體驗太單一或太硬。

因此推薦的作法需有很多面向的觀察和想像力，產品經理必須多方面地理解人的思維、行為反應與使用情境。透過不斷與工程師、編輯、其他產品經理交流，以及用戶觀察/數據分析，才會激盪出不同的想法做出更好的推薦。

§ 何謂機器學習

產品經理要和演算法工程師合作，應對機器學習（Machine Learning）有基本的概念與理解。Anadem 推薦了這個網站，協助大家深入淺出快速瞭解機器學習的其中一種原理與應用。

圖解機器學習

§ 1 . 演算法的推薦功能，如何開需求

負責Machine Learning的產品經理和一般數位產品經理的工作方式相當不同。一般數位產品經理通常會透過wireframe、UI spec.、Flowchart等來具體闡述功能需求。

但當產品是與Machine Learning演算法相關，較少是UI介面上的調整，因此如何清楚和工程師溝通需求具有相當高的難度。

而一般程式語言是透過 rule-based規則，來做邏輯上的描述。Machine Learning並不提供這樣的規則，而是由ML自行去學習得知。因此Anadem建議透過回答這七個問題，來跟資料科學家提需求：

1. 要解決的問題是什麼？(value proposition)
2. 誰是目標對象？(TA)
3. 衡量的標準是什麼？ (evaluation metrics / success metrics)
4. 基於什麼觀察，我們為什麼可做得好？使用者為什麼會買單？(our differentiator)
5. 為什麼是現在？(why now)
6. 什麼是成功的關鍵因素？(solution requirement)
7. 未來持續成長 / 優化的策略是什麼？(growth strategy)

工程師透過這7個問題的回覆，瞭解產品經理希望達到的目的以及短長期的目標。工程師著手training model，並且找到適合的使用者群體，並使用過去的歷史資料作為驗證。這樣可以知道這個model的成功機率多少（例如metrics希望能達到85%的成功機率）。

§ 2. 和一般數位產品Release 流程不太一樣

這邊講的數位產品，指的是網站 / APP / 穿戴裝置等，具有UI （使用介面）的產品。

圖的上方是一般UI設計類型的數位產品開發流程，下方是數據資料類型產品開發流程，可以看出二者有非常多的差異處。

§ 3. Eyeball test 的結果很重要

Eyeball test就是在工程師解析資料數據特徵值，並透過model訓練後，將初步歌曲推薦結果，找專家或內部人員來測試，請大家收聽，並逐一寫下他喜歡這樣的歌曲推薦或者想切歌的原因。

用戶切歌原因很多種，例如他就是討厭這個歌手、不喜歡某個樂器等等，非常個人主觀。

經驗上還遇到一種狀況是，Machine Learning推薦的歌曲，二首古典音樂中，突然出現人聲歌曲，用戶聽了就覺得很突兀，破壞聽歌的流暢性。因此團隊一起討論處理有人聲和沒有人聲的歌曲推薦順序問題。

另外即便是同一首歌，有的人只聽原唱，非常討厭翻唱。但如今有網路歌手翻唱曲相當多，很容易被推薦到。當這些不喜歡聽翻唱版的用戶聽到系統推薦了他喜歡的歌曲翻唱，就會立刻切歌。這也是透過人工eyeball test後才發現的使用者回饋，再讓推薦系統依據使用者偏好予以扣分。

喜好經驗感受一定要透過人的把關才能測出，因此上線前找不同類型的使用者前測和蒐集意見往往能有更多發現。

除此之外，Eyeball test還包含以下幾個關鍵點：

1. 用戶質性行為現象，需給予量化的數字描述
2. 從High-level去詮釋問題，避免單點描述：例如User說不要聽到某位老牌歌手的歌 →不要只針對那位歌手做排除，應觀察此現象並 歸類為「不要聽到老歌」的特徵行為。
3. 搭配適當工具，簡化並加速Eyeball test流程

§ 4. A/B 測試 — 不優化就會退化

A/B testing 是個非常重要但高成本的測試方式。有時想要做A/B testing的需求很多，要列出優先次序，這些是數位產品經理基本的專業能力。

另外，明確定義哪些是A/B testing的重要成功指標（Success metrics）很重要。以常見的「搜尋結果演算法」為例，它的目標在於「幫助使用者儘快找到喜歡的商品」

因此產品經理分別就「儘快」和「喜歡」這二種質化說明，定義出量化可衡量的指標：

1. 搜尋結果前 N 筆的點擊率 (per query CTR) → 表示是否達到「儘快」的目標
2. 搜尋結果放棄率(Abandonment rate)：用戶看到搜尋結果頁，但未點任何連結就離開了 → 表示用戶不喜歡這些演算法建議的搜尋結果
3. 搜尋結果重試率(Retry rate)：表示用戶找不到他需要的，所以必須重新搜尋。

§ 5. 資料型產品，要先有資料

好的推薦，來自對「使用者」及「內容」的細緻了解。

對使用者的瞭解，包含Persona 人物畫像、Demographic、偏好等等。對於內容- 歌曲的瞭解，包含明確定義特徵值「專輯、歌單、編歌單的人（Curators）、音訊解析、藝人歌手等」。而這些資料往往需由產品經理會同內外部專家，並與工程師討論打造出來。另外還可能遇到唱片公司所提供的曲風資料可能太「廣義」，例如中文歌曲通通定義成 C-pop 中文流行歌曲，這樣的資料是較難被細緻使用的。

§ 6.Data-driven vs. Non-data-driven

如果想轉型成資料數據型產品經理，要如何準備呢？重點就在這張圖～

當然，一般數位產品經理的基本專業能力，例如專案管理能力、排定優先次序（抓重點）能力、溝通力、主動積極發掘並解決問題、對使用者的深入好奇與瞭解分析力等等，也都是資料數據型產品經理需具備的專業能力。

§ 7.Product Strategy 要呼應 Business objectives

無論是不是資訊數據型產品經理，這個也是一般數位產品經理需具備的能力。

特別是當面對到喜歡各種新技術的Machine Learning工程師，產品經理一方面要讓工程師有空間去嘗試新的技術應用，另一方面也要跟工程主管討論/評估新技術產品落地的方向，確保資源的投入可以回收。

§ 8.先做 ROI 高的，且同步為重要功能打底

這個也是一般數位產品經理需具備的能力。只是面對Machine Learning技術開發以及大量的A/B testing測試成本，數據型產品經理需要更重視風險與成本效益。

因為Machine Learning做出來的推薦成效難以事先預估，演算法model開發下去才知道是否會有效，很有可能數月之後產出有限，A/B testing也並非能有每次都有 positive results，因此產品經理必須特別留意資源配置。在溝通方式上，產品經理不要問工程師能不能做得到，因為對能力強的工程師而言，程式很多都可以做得到；產品經理要問有沒有風險，風險多高等等來評估。

Anadem有提出上圖這個優先次序排列的基本原則，這個也是產品經理/專案經理必備的知識。

§ 9. 要讓每個推薦功能-定位清楚、具差異性

不同的演算法會產出不同的推薦功能成效。但若各種推薦功能的定位未能明確區分，可能使用者最後搞不清楚這個到底是推薦什麼；而對內跟工程師溝通時，工程師不會覺得怎麼都做同一個東西，產品經領要很清楚每個推薦功能的差異點以及比重濃度。

上圖Amazon的四種商品推薦，除了明確做出定位差異外，在UI使用者介面設計上，也要考慮購買流程動線「User Journey 使用者旅程和User Scenario使用情境」將推薦放在最適當的位置，才能產生成效。

§ 10.產品經理的價值

當產品經理在執行AI 機器學習專案時，PM不需要畫UI/Wireframe，機器學習又是個複雜的演算法，怎麼才能發揮產品經理的價值並獲得團隊的認可呢？

首先，要能問出好的問題！好的問題命中產品核心、刺激思考/討論，並找到有價值的執行方向。

AI 機器學習類型的資訊產品，最困難的部分往往不一定是技術本身，反而是如何針對不同場景使用情境，推出「棒的應用」。例如：工程師說他會做圖片自動偵測，產品經理就要去思考這樣的技術可以如何應用。

Netflix便是使用這樣的圖片技術來做影片推薦。演算法也許連續幾天都是推出同樣的10支影片，但透過Machine learning每天針對同一支影片更換不同的封面。也許前一天用戶看到的影片主圖並沒有觀賞意願，但隔天換了一張圖，可能就引發想看的興趣，這就是個很棒的應用。

而詮釋現象的能力，對於產品經理來講，更是一個具高度專業的要求。實務上常遇到，產出了數據和測試結果，然後呢？大家仍是不知道接下來該如何做！即便有了數據也無法對產品優化產生有價值的策略運作。「解析問題核心 → 提出洞見 →達成優化成效」這件事真的很難，也是值得產品經理不斷去思考學習的課題。

緊盯成功指標Success Metircs也是非常重要！這件事有許多層次需被落實執行：釐清何為成功指標、執行並依據指標檢核成效、排定優化優先順序等等。實務上對於許多公司而言，光是釐清哪些是應該追蹤的成功指標Metrics就相當有難度了。

成功指標是可以被調整的，產品經理不定期檢視哪些Metrics是時間/隨情境推移的，如果有更適合的Metrics，那就應該做適當的調整。

最後就是產品經理的策略思考能力！要能兼顧長期/短期目標、市場用戶需求反應、配合商務營運策略，來思考規劃產品，這樣的PM工作是不是很有挑戰性呢？

不管是哪一類型的產品經理，都不是只靠自己一個人就行了。所有的產出都是來自於團隊的合作與智慧。AI數據類型產品團隊，包含以下成員組成：

Machine Learning Researcher / Engineer

Data Scientist / Business Intelligence

Editor / Curator / Content Planner

User Experience Designer

Business Manager

Product Manager

Anadem特別提到，產品團隊要像個爵士樂團那樣大家共同合作，有主旋律演出、但也有隨興的一筆！接受並擁抱各種可能性與不確定發生，光芒不是只照在少數人身上，也 要讓成員每個人都有上台表演的機會！

歡迎加入Facebook【數位產品經理不想公開的秘密 】私密社團，一起參與我們在數位產品經理領域的工作交流與專業討論！

數位產品經理不想公開的秘密 Secrets Digital Product Managers Don't Want to Disclose

§ 產品經理系列文章

產品經理PM第0講：誰是產品經理?

產品經理PM第1講：專業能力

產品經理PM第2講：從頁面拆解練習IA資訊架構(Information Architecture)

產品經理PM第3講：如何開始一個改版專案

Google UX Playbook — 【給新手的練習題】金融財經手機版

※ 數位產品經理的一天 — 在雲端管理跨國產品開發團隊

※ 數位產品經理的一天 — 以美國大型證券商交易網站為例 ( 奶爸老喬的矽谷觀察 Silicon Valley Old Joe)

寫完上一篇【 Google UX Playbook — 金融財經手機版規劃指南】後，突然想到這題目適合給新手產品經理作為練習。有興趣的朋友可以來試試～

§ 步驟一：Persona

首先，我們從使用者角度出發，寫一份Persona。

Persona有的稱為「人物誌」、或者「用戶畫像」。原本我在產品經理PM第X講系列中打算詳細介紹，因時間關係先跳過，可以Google查【Persona 用戶】關鍵字說明。

金融財經網站的使用者依據不同的目的或金融產品使用，可以分成相當多種Persona用戶群。我們先來假設這次的練習題目為：

你是一個財經網站產品經理 PM，打算提供投資訊息、股票報價、基金報價、投資付費線上教學以及付費顧問諮詢。請設計出這個網站的首頁！

所以有哪些類型的使用者？

我先提示一下可能線索：

・有一群人可能剛進股市，有點股海資歷了但想要積極賺更多錢。

・有一群人可能較為保守，他們手上有一筆錢，覺得放定存不划算、做股票又怕賠太多，也沒時間看盤。

・有一群人什麼都不懂，想學投資但完全不知從何著手。

・其他…. 可以自行補充。

【練習題】
請針對上述情境，列出2～3個Persona即可。內容包含：

・虛構的名字
・圖片
・年齡
・性別
・職業
・收入
・生活形態描述
・投資經歷
・投資頻率
・預期到訪頻率
・使用產品動機、喜好
・痛點
・需求功能描述
・預計到訪頻率….等

在正式的專案工作上，Persona最好是經過一連串的資料Study、使用者訪談、團體討論取得共識、或者參考數據佐證等，產出3～N個不等的用戶族群區隔描述。我們這邊當作練習，所以簡單處理。

§ 步驟二：使用者旅程圖User Journey Map ?

在完成Persona後，接著會進行使用者旅程圖User Journey Map。

由於專案時程關係，不一定有時間做這麼多文件，這步驟我通常會跳過，或者交給UX designer處理。

但是，即使跳過不做文件，身為產品經理PM也要懂得用戶的使用體過程中的真實情緒、使用情境Scenario與不滿的痛點。並從中找出能解決用戶痛點的關鍵需求，延伸為功能設計的切入機會點。

【練習題】
請針對不同的Persona族群，分別描述他們在財經網站上的使用情境Scenario，並列出功能需求。

§ 步驟三：Epics / User Stories / 需求功能描述

接下來會依照專案開發流程：敏捷式 Agile 或瀑布式 Waterfall，來決定功能描述的文件產出方式。

● 瀑布式專案開發 Waterfall

在先前這篇PM第2講內容中，有張附圖提供了「首頁」的功能描述，可以參考看看。不過我那樣的描述比較細節，可以再概略一點，例如「提供股市大盤報價功能」這樣描述即可。

產品經理PM第2講：從頁面拆解練習IA資訊架構(Information Architecture)

● 敏捷式專案開發 Agile

敏捷開發流程在網路上相當多的討論，我就不多說了。此階段列出的比較是Epic這樣的抽象、high level的需求描述。

敏捷式的Epic、Feature、User Story描述可參考這篇：

需求的大小

【練習題】
請列出財經網站首頁預計提供的功能描述，Waterfall、Agile擇一即可。

接下來……..等等，你有沒發現一件事：

我們現在有2～3個不同Persona族群、每個族群有不同的痛點和功能需求，請問要怎麼塞入一個首頁頁面？

§ 步驟四：Prioritization 排定優先次序

對於產品經理而言，排定優先次序非常非常重要！資源有限，必須要將力氣放在關鍵有價值的事情上。

排定優先次序有幾個琢磨的角度，可協助PM思考：

● 廣度思維
・誰是我的關鍵用戶（TA）
・公司的政策營運策略
・市場規模
・競爭者分析
・我們的優勢以及差異化特色
・營收來源…
(有時還要考量公司各部門的政治角力運作…)

● 細部思維
・關鍵用戶的主要需求
・關鍵價值主張
・使用頻率高低
・影響營收/流量重要功能
・其他首頁上一定要有的內容…

有的資深產品經理可以直接就經驗值下判斷，有的需要眾人討論後、透過scoring system計分模式給予權重。這邊既然是練習題，那就自行決定。

【練習題】
請針對前面的功能列表/User Stories，排定P1~P3不等的優先次序。

【權重定義】以下提供簡單的定義：

P1：一定要做的功能。不做無法上線
P2：必須具備的功能，但可晚一點上線
P3：nice to have，有資源再做

§ 步驟五：繪製Wireframe線框圖

產品經理 PM 需不需要會畫Wireframe？

我建議如果有UX designer，應該是由UX人員來畫。但是身為一個PM，最好也要會畫Wireframe。我至少畫過上千張Wireframe，之後會在產品經理PM第X講系列中再做描述。

簡單來講，Wireframe可分為Lo-Fi和Hi-Fi Wireframe。我自己通常直接出Hi-Fi 版本，一次將細節確認清楚，省得來回溝通。新手PM可以從Lo-Fi著手，慢慢加深細節。

※ Low-Fidelity Wireframe 低擬真 Vs. High-Fidelity Wireframe高擬真 範例請見下文描述～

What Is The Difference Between Low-Fidelity and High-Fidelity Wireframes?

製作Hi-Fi Wireframe的好處是，使用相關軟體簡單設定，就可以直接製作成Prototype測試原型。缺點是有時會限制UI Designer的想像力，或者一下子直接落到功能細節，缺乏更廣泛的討論以求更佳的體驗設計。但這樣的練習是有必要的～

進到這個階段時，可能會發現步驟三的功能描述不夠詳細，因此繪製Wireframe時，可以再繼續補上細部功能描述。

【練習題】
依據前述文件，並參考 Google UX Playbook For Finance前文，繪製出財經首頁Hi-Fi Wireframe。

Google UX Playbook — 金融財經手機版規劃指南

大家完成了嗎？如果能依照這樣的流程做完，基本上已經能熟悉專案中的需求與介面規劃階段。希望讀完這篇文章能有所收穫，也歡迎加入Facebook 【數位產品經理不想公開的秘密 】私密社團，一起參與我們在數位產品經理領域的工作交流與專業討論！

§ 產品經理系列文章

產品經理PM第0講：誰是產品經理?

產品經理PM第1講：專業能力

產品經理PM第2講：從頁面拆解練習IA資訊架構(Information Architecture)

產品經理PM第3講：如何開始一個改版專案

AI時代的數位產品經理-與資料科學家合作的10個關鍵

Google UX Playbook — 【給新手的練習題】金融財經手機版

※ 數位產品經理的一天 — 在雲端管理跨國產品開發團隊

※ 數位產品經理的一天 — 以美國大型證券商交易網站為例 ( 奶爸老喬的矽谷觀察 Silicon Valley Old Joe)

前陣子 Google 提供各產業手機的網頁設計指南 UX Playbook，涵蓋電商、新聞媒體、旅遊、金融財經、不動產以及顧客經營等領域。

金融財經UX Playbook 共有106頁英文內容，因為我約有10年工作經驗在金融財經數位平台產品經理 Product Manager領域 、也負責過亞洲多國股市網站（台港韓印東南亞等），就來幫大家中文化說明一下～

首先，來定義一下金融財經的範圍。

在我曾負責的各式各樣的數位平台中 — 媒體、電商網站、線上課程、會員經營、保險、股市、理財金融等，我覺得金融財經領域的數位產品經理工作是非常有難度的。它需具備有二個面向的專業：金融財經背景＋數位產品規劃能力，要找到這樣跨領域人才很不容易。

金融財經平台又依照金融產品的差異性，有非常多具Domain Knowledge的功能機制設計，純粹財經新聞網站我們就不多說了。股市平台會有報價串接、線圖公式邏輯、投資組合、投資商品推薦篩選、線上下單等，期貨/選擇權/外匯等也有不同的報價邏輯。保險商品的建議書平台具有非常複雜的精算與條款邏輯規範、以及個人的保單試算，更不用講整個數位銀行機制都相當的複雜。產品經理對於不同的金融商品結構以及使用情境就必須有很深入的涉獵，才能駕馭相關數位產品平台設計。

拉回來看Google 這份UX playbook for Finance，內容比較偏向銀行存貸上的設計建議， 針對以下六個領域，提供了25個 UX設計原則，以協助手機版網站規劃：

1. 首頁/著陸頁
2. 選單
3. 產品頁
4. 商品比較/訂價
5. 轉換流程
6. 表單優化

另外，也針對登入與註冊、付款、驅動APP下載等UX設計做詳細的說明。

在進入主文之前，這段提示非常非常重要！

我們在參考外部的UX設計建議時，要隨時記得「別人做得有效的設計，不代表自家相同的設計也有效，因為目標群眾TA和使用情境都可能不同，所以請別原封不動照抄。」最理想的狀況是做A/B testing加以驗證，不過這份playbook的建議，還是具有相當的參考價值。

§ 首頁/著陸頁設計

■ 原則一：請在第一屏提供清楚、價值導向的行動召喚（CTA；Call-to-action）設計

第一屏的CTA設計這件事我大概跟同事講了100多次了，若要提升轉換率，就要非常重視CTA設計，這也是值得投入資源做A/B testing的地方。可測試的 A/B testing 變數項目，包含CTA button按鍵的顏色、文案、底圖、位置等。

例如上圖 BettingExpert.com的註冊頁面A/B testing結果顯示，改變註冊區塊上的文案內容，竟然提升33％的會員註冊率。

■ 原則二：請在第一屏展示清楚的價值主張

如果這是一個新的平台、或者網站目的在於吸引新手加入，第一屏也應該提供清楚的「價值主張」，告訴用戶為何要使用我們的服務。價值主張包含以下三點：

1. 說明我們的產品如何解決用戶的痛點
2. 提供特別優惠
3. 告訴潛在顧客為何應使用我們的服務、而非競爭對手的產品

（但我覺得第三點要很謹慎使用，以免弄巧成拙，反而幫競爭對手做宣傳）

■ 原則三：為CTA排出優先次序

在UX設計上，產品經理必須能判斷CTA的權重！也就是PM要想清楚，在這頁面中，我希望使用者第一件事情做什麼、第二件做什麼，並且清楚地跟UX/UI人員說明。

上圖提供了非常好的CTA權重差異化UI設計示範。在Lemonade網站，觸發用戶去「Check our prices」是最重要的，所以用桃紅色底Button呈現、次要為「Watch the video」，這樣可以很清楚地看出設計層次感。

我曾看過有些網站/APP很重視CTA，但每個CTA的權重都給的一樣，結果使用者完全不知該點哪裡，頁面上花花綠綠的非常可怕，造成反效果。

■ 原則四：設計清楚的多種產品服務展示（icons）

有時候為了追求精簡美觀，有些人會把產品服務分類收到漢堡選單內，但切記一個原則 ” I see and I remember.” 有看到才會用，別讓使用者還要到處去找，影響使用者體驗。

現在這種設計相當常見（特別是在電商網站）。

■ 原則五：使用網友證言/評價以贏得信賴

這點我持保留！網友證言要謹慎使用。

如果是商品眾多的大型平台式服務（例如淘寶），網友證言或經驗分享對於平台營運是有效益的，無論網友是正面或反面的意見，皆能幫助使用者在眾多商品中作為選擇判斷參考。但如果商品不多的網站（例如品牌電商），就要很小心使用。網友的負評很可能會直接影響到網站（商家）本身的評價。

另外，網友證言的設計上，要不要顯示「證言人的照片」這件事情也很有趣。我曾看過一份國外的A/B testing報告，由於使用者對於照片上的人可能會有些刻板印象或過度解讀，所以反而不放照片效果比較好。當然每家的使用情境不同，所以以上結論僅作為規劃時的參考。

再延伸說明一點，有些主管或者新手PM可能一時看了報告後，覺得「網友評價」似乎能幫助銷售，就貿然決定開發這個功能。但並未想到一個關鍵點：

我們要如何吸引用戶願意回來評價？

這個incentive以及觸發的流程機制設計非常重要，其中有非常多的學問細節！最怕的是事前沒想清楚、工程師投入資源完成上線後，結果沒什麼人來回饋意見，那等於是白做工了。

另外有一個「網友見證」的作法，是邀請特定使用者作見證，例如瘦身廣告中的「使用產品之後，我瘦了XX公斤」。根據先前做過的使用者訪談，有些人覺得這個純粹就是廣告、有的人仍然會大致參考，端看行銷上如何操作！

■ 原則六：不要使用自動輪播機制！請讓使用者自己滑動

如果有常在看國外的A/B testing報告的人，應該都有注意到許多研究都建議不要使用自動輪播機制，特別是在手機的第一頻更不應使用。但在台灣中國大家都很愛用！而且還讓它一直自動轉動得非常開心。

「自動轉動」對於使用者的確是一種干擾，但它同樣有吸睛的效果。這點我建議大家直接下點閱追蹤，看看自家的數據分析如何。

以上是 【首頁/著陸頁設計】建議。大家可以發現這件建議其實適合各種不同類型的手機網站，並非僅侷限於金融類。

但這份對於金融財經產業的產品經理/UX人員而言，最值得參考的是它提供了數百個國外的財經網站範例，這些網站服務都很值得去瀏覽（當然有些要國外開戶比較麻煩），進一步思考為何要如此設計、並對應到各種使用情境。

由於這份文件有106頁，後面的內容會再擇期放上。如果讀了之後覺得很想嘗試財經專案，可以依照下文【給新手的練習題】，從使用者描述一直做到Wireframe練習看看！

Google UX Playbook — 【給新手的練習題】金融財經手機版

歡迎加入Facebook【數位產品經理不想公開的秘密 】私密社團，一起參與我們在數位產品經理領域的工作交流與專業討論！

數位產品經理不想公開的秘密 Secrets Digital Product Managers Don't Want to Disclose

§ Google UX Playbook

• Retail (零售、電商)
• Travel (旅遊)
• Finance (金融)
• Real Estate (不動產)
• News ＆ Content (新聞內容)
• LeadGen (潛在客戶)

§ 產品經理系列文章

產品經理PM第0講：誰是產品經理?

產品經理PM第1講：專業能力

產品經理PM第2講：從頁面拆解練習IA資訊架構(Information Architecture)

產品經理PM第3講：如何開始一個改版專案

Google UX Playbook — 【給新手的練習題】金融財經手機版

※ 數位產品經理的一天 — 在雲端管理跨國產品開發團隊

※ 數位產品經理的一天 — 以美國大型證券商交易網站為例 ( 奶爸老喬的矽谷觀察 Silicon Valley Old Joe)

前幾天有朋友請我幫忙估個價，將整個網站功能拆解後，依照經驗值抓個大致預算。於是想到這常被問到的主題：開發一個電商網站需要多少錢？

首先我們來看，想做電商有幾種方式：

1. 直接上拍賣、購物開店平台
2. 使用Wordpress購物車套件兜一兜
3. 電商開站套件模組＋客製化開發（俗稱套件開站工具）
4. 完全客製化開發

一般而言，除非業主很清楚自己的差異與獨特性需求，不然我通常會建議儘量用前3種方式營運。

而我工作上只接第4項，所以就來聊聊第4項的客製化功能價格。深入淺出說明「為什麼電商平台開發價格可以差到這麼大？」

＊請注意：以下純為個人與周遭經驗分享，歡迎各方交流但勿戰！感謝！

先從簡單的說起：【前端網站】也就是消費者會看到的網站

通常包含：

1. 商品列表：首頁、列表頁（商品分類）、商品搜尋、商品頁。

2. 結帳流程：購物車、金流選擇、物流選擇、結帳完成或失敗

3. 會員註冊相關功能

4. 查詢訂單相關功能

5. 相關通知信

這樣算是一個基本的架構。我們再往細節走，以下是影響報價的思考點：

首頁：有沒有需要手動上稿宣傳的地方（例如大圖輪播）？有幾個手動編輯版位？還是全都依照程式自動更新（例如只抓最新分類商品）？愈多需要手動上稿的，後台就要有相對應的欄位管理，價格愈高。

搜尋：只做關鍵字搜尋？或者可以依照價位、款式、分類搜尋？當然工時都不同。

商品頁：是長長一頁介紹完？還是會分好幾個tab頁面？如果要放上網友問答評鑑留言，需包含前台網友留言form與list、後台留言管理檢舉下架機制，再配上通知評鑑與留言系統信，整區又是另一種價格。

商品推薦區塊，是只顯示最新分類商品、最近熱銷商品、你曾經瀏覽過的商品？還是要用machine learning機器學習推薦「買過這個的人也可能喜歡的商品」？後者通常不是一般定位在「網頁工程師」做得出來的，需要另外買solution。

單純的購物車邏輯較不複雜，但如果搭配各種銷售方案外加折價券、各種運費計算等，這樣難度就不知是幾乘以幾倍了。

有遇過客戶詢問國外運費計算，這是一門很深的學問，除非訂單量大到人工處理不來需要系統自動計算，通常建議人工計算後回覆、或者抓個價格範圍/限定送貨國家明確可規格化的系統邏輯比較容易。

還有「加價購」，有的是做在商品介紹頁所相關商品折扣推薦，例如買手機下方出現手機殼加價折扣購買，有的是做在購物車下方做全站熱銷或小物折扣購買。程式邏輯和使用情境不太一樣，也都是不同的工。

所以在後台，個別商品自己特定搭配的加價購，例如買某A商品可搭配abc三種商品加價折扣、買某B商品可搭配bdef四種商品折扣…這樣的機制比全站統一設定一種加價購複雜多，成本也高。

金/物流：包含信用卡、虛擬ATM、超商取貨付款、線上付款超商取貨、宅配、貨到付款等，都要與外部廠商串接。對了，還有電子發票、發票捐款等。做得愈多、錢就一直疊上去。

結帳前還看要不要加入會員？有的公司可分為會員或非會員結帳。這個會影響到後續的查詢訂單流程。

會員區可以是另一整套機制，包含訂單瀏覽查詢、察看購物車、待購（下次再買）清單，再往細部做還有缺貨時的「有貨通知我」等，以及個人帳號密碼預設地址設定等。

還有系統通知信，包含加入會員歡迎信、密碼查詢信、訂購成功信、ATM繳款催促信、訂單取消信等等。

如果以上述從簡單到複雜功能而言，價格區間可從萬元到百萬元。

接著來看【內部管理網站】，也就是我們常講的「後台」

我們先定義：誰可以進後台？誰來負責維護後台的資料？

（A）自家公司員工：
品牌電商、或者小型電商平台多屬此。只有內部員工有權限，不開放外部人員上稿或查詢。

（B）自家公司員工、外部供應商：
這就要看內外人員的權責區分在哪，從中再細分外部供應商登入系統後可接觸的範圍。
一般考量點是節省內部人力，讓外部廠商可以自行上架商品、或者查詢銷售報表等，但不一定會讓外部人員接觸重要功能如訂單管理、行銷管理等。但有的會讓外部人員接觸部分訂單維護功能，例如供應商可自行維護訂單狀態，但不能取消訂單，這種細節就比較複雜，

（C）開站平台：
讓供應商可以自行上架訂價、設定行銷優惠、管理訂單報表以及自行開店。這完全是不同等級的系統設計。（看看人家momo、pchome、蝦皮的資本額與員工人數…。）當然硬要以較低成本做開站平台，還是有「小做」的空間。

簡單區分開發費用：1的話價格會落在數萬～百萬、2的話價格大概數十～數百萬、3的話價格就數百萬～千萬。中間的價格落差還有以下幾個考量：

後台商品管理系統：包含商品分類設定、商品查詢列表、商品維護頁面、上稿預覽頁面等。

商品部分可以做到非常複雜。簡單的商品名稱/價格/規格/圖片上傳等這是相對單純的。複雜的部分有二個大關鍵點：

1. 庫存怎麼管？
2. 有沒有各種行銷方案？

如果是做轉單電商，也就是沒有自行出貨、轉訂單給廠商出貨。大概會設定一個安全庫存人工手動調整。

如果是自有庫存，需串接ERP系統做到即時庫存，甚至多倉處理、多平台出貨管理或線下同時接單等狀況，就會相當複雜。

行銷優惠方案這是一個我不太喜歡碰的區塊，因為玩法太多種了，PM和系統分析對這部分需求和邏輯要掌控很清楚，不然整死大家。玩法舉例：

1. 全站統一折扣
2. 全站統一折扣但部分商品除外
3. 分館（依商品分類）折扣，但部分商品除外
4. 全站或分館買幾件幾折：例如3件75折
5. 策展型：部分商品幾件幾元：例如年終特賣商品3件199元
6. 策展型：挑選特定商品給予特定折扣，例如開學季文具85折
7. 依照不同會員身份給予折扣
8. 折價券玩法也是另一個坑：限時、限定商品可用、限制使用次數、限制折抵金額、限定折抵折扣、限定身份可用…

然後，行銷人員可能還會要求折上加折，例如1.全站折扣再加上7.會員身份折扣，但又怕低於成本要做防呆提醒，還要能依照折扣優先次序調整….千萬別這樣玩！

組合商品也是另一種行銷玩法（商品A＋B一個價、A＋B＋C一個價），需要有很清楚的品號與料號，還有搭配贈品選擇，這部分不只行銷包套複雜、庫存管理也有難度。

太複雜的功能最終只會累死大家，不止開發成本很高、測試期很混亂、最後上線使用時，操作人員可能覺得太複雜就不想用了，這就是一種浪費！

再來是訂單管理，我們先講前面提到的「轉單」：

如果是上述（A）模式，原則上我們希望訂單收進後讓系統自動通知供應商出貨，儘量減少人工作業（例如手動整理訂單在Excel之類的）。但實務上不可能每家供應商都有能力透過API自動接送並追蹤訂單，應變作法是至少要做到自動匯出訂單檔案、並能夠發送Email到供應商指定窗口出貨。

有的人覺得這樣內部員工要做太多事，所以採行（B）模式，也就是讓供應商自己上來維護訂單。這就牽涉到對方的人力以及銷售規模，並不是每家廠商都願意。

大量自行出貨的訂單通常會串接物流商系統批次處理訂單、外接第三方/超商系統出貨，這裡有許多業界慣例，相對而言比較少奇奇怪怪的需求。

訂單管理另一個複雜層面是逆物流，包含退換貨款項處理邏輯、系統與人工處理流程的界定等，訂單狀態要追蹤到那個細節、成本庫存歸屬等，是另一門學問。

供應商管理不見得每家都會有，例如品牌電商可能就不做。有的只做供應商名單與報表管理，有的開放讓外部供應商登入，就會串接到權限管理。

另外一個坑是報表管理。格式有月報/週報/日報/自行設定時間區間、內容有銷售報表、帳務報表、會員報表、行銷成效報表…等各種不同面像需求，搜尋條件又可千變萬化，除非錢很多不然儘可能不要做各種美輪美奐的dashboard。如果有外包工程師要接案開發報表管理，請務必明確定義需求後再報價。

會員管理與客服系統可大可小（其實每個功能都是可大可小）。有的只做簡單的會員資料查詢與維護、有的要串接CRM、有的還要做到客戶Email來函/電話對談記錄/網站留言管理等，差別就是工工工、錢錢錢。

警示系統往往是大家比較容易忽略、也不一定會做的。包含庫存警示、訂單未處理與異常警示、物流金流異常警示、以及其他各種系統面警示訊息。會搭配dashboard、log、email、簡訊通知管理人員即時處理。通常是看業務量大小決定要做的複雜程度。

再來就是人員權限管理。如同上述（ABC）三種模式，誰可以維護哪一部份功能、誰只能看不能新增刪除、有沒有開放公司外部人員進入、以及公司對於外部連線安全是否有特殊要求（例如鎖IP或者VPN登入）等等。

其他各種外部系統串接，如上述的ERP、CRM、電子發票財會帳務系統、電子報發送系統、廣告系統等等，中大型集團還有自己的會員系統等，有非常多的不確定因素，以及其他廠商的系統規格與變更、溝通與開發時程能否配合等。

還有一些基本費用，例如伺服器設備、頻寬、網域、SSL 、定期備份服務
金流申請、遠端備援、Load balancer等等，這通常就看自己的需求選擇來付。

另外一個可能會有爭議的是測試這件事，不在網路IT圈的人，可能覺得「承包開發就是要把系統測到好！」但光是手機的各種系統平台瀏覽器版本來看，「測到好」是個非常高成本的人力支出以及專業領域（想想看你要調多少台手機來測）。所以我們通常會定義哪幾支市面常用手機的哪些瀏覽器需測試，免得bug介面修改無限上綱。

最後一個是上線後續與維護合約。外包開發商給不給程式碼，程式碼的版權限制與使用範圍，如果自有工程師會接手外包程式、是否有教育訓練時數以及移轉成本？Bug修改的時間範圍、後續需求變更的時數成本等，都會影響到外包價格。

以上外包電商價格影響層面，其實就大概憑記憶寫寫的，如有遺漏歡迎大家補充。電商網站變形的話還有團購系統、募資平台、各種B2B平台、以及電商APP等，族繁不及備載，有緣再說～

來補充一個網友提醒的：

我們在開發平台前，有經驗的會先做流量預估、特別是瞬間流量，這個也會牽涉到開發人力/成本。

能撐起大量瞬間流量的平台結構，對程式與系統結構的技術功力要求相對更高。我曾經遇過實習工程師小做一個實驗性網站，老闆看了很開心問能否立刻上線，結果被工程主管攔下，因為我們當時日常網站流量大概就需數十台Server，這小網站必須整個重新改寫才能用。

因此後來工作上與外包工程團隊合作開發時，都會先看對方是否有大型平台開發經驗，工程師的經驗值、專業技術能力不同，當然報價也有差～

歡迎加入Facebook【數位產品經理不想公開的秘密 】私密社團，一起參與我們在數位產品經理領域的工作交流與專業討論！

數位產品經理不想公開的秘密 Secrets Digital Product Managers Don't Want to Disclose

§ 產品經理系列文章

產品經理PM第0講：誰是產品經理?

產品經理PM第1講：專業能力

產品經理PM第2講：從頁面拆解練習IA資訊架構(Information Architecture)

產品經理PM第3講：如何開始一個改版專案

Google UX Playbook — 【給新手的練習題】金融財經手機版

※ 數位產品經理的一天 — 在雲端管理跨國產品開發團隊

※ 數位產品經理的一天 — 以美國大型證券商交易網站為例 ( 奶爸老喬的矽谷觀察 Silicon Valley Old Joe)

在我數位產品經理PM職涯中，少說帶過數十個數位產品開發專案，其中九成都是網站平台改版。

打造一個全新數位產品和針對既有產品進行改版，專案的啟動(project kick-off)方式有所不同。

一個全新的數位產品規劃，需要更往前思考，分析目標的市場/競爭者/使用者等不確定因素，思考全新的商業模式的各種可能性，會花較多的前期評估企劃。當然也可能採取精實創業lean startup模式：直接做就是了，上線撞牆後再來調整。

改版專案通常有較明確的方向以及待解決的問題。原因可能是系統老舊、UX使用者體驗設計不良、公司業務調整擴張或打造新功能整合等。

以目前產品設計潮流以及因應技術更新快速，約略3~5年就會進行翻修大改。當然市面上也有許多知名網站已經存活10多年未曾改版，往往是因為系統架構過於龐大、程式邏輯複雜、加上開發的工程團隊已經不知道換過幾輪，改版茲事體大、牽一髮而動全身所以沒人敢動（我曾接過這種案子），所以就還是繼續撐著疊床架屋吧。

在剛接改版專案時，我所做的第一件事情，便是依照 產品經理PM第2講：從頁面拆解練習IA資訊架構(Information Architecture)，把既有網站平台拆解後列出資訊架構與主要功能。有些客戶會提供數年前的規劃文件參考，但通常既有版本上線後，數年間也會不斷進行功能調整，許多功能已經和原本的規劃設計不符，因此我通常不會參考這些文件。

列出既有網站的資訊架構後，會對網站全貌有清楚的認識。在同時以外部人員視同一般使用者的身份來看，過頁面時也會發現許多UX上的問題。此時可以一一記錄下來。

接下來，進行需求訪談。通常會有幾種狀況：

A：解決既有問題類型

有些客戶非常熟悉數位產品經營，能有條理的列出改版目標與所需修改的問題。但這種客戶可遇不可求，大部分是客戶敘述的非常模糊或者只有概念性的問題。這時候產品經理需要一些技巧來引導發掘問題。我通常把它稱為「聊天」階段：

“ 我們使用者反應網站很難用，會迷路 ”

“ 是那邊難用呢? 可以示範一下嗎? “

“ 搜尋找資料都找不到…. “

“ 通常是輸入哪些關鍵字呢? 你期待的搜尋結果是什麼呢? “

這其實是基本的用戶訪談技巧，目的是把許多抽象的描述轉化成具體的問題/流程/邏輯敘述。這個概念有點類似敏捷式開發裡的User Story自然語言敘述：

身為一個家長，我想要找住家附近的學校，這樣我可以瀏覽這些學校的評價。

（但我們這篇不談敏捷式等開發流程）

因為時間關係通常不會寫這麼多字，而且如果可能，我會嘗試把模糊字詞當場討論確認，例如：「什麼叫做附近的學校?」也許程式邏輯是GPS定位住家附近20公里，或者輸入設定同一行政區。只是這樣直接列出解法通常有風險，所以只當筆記附註參考。因為對使用者而言，所謂的「附近」往往只是一種感覺，有人的附近是希望走路可到、有人覺得開車可到、有些人要比較學區限制…等。如果有需要，還要做進一步的用戶訪談或測試釐清，這些可列為後續的「待辦事項：釐清住家附近學校的定義」。

而由於先前已經先把資訊結構列出，所以很容易依序引導客戶提出並立刻歸類各種需求描述。這樣的訪談過程約1小時至半天不等。

B：目標導向類型

除了上述直指需求問題外，有的改版專案會清楚列出欲達到的目標。例如我遇過這幾種：

” 增加新會員註冊 2倍成長 “

” 推出讓 SaaS客戶覺得 WOW (驚艷 )的功能 ”

這些目標往往意指新功能的推出或者既有功能優化，需要廣泛創新思考各種作法可能性。

假設我們的目標為「增加註冊2倍成長」，從產品經理角度來看，我們會先把新會員獲得(acquisition)等行銷宣傳策略放一旁，而專注於產品設計本身，此時可使用HMW發問技巧來思考：(How might we)我們如何將導入的流量轉化成新會員註冊?

在數年前規劃親子天下改版時，我們就設定了媒體網站上幾個會員轉換門檻：投票、測驗、文章兌換，以及觸發動機：遊戲化機制Gamification親子幣點數累積。從這樣的想法出發再延續到完整的互動流程動線、CTA(call-to-action) UI設計，會員數據定義與收集、點數換算與後台管理等一連串的機制設計。

C：不知道問題在哪裡的類型

這樣的改版出發點也滿有趣的。客戶覺得好像應該要改版、隱約覺得應該有問題要解決、應該可以做的更好，但又不知道要改什麼、或者怎麼做比較好。

這時候會有比較全面性的訪談。包含公司各相關部門(stakeholders)、外部使用者訪談等，從中彙整出需求列表，設定改版目標，並配合公司策略方向排定優先次序等。

數據分析以及使用者訪談

在改版專案進行前後，也需檢視既有數據資料、並視需要安排各種使用者研究。而在進行大改版之前，如果時間充裕狀況下，有時我會建議幾個重要頁面或使用流程先做幾輪小優化、將數據調至滿意後，再以此為基礎進行大改版。

有時既有版本的數據追蹤碼埋設不夠完整，能提供的分析資訊不夠，會建議先將既有版本的埋碼補上，等有清楚的數據資料再進行改版。

當然如果既有網站問題非常明顯，例如有些功能流程使用者早已抱怨連連，就直接對症下藥進行，簡化數據分析以及使用者訪談階段。。

特別一提的是，既有數據分析僅能分析既有使用行為、從中發掘目前遭遇的問題。如果新改版的目標在於擴大市場或是創造新使用行為，既有數據較難以反映出此方向。

專案Kick-off meeting簡報項目

有些公司會從BRD( Business Requirement Document)、PRD( Product Requirement Document)、Business plan著手一步步進行，但我個人覺得如果目標方向已經很清楚，可以儘量精實簡單處理，不要為了製作文件而努力去產出一堆文件。

當前述分析都取得初步共識後，通常會召集專案相關人員舉行Kick-off meeting，產品經理簡報以下訊息：

1. 既有版本的問題

2. 改版目標

3. 改版重點功能介紹

4. (長程)Product Roadmap

5. (近程)專案時程

6. 專案成員R&R(Role & Responsibility角色與權責)

7. 風險與問題分析(Risk management & Issues)

8. 其他待議問題

當然有時還會視狀況附上以下分析：

1. 市場分析
2. 競爭者分析
3. 使用者分析
4. 數據分析
5. 商業模式描述
6. 成本與收益分析

接下來就進入專案規劃開發流程。

歡迎加入Facebook【數位產品經理不想公開的秘密 】私密社團，一起參與我們在數位產品經理領域的工作交流與專業討論！

數位產品經理不想公開的秘密 Secrets Digital Product Managers Don't Want to Disclose

§ 產品經理系列文章

產品經理PM第0講：誰是產品經理?

產品經理PM第1講：專業能力

產品經理PM第2講：從頁面拆解練習IA資訊架構(Information Architecture)

產品經理PM第3講：如何開始一個改版專案

Google UX Playbook — 【給新手的練習題】金融財經手機版

AI時代的數位產品經理-與資料科學家合作的10個關鍵

※ 數位產品經理的一天 — 在雲端管理跨國產品開發團隊

※ 數位產品經理的一天 — 以美國大型證券商交易網站為例 ( 奶爸老喬的矽谷觀察 Silicon Valley Old Joe)

§ 本文接續前一篇： 2.5天完成Google Design Sprint 衝刺計畫@親子天下(上)

【Day 2】完成書本「星期三&星期四」內容

10:00–11:00 票選最佳方案
11:10–12:30 比拼表決、繪製分鏡腳本storyboard
12:30–13:30 午休
13:30–17:00 製作prototype、撰寫Day 5使用者訪談腳本

§ 前一日的回家作業

鑑於大家對於分鏡腳本storyboard有些陌生，所以我請參與者除了閱讀 Sprint衝刺計畫這本書外，也上網查詢 UX design storyboard 關鍵字，多參考國外storyboard的範本，比較有概念。

另外同事中除了少數1、2位有製作prototype的經驗，其他人並不熟悉prototype原型製作，所以也請大家預先研究並試用相關工具。

課程開始

1. 票選最佳方案 流程

§ 美術館與熱點圖

Workshop第二日 一早我們先將前一日的方案草稿貼在牆上，排程一長列讓大家像在美術館觀看畫作一樣瀏覽。每人手上拿數十個圓點、便利貼、筆，靜靜瀏覽每個方案。流程如下：

1) 安靜看一份草圖
2) 在你喜歡的部分，貼上圓點
3) 特別喜歡的點子，可以貼2、3個圓點
4) 如果有疑問，將你的疑問寫在便利貼上，貼在草圖下方
5) 看完一張後，繼續看下一張草圖

美術館的重點在於讓頁面不言自明，畢竟一般使用者在瀏覽網站時，並不會有人在旁解說。所以包含文案設計、功能動線都必須讓使用者一眼就能明瞭，不需花時間猜測思考。Don’t make me think！

愈多圓點的部分，表示這個構想愈有意思（熱點集中），可以作為稍後決策的基礎。每組約7個方案，總計約20分鐘結束此階段。

§ 快速評論

接著是快速評論，先在組員中安排一位抄寫員，每個方案有三分鐘的時間逐一討論。

首先，所有小組成員走到第一個方案，由促進者以「看圖說故事」引導描述方案，並且喊出圓點票選較多「突出點」以及問題點。例如：

「 我們來看一下這個畫面… 最上方有個搜尋框，旁邊可以下拉選擇。
假設我輸入”旅遊”後，換到下一頁…
這裡有個投票功能獲得很多圓點（此時抄寫員要將此投票功能命名e.g. 熱點投票。並寫在便利貼上)，這裡有個圖示看不太懂，可能要說明一下」

其他組員可以補充疑問或看法，但方案作者要匿名且保持沈默，直到最後促進者邀請方案作者針對疑問點說明，這樣結束一個方案討論後，再換到下一張方案。

§ 稻草民調與超級票

當評論完所有方案後，除決策者外每位組員獲得一個大紅圓點，用來選出最佳方案、或者方案中的某一功能。

而最後決策者有三個標示為A的大紅圓點可投，決策者可以參考大家的投票來選擇，或者「非常任性地」不理會大家指選自己想要的。

我覺得這點相當反應現實狀況，因為有時老闆就是不會聽大家的分析建議、只作自己想做的（老闆就是有權任性）。這個衝刺計畫流程設計，相當能反映真實情境與人性面。

完成以上步驟後，結束票選最佳方案事項。

2.比拼或整合

有時最佳方案可能有同分或難以抉擇的狀況，例如我們同時二組雙題目進行時，發現有一組的票數非常集中在某一最佳方案上，另一組評分較為分散。

分散票數的就必須要做「比拼或整合」，可考慮將不同方案的優選功能合併在一起，或者乾脆製作二個原型(prototype)，交付使用者測試看結果。

3. 繪製分鏡腳本storyboard

分鏡腳本storyboard 是整個衝刺計畫中，我覺得難度僅次於原型製作Prototype的部分。

由於時間關係，我們只有1.5小時完成分鏡腳本storyboard。因此事先在組員的安排上，我們請了二位視覺設計師 UI designer當暗樁，所以分鏡腳本大家也就請視覺設計師擔任畫師一角。

分鏡腳本storyboard是將先前獲選的最佳方案，延展成一個故事連續圖。在著手繪製前，需要再結構化完整情境流程。有經驗的產品經理PM暗樁能夠協助此流程快速進行，不然這過程可能會卡很久還無法著手繪製，促進者可以請大家在討論過程中，儘量利用白板把想法繪製下來。

整體而言，1.5小時非常緊迫，有些組員想再多作調整，因時間關係我請大家在下午原型製作Prototype階段進行補足。

4. 原型製作Prototype

午休後就是整個衝刺階段技術難度最高的部分，Sprint衝刺計畫書中安排一整天製作Prototype，但我們只有一個下午時間可進行。

首先分工如下：

1) 原型製作(2人)
2) 整合者(1人)：協助製作者整合成可測試的原型
3) 寫作者(1人)：文案
4) 資料蒐集者(1人)：尋找圖片或模擬畫面素材
5) 採訪者(1人)：撰寫訪問腳本 — 五幕式訪談

原型Prototype可以用ppt、word、紙本或一些軟體製作，我們使用photoshop製圖+inVision做互動功能。在我以前做Prototype使用者測試的經驗中發現，Prototype愈擬真愈好，免得使用者無法關注在主要測試功能上，反而問一堆模擬素材上的問題，例如：這張圖怎麼看起來假假的、這個文案怎麼沒寫完等等。

當然這個牽涉到測試使用者召募的條件，如果你找的是 行業內熟悉網頁製作的使用者，即便拿wireframe線框圖當prototype也可以，國外就有好幾個類似的測試範例。但如果是找真正的目標使用者(TA)，像我們打算找一般的家長來測試，必須儘可能擬真。

1:30~5:00 安排製作原型。在4點時我們請小組集合進行操作排練。由於第三天就要立即上場訪談，身負重任的視覺設計師UI designer說時間相當緊迫刺激，好像在參加考試一樣。小組成員在分工後，也立即成立line群組，即時交流每個人的工作進度與素材交換。

在大多數成員忙著製作Prototype原型時，有位同事在旁撰寫使用者測試訪談腳本。在我協助多家媒體/網路公司數位產品開發顧問中，發現許多人不甚明瞭如何進行使用者訪談，包含完整流程、如何詢問等。而在Sprint衝刺計畫 一書中，有提出五幕式訪談技巧，從如何開場、引導話題、發掘問題點等，有詳細的說明。

【Day 3】完成書本「星期五」內容

最後一日的任務重點在於使用者訪談。我們依據書上建議安排2個會議室，分別作為訪談室與觀察室。訪談室中有受訪者、訪問員、錄影設備操作員。其他所有成員就留在觀察室，觀看投影並在便利貼上記錄訪談重點。

Google Design Sprint書中建議安排5位受訪者，這樣當看法出現分歧時，較能有充分的正反意見作參考。

由於這次Workshop有二組二專案同時印行，我們安排每位受訪40分鐘，前 20分鐘由A組訪談，後20分鐘B組訪談。受訪者背景與時間如下：

10:00~10:40 受訪1 — 集團同事，視覺設計相關
10:50~11:30 受訪2— 集團同事，數位課程製作相關
11:40~12:20 受訪3 — 一般家長，金融業
12:30~13:10 受訪4— 一般家長，傳產業
14:00~14:40 受訪5 — 集團同事，影音製作相關
14:40~15:00 訪談後小組討論(20min)

訪談過程可以發覺，有些功能原本大家都覺得非常重要，但使用者覺得還好；也有二極化的看法，例如有人覺得網友評價很重要，有的人根本不會參考。在觀察室的小組成員，也會在訪談中透過即時通訊，將想立刻詢問的問題傳過去，請訪談者提出。由於許多同事是第一次參與使用者訪談，從中得到豐富的回饋與改善建議。

訪談結束後為小組討論時間，大家先將手上的便利貼分類整理，並討論後續可改善的方向。Google Design Sprint 5天衝刺計畫，並非5天結束後就是終點。相反地，這只是個起點，如果這5天的成果具體，接下來可排入實際的專案開發時程（記得我們只做出Prototype吧~ 還沒套程式呢）。也可依據使用者建議，回頭再檢視分鏡腳本Storyboard，或者繪製更完整的Wireframe，然後再回來聆聽使用者的看法，焠煉出真正使用者所需的產品。

§ 參與成員的回饋

非常感謝此次親子天下同事參與2.5天Workshop。事後我們也做了一份內部同事的問卷調查，大部分的反應非常好，摘錄部分意見於下：

● 有趣、快速。希望以後還有類似的活動
● 和design thinking最大的好處，對於接下來的專案可以馬上進行。3天的模式很快速、且跨部門合作有幫助。
● 短時間內發想出二個案子很辛苦，發現每個人專注的點都不同，可以互相學習
● 是一個可以很快解決問題的方式，只是三天太快，有些細節沒辦法完成
● 使用者訪談很重要，對於草圖很有幫助。分三週隔三天，中間會忘記。
● 大家很厲害，短時間內可以想這麼多東西。
● 決策者的角色很重要，要引導到正確的方向，從發散到集中的轉換過程滿卡的。
● 訪談非常重要，而且要真的可以點。以往都用猜的。這次User回饋幫助很大。
● 工程師、視覺的角色很重要，幫助不同角度思考
● 我們真的很快的做出原型並聽到使用者的意見。例如行事曆功能，原本草圖討論時以為很重要，但事實上訪問後才發現沒那麼重要。可以用很低成本的方式測試。
● 我們平時對這些太熟悉了，所以反而遺漏使用者需要的。希望有更多的使用者訪談。
● 訪談者：集團內部與外部受訪家長提供的角度不一樣。內部的人理解很快，可以給很多意見。外部人的理解比較慢，這樣的差別滿明顯的，也不錯。過程發現很多同事的想法很有趣、邏輯性強。
● 剛開始覺得跟自己的工作內容有點距離。會議過程希望二組分開，人數可以再少。
● 希望以後有二階段的訪談，修改後再請使用者訪談做二次訪談。

我覺得Google Design Sprint 5日衝刺計畫是個設計相當完善的新產品實驗方法論，也能協助公司同事在整個數位化浪潮中，以最快速的方式瞭解數位開發流程、並幫助大家建立數位思維 — 這個在傳統產業/傳統媒體數位化過程中非常重要。

雖然平時不見得能撥出完整的5日來進行Workshop，但如果單獨抽出其中幾項，例如Crazy 8 瘋狂八、閃電示範、美術館瀏覽 等；這些工作技巧都能獨立使用在一般專案流程中，能有效協助產品經理PM加快產品開發腳步，並且快速驗證獲得使用者回饋。

§ 需要Workshop課程簡報檔的朋友，請加入Facebook私密社團【數位產品經理不想公開的秘密】 ，我將在整理後放到此社團中。另外，新申請加入者，請務必填寫社團問卷3題目，才會通過審核喔~感謝。

§ 上一篇： 2.5天完成Google Design Sprint 衝刺計畫@親子天下(上)

親子天下導入數位產品經理制（Digital Product Manager）已經有數年時間，主要平台開發專案都由PM來主導，到完成專案開發上線。

但產品經理PM的培訓並不容易，特別是現在各種專案都與數位有關，如何讓更多人具有數位開發能力更顯重要。去年年底時，親子天下陳世耀總監找我聊，希望能辦個workshop，讓公司更多同事能學習數位產品開發流程。

剛好我讀完 Design Sprint的5日衝刺計畫 這本書後，一直想找時間試行，與總監討論後便決定以此讓大家實際動手執行。

摘錄Design Sprint 衝刺計畫書介：

Google創投團隊認證的獨特5天5步驟工作流程，藉由設計、建立原型和邀請顧客實地測試構想，在5天內就能解決各種商業難題；並且已在Google內部及超過100家新創公司證實有效！

聽起來很酷吧！從星期一到星期五每天需完成的內容為：

參加同事主要為網路編輯(社群小編)、影音製作、工程師、視覺設計、產品經理等。由於同事日常工作繁多，撥出完整的5日實在太困難了，最後我們濃縮在2.5日內完成整個衝刺計畫。

除了挑戰縮時衝刺外，由於參與人數眾多，又不便分成二梯次，便決定在同一場地分成二組二題目同時進行。整體流程紀錄於下供大家參考：

會前會

在Workshop的前二周召集10分鐘快速會議，向所有參與同事介紹Design Sprint 衝刺計畫流程，並且提醒需先預做的作業。

在書中並不需有此事前作業準備，一切都到Workshop Day 1時進行即可。

但由於我們是將書本「星期一&星期二」濃縮在第一日就要完成，因此原訂於Day 2上午的外部觀察 閃電示範 就需請同事預作準備。

閃電示範 是讓每個組員以3分鐘為限，向大家分享1~2種外部相關解決方案。而為了收集外部參考，也需預先將衝刺計畫所希望達成的「長期目標」方向先定義下來，這些是與書上不同之處。

§ 會前提醒事項範例

1) 讀完書
2) 準備專家問題
3) 準備 閃電示範
4) Sprint期間請不攜帶電子裝置、手機等(休息時間才能用)
5) Sprint期間請攜帶書，有問題可以立即查詢

§ 角色分派

每組中需有一位決策者，由實務上與此專案相關的同事擔任(如PM或企劃)。另外，由我和世耀總監分別擔任二組的促進者角色。

決策者：小組討論過程中遇到爭議時的，擁有最後決策權的人。

促進者：在衝刺計畫過程中，負責管理時間、概括眾人觀點、從旁觀察做討論筆記，並假裝是外人問些笨問題：「是這樣子的嗎?」「為什麼呢?」，協助大家深入思考。

【Day 1】完成書本「星期一&星期二」內容

9:50 分組入座
10:00–10:05 Design Sprint 介紹、小組自我介紹
10:05–10:40 列出長期目標與問題
10:40–11:20 畫示意圖
11:20–12:30 請教專家-3位
12:40–13:30 午休用餐
13:30–14:00 HMW分類與確定目標
14:00–15:00 閃電示範
15:00–17:00 討論是否分工 & 四步驟畫圖法

1. 列出長期目標與問題

「衝刺計畫」第一件事是就是列出專案目標。

首先以終為始 Start at the end 從結果回推，思考專案長期目標。討論的重點在於樂觀思考，讓成員透過以下問題與討論、找到答案。

為什麼要做這個專案?
6個月、一年、五年之後，我們希望自己走到哪裡?

雖然這次我們已預先提供目標，但組員仍可更深入討論並再定義長期目標。

接下來換個方向，想像一年後這專案失敗了，會是什麼原因呢? 這是種悲觀思考角度，把危險假設轉換成問題，試著找出一些答案

如果沒人用怎麼辦 ?
如果市場改變怎麼辦?
如果競爭對手也推出怎麼辦 ?

我們在現場準備許多壁報紙，當各組成員討論時，促進者協助將討論中被提到的關鍵字句記下。有些好點子在討論過程中，可能一瞬即過，促進者能以旁觀角度適時筆記，這些在後面的繪製草圖會用到。

各組討論後，需將長期目標和問題(1~10多則等)寫在白板頂部，以確保後續大家的方向一致。

2. 畫示意圖

這一個步驟要將抽象的「長期目標」直接落地成流程步驟。

示意圖類似我們常說的使用者流程圖。畫面左方為「重要的角色」，中間為「文字和箭頭的流程圖」約有5~15個步驟，最右方為結局。

我們請小組成員站在白板前邊畫邊討論。一剛開始方向可能非常發散，甚至步驟流程太抽象，這時促進者的引導很重要。

我們不斷詢問成員：這個圖看起來正確嗎? 這裡是指什麼呢? 從中協助釐清想法。過程中發現並不是每個人都擅長抽象思維到具體化流程的轉換，往往需重畫數次才有較清楚的方向流程。

3. 請教專家

原本覺得大部分的同事對親子領域都相當熟悉且專業，因時間關係我打算刪除此一步驟。

但幾經思考後，決定邀請親子天下何琦瑜執行長和高階主管擔任專家角色。主要原因是，書中建議透過專家訪談，可以幫助我們重新想起已知、但容易被忽略的觀點。

另外，書本也強調決策者應全程參與衝刺計畫，但實務上要老闆主管們撥出完整的2.5天簡直不太可能，邀請他們擔任專家是種不錯的變通作法，一來可分享豐富的市場觀察經驗，二來大家對公司策略面有更深入的瞭解。執行後發現，專家訪談的收穫遠超過我所預期的。

組員聽專家講說時，需同時在便利貼上做筆記，這筆記叫做「HMW(How Might We) 我們可以如何…」

每人在便利貼上寫下聽到的一個問題。例如，專家講到家長都很忙，沒有太多時間找資料。這時就可寫下「HMW 我們可以如何讓User快速找到他要的資訊?」

每個小組成員忙著邊聽邊寫HMW筆記時，促進者也同步將專家內容筆記在大壁報紙上，每個專家寫一大張，完成後張貼於會議室中。

4. HMW分類與確定目標

午休結束後，進行書上 Day 1 最後一階段HMW分類與確定目標。

成員先將HMW便利貼貼在牆上，進行分類後再貼上各分類標籤。然後讓大家票選出最重要的問題。

每個組員有二票，每組中的決策者有四票。再將票數高的HMW貼回2.示意圖中，並確定主要使用情境與目標。此時可能需再調整示意圖，以便進行後續的草圖繪製。

5.閃電型示範

除了自行構想外，參考外部資訊也是不可或缺的。閃電示範正是以即有效率的作法來進行此任務。每個人輪流上台，在3分鐘時間內介紹1~2種他覺得值得參考的外部解決方案。

由於事前已請大家將示範網站列表準備在雲端文件，整個階段進行得非常順暢。

此階段我們也做了一些小調整。書上提到組員在台上講解時，需在旁邊的白板上同時畫出功能介面圖(手繪wireframe)，讓大家不會聽過就忘。

我們採行的作法是每一位簡報者介紹完後，幫下一位在A4紙上畫出介面圖，再逐一貼在牆上。

我覺得3分鐘的「閃電型示範」模式非常簡潔有效，在其他類型的Workshop中也可以考慮採用。優點是節省時間，透過快速繪製wireframe，便於日後回想時參考。我們平時在研究各種網站數位平台時，也可考慮用此方式製作筆記。

6. 繪製草圖 — 四步驟畫圖法

這階段算是今日最難的部分，許多人先前並沒有動手畫草圖Wireframe的經驗，所以我們也很好奇結果會如何。

步驟一：
首先，請大家站起來在會議室走動，瀏覽白板上的紀錄的長期目標與問題、會議室內四周牆上張貼的專家訪談壁報紙、HMW筆記便利貼、閃電示範wireframe等素材，各自將想法記錄下來。

步驟二：
回到座位上每個人獨自列出數個構想，並選出一個最佳構想。

步驟三：最具挑戰的「瘋狂8」
瘋狂8是限時8分鐘內，在折成8格的紙張上，為最佳構想列出8種不同的解決方案，也就是每一分鐘在一個空格上畫一種方案。

瘋狂8的論點是「短時間激發出來的想法最為直接有效」，不過難度頗高，因此我們並沒有實際去計時8分鐘時限，而是在2小時內讓大家自行完成四步驟繪圖法。

步驟四：
最後一件事要畫出方案草稿。從瘋狂八格中，選出一個最佳方案，製作分鏡腳本。首先，以便利貼畫出與使用者互動的情景，然後在旁邊加上文字說明，在沒有口頭解說時也要讓人看得懂。

最後繳交方案草稿給數位總監，結束今日工作。

§ 下一篇： 2.5天完成Google Design Sprint 衝刺計畫@親子天下(下)

§ 需要Workshop課程簡報檔的朋友，請加入Facebook私密社團【數位產品經理不想公開的秘密 】 ，我將在整理後放到此社團中。另外，新申請加入者，請務必填寫社團問卷3題目，才會通過審核喔~感謝。