你將在這門課更加認識何謂產品經理，從職業技能的角度切入，請來有多年產品管理經驗 曾任 Yahoo! 亞太區行動電信產品經理，miiCasa 使用者經驗設計總監的 Cloud 來告訴我們身為跨國企業的產品經理，會需要具備的特質與真實的工作樣貌。 先從大公司的角度分享，再以近年新創團隊的經驗，介紹創業團隊該如何面規劃產品經理此一職務 同時，也會仔細講解如何應用 Lean, Agile, 與 Scrum 等快速產品開發流程與工具

1. $!
Cloud!Chen!*-!!!
!
[9/18]

2. 講師介紹
!
!
YE(Cloud Chen)`.8O
0`4]Yahoo!^ miiiCasa^M
@_Yahoo!+.T8!`PQM
CMobile!?UH+3_
miiiCasa UED team T8)[`',L(
DA52`BN#-1V$`

3. !6

4. G'%6

5. 7 Z_miiiCasa
2011CES Innovation Honoree W
`
: ?UA5/*R?`JF
A5XKS];^
/Tablet App^TV_

6. 關於我
‧ travelmob : 台灣區行銷業務總兼 (Startup:2歲)
‧ miiiCasa / D-Link:使用者經驗設計總監 (Startup: 3歲)
‧ Yahoo APAC : Mobile產品經理
‧ Yahoo 奇摩 : 網站製作人
‧ 亞太電信：網站企劃
‧ Gigamedia：網站企劃

7. 內容
‧ 新創公司的組織特性
‧ 以使用者為中心的設計思維
‧ 善用精實創業精神開發產品
‧ 敏捷式產品開發 (Scrum)

8. 重點是「服務」
服務
服務的用戶
系統間的
用戶
社群(Social)
的串連
手機
通訊
錄
使用情境
裝置的串連

9. 加入新創公司

10. 新創公司
‧ 產品及市場不確定性大
‧ 資金有限，先算好你能燒多久，控制預算、認真看待每一筆
營收、每一個機會
‧ 目標隨時變動，團隊成員心臟要夠強、隨時整隊重新出發
‧ 組織扁平，避免官僚
‧ 團隊合作需要更緊密、避免掉球
‧ 可能加班、薪水打折
‧ 要做全球市場的產品

11. 關於人才的選擇
‧ 找到心態正確的人 - 能做小事、也能做大事
‧ 丟掉大公司的習氣，比你想像中困難
‧ 成員同質性高好嗎？
‧ 一群資深、聰明人一起工作可能是場災難？！
‧ 主動性格：願意幫你的前、後棒想
‧ 組織需不斷調整，沒有最佳組合

12. 我待過的新創公司
組織形式 A
使用者經驗設計程式開發行銷暨客服
產品經理(Researcher) 架構、互動設計視覺設計
產品團隊的leader背景：產品

13. 我待過的新創公司
組織形式 B
產品開發
行銷業務營運暨客服
專案經理程式開發視覺+架構+互動設計(UX)
產品團隊的leader背景：程式開發

14. 初創事業(產品) (Startup) 一個由人組成，專門進行新產品
或新服務的開發、未來發展具有高度不確定性的組織
創業(新產品)的管理需要一套能夠適合其強烈不確定性特質
的全新管理方式
開發 – 評估- 學習：將構想轉化成產品、測試顧客對產品的
反應，評估公司(產品)發展方向是否需要進行軸轉(Pivot)，
抑或該堅持下去
!

15. 傳統產品開發流程的風險
Concept/ Seed = Product Development
= Alpha/Beta Test = Launch / 1st Ship
!
‧ 將猜測當作是事實，在跟第一個真正的客戶聊過之前，
開始設計產品和花大錢。
‧ 上線之後開始發現當初預先設想的流程不符合實際需求
‧ 行銷計畫過於花錢
‧ 忙著擴張市場卻一天到晚作賠本生意
‧ 客戶群開始逐漸萎縮但公司視若無堵的繼續擴張計畫

16. 精實開發的好處
(Lean Development)
‧ 就算做出來的是一個沒人要的爛產品，也比延後推出要強
‧ 推出市場後，就能驗證後的學習心得：那些顧客會用你的
產品，以及為什麼他們會用？
‧ 找客戶聊聊，驗證策略是否有問題？
‧ 學習創造顧客要的價值！

17. MVP (最小可行性商品)
與Prototyping跟Concept testing不同，他不是用來回答
設計或技術上的問題，而是為了要測試重要的商業假設
MVP是為了幫助創業家儘快開始學習的過程，可以讓
「開發-評估-學習」循環的時間減至最低、又不費工夫
製作的一個產品。目的是要啟動學習的過程，而不是終
結學習的過程。
MVP不必完美，因為銷售對象是有遠見的Early
Adaptor，引起他們興趣不需要一個完美的商品，他們可
以接受只能解決八成問題的產品。(iPhone第一代)

18. 眼光放大，由小作起 – Zappos
從簡單的商品做起，只為了回答一個最重要的問題：是否已
有相當比例的消費者，希望能夠在網路上獲得令人滿意的購
鞋經驗。

19. Groupon的工人智慧MVP
http://web.archive.org/web/20090907045001/http://www.groupon.com/

20. 你能接受MVP嗎？
‧ 創業家(產品經理)的願景是改變世界的高品質主流產
品，而不是一個尚未完成、只有小部分人願意嘗試的
產品。
‧ 挑戰傳統產品開發觀念對於品質的要求
‧ 但是，如果我們不知道顧客是誰，我們也不知道品質
是什麼
‧ 精實創業(產品開發)不反對生產高品質的商品，但必
須是在贏得顧客的心為前提下進行。必須將傳統的專
業標準放一旁，儘快展開驗證學習。

21. 軸轉你的產品
‧ 無論MVP測試出來的結果是什麼，都不可以放棄希望，
這是學習旅程的開始。
‧ 經歷多次重複的過程後，就能發現產品或策略存在某些
缺失，必須改變前進的方向，就是所謂的軸轉 (Pivot)
‧ 軸轉通常不需要丟棄所有過去完成的工作才能重新出發，
而是要賦予已完成的工作新的目的，將學習到的資訊用
在新的策略上，以便找出更正確的方向
(註：Pivot 在英文當中，不是旋轉，也不是跳躍，更不是轉進、改變，而就是上述的「軸轉」。以動作來說，最
接近籃球運動中，持球者必須固定一腳，以該腳為支點，而移動另外一隻腳來改變身體方向，進行傳球或進攻)

22. 產品經理的工作

23. 定義產品
• ;”BcgirxGº !
• ;”y/V!
• ;”y
q5!
• ž9,%œ–IQ`{º^’ŠL

24. ¶º!
• ;”y!mˆ‚¸;?!pˆim !
• ;”yiY…_w+•dº!
• ;”ybD
y;Sf³›|nº

25. 要知道的技術真的好多...

26. 帶領團隊釐清問題，
而不是自己埋頭找答案

27. 將你想法透過閒聊
取得共識
O: ¹ http://www.mint-tastic.co.uk/

28. !
定期讀書會

29. 喜歡探究不同的解法

30. Android Box (miiiTV)
Apple TV
Notebook
MOD/Cable
Xbox
3C控有加分
iPhone

31. 不懂？
就從複製他人的經驗開始

32. 學習
以使用者為中心
的設計方法

33. User Centric Design
需要整個設計團隊的參與
共同為產品使用者負責
O: ¹http://maajoun.com/blog/2010/12/01/shimal/

34. 讓所有設計團隊提早
加入討論

35. 一起做競品研究，並且輪流分享

36. 理論方法教你架構思考

37. 初期的使用者研究
‧我們的產品可能有那些不同的使用者？這些使用者彼此
之間的關係是？例如：部落格服務有產生內容的部落客、
也有瀏覽部落格的人，他們之間的行為、需求各是什麼？
‧目前市面上相同的工具，有沒有什麼是他們使用上有產
生很大的障礙？不管是流程、功能的問題？
‧分析使用者的性別、年齡、職業、生活型態、家庭組成
等等不同變數，有沒有可能對於使用上造成不同的影響

38. 分出不同使用群體及
使用需求

39. 建立你的使用者人物描述
( Persona )
‧心智模式：對世界、自我、組織、環境所抱持的根深蒂固信念
與假設(assumption)
‧動機跟目標
‧在類似的服務工具上遭遇到的挫折
‧用這個服務工具主要的用法是什麼、使用頻率
‧一次使用的量有多大：例：一次處理一千張照片
‧使用這個服務或工具是非常享受、還是有其他目的非得要使用
‧技術程度及使用熟練度
O: ¹http://www.flickr.com/photos/nnova/2081056587/

40. 為什麼要建立personas?
‧ 對設計小組來說，使用者的需求跟目標需要變成一個大家共同的努力的方向
‧ 設計小組可以專注在一個可被操控的角色內設計功能，而不是設計功能給所
有人
‧ 設計小組可以容易的尋找到persona的使用群體，並且快速的針對這個群體
作訪談、開發跟測試
‧ 更容易確認需求，這也可以避免去開發一些使用者說他們要的功能，但實際
上這並不是最主要他們會使用的功能
‧ 設計的需求開發清單可以容易的被排序
‧ 設計小組在開發上的設計決議若有衝突，大家可以用Persona來做參考以便
作裁決
‧ 所有的設計細節可以經常用persona來做反思跟檢討，可以避免掉高成本、
頻繁的使用者測試

41. 拼貼使用者的生活跟喜好

42. Persona 的形式
(­±¹http://wiki.fluidproject.org/display/fluid/Fluid+Personas
O:]¹http://adpearance.com/blog/using-personas-in-web-design!
http://ebiinterfaces.wordpress.com/2011/12/01/personas-for-the-ebi-resdesign/

43. 建立使用情境
(User Scenario)
‧建立任務導向的使用情境
‧先從一個觸發的事件開始，然後開始描述這個事件的資
訊流向、使用者作了什麼動作、結果是什麼，利用
5W1H(Who, what, where, when, why, how)來描述
‧描述使用者遇到的一些障礙情境
‧從這個使用情境開始創造基本的需求清單 - 內容需求、
功能需求、需要的品質

44. 使用情境範例
Sharon有兩個小孩，一個七歲、一個三歲，假日時，平常
她都自己在家裡照顧孩子，也經常用iPhone幫小孩拍照、錄
影，但照顧孩子很忙，她只能利用小孩睡覺的時間整理照片。
Sharon的爸媽很想念孫子，經常想要看到孫子的照片，
Sharon買了一台iPad給他們， 希望他們可以透過iPad經常
看到孫子的照片，本來Sharon想要透過Line傳照片給他們，
但是Line太複雜，需要找到對話，再按下照片才能看，爸媽
實在不太會用，現在Sharon只好等回家有空，把照片sync
到iPad去，但如此一來，爸媽一個月才能看到一次孫子的照
片，實在有點不方便....

45. Product Backlog

46. ...
... !
1 2 Sharon
jŸiPhone
[:_

47. †M
iPad
†M0j
U

48. ²[:
uTŸK
'-¬R
/v¸=†
M¸
´ª
eŽ
1 l
• (Product backlogtPs€ http://www.mountaingoatsoftware.com/blog/a-sample-format-for-a-spreadsheet-based-product-backlog

49. 一定要在終端設備上測
試互動設計

50. 各種Prototyping的方式
WO:]¹http://www.hcii.cmu.edu/M-HCI/2010/MicrosoftStudio/process.html

51. 由工程師做技術
Prototyping

52. 使用者測試 - 觀察任務操作狀況

53. 設計團隊討論觀察測試的結果

54. 讓全團隊一起賣產品！

55. ‡£¯8Xz/¤E 善用雲端協作平台/軟體

56. 利用Google協作平台管理專案
Wiki

57. 利用Google雲端硬碟管理文件

58. 利用Google表單作量化調查
O: ¹www.inote.tw

59. 利用Axure製作
sitemap,wireframe,互動文件

60. 利用雲端平台協作系統流程圖
https://cacoo.com/lang/zh_tw/tour?ref=header

61. 多幫你的下一棒想一步
Visual Guideline±

62. 善用Scrum專案管理方式
加強團隊合作默契及效率

63. Scrum
小而美 控制風險
!

64. Sprint 1!
(1M)
Sprint 2!
(1M)
Sprint 4!
(1M)
Sprint 3!
(1M)
q o +
q
q
y«¢!
(3M)
}a!
(2M)
QA
q!
(2M)
!
(5M)
«¢·}a·
_Waterfall
Agile/Scrum

65. Scrum的開發方式
O: ¹http://www.agilebuddha.com/trainings-workshops/agile-scrum-training-workshop/

66. Scrum Team
‧ 一般的團隊有 5-9 人
‧ 跨功能團隊
‧ 程式、測試、用戶經驗設計等
‧ 全職團隊成員，不能被抽調
‧ 特殊職能可以例外 (例如, 資料庫管理員)
‧ 團隊自我組織和管理、包括task及時間的估算都是自己承諾管理
‧ 理想上都沒有職稱，但實際上很難做到
‧ 在Sprint之間調整團隊成員的變

67. Product Owner
‧ 訂定產品功能 (Product Backlog)
‧ 決定產品發佈的內容及日期
‧ 對產品的利潤負責 (ROI)
‧ 根據市場價值決定產品功能優先順序
‧ 如有需要，調整每個Sprint的產品功能和優先順序
‧ 接受或者拒絕產出成果

68. Scrum Master
‧ 專案的直接管理，不一定是PM，但是要有管家婆性格
‧ 領導團隊進行Scrum專案
‧ 排除團隊遇到的困難
‧ 確保團隊能勝任工作並保持高生產率
‧ 促使團隊中所有的角色及其功能緊密合作
‧ 保護團隊不受外來打擾，必要時必須阻擋來自高層干預

69. Scrum與UCD
‧ Scrum 是為了要去對應需求難以在前期明確界定的專案類型。 但
因為大部分專案都還是有嚴格的時間限制。 所以Scrum將把管理
重心放在需求澄清、以及需求控制上，並以時間限制的方式來做為
管理的核心限制。
‧ 所以Scrum或是Agile等方法的核心概念就是 - 既然使用者很可能無
法一下子定義出自己的真實需求，很多東西也很難紙上靠流程圖或
規格書來解釋清楚，那為何我們不盡快的做個Prototype？
‧ 這Prototype不用很完美，也不用一次就完整，只要能每次精進一
些。 每次都讓使用者能多看到些東西、能按些按鈕、能有些反饋，
這才會知道產品到底跟他想像的有沒有任何差異。 然後隨著逐次
使用者的回饋，每次重新計畫，讓下一階段的Prototype能越來越
朝向正確的方向。
~ ¹http://www.projectup.net/blog/index.php?option=com_contentview=articleid=6651%3AscrumItemid=19

70. Product Backlog

71. ...
... !
1 2 Sharon
jŸiPhone
[:_

72. †M
iPad
†M0j
U

73. ²[:
uTŸK
'-¬R
/v¸=†
M¸
´ª
eŽ
1 l
• (Product backlogtPs€ http://www.mountaingoatsoftware.com/blog/a-sample-format-for-a-spreadsheet-based-product-backlog
QN1¸
kApple iOS7
@Airdropm6
match
k
„e

74. c
g™7...

75. Sprint Backlog / Burn
Down Chart
Owner D1 D2 D3 D4
~ ¹http://www.mountaingoatsoftware.com/scrum/sprint-backlog
jŸiPhone
[:_

76. †M
iPad¸†M#
²[:
¥*}a “3 ©¦iOS guideline·4wireframe 4 8 4 0
Z.}a ¨ƒ e$˜Z./V 8 8 0 0
Šv}a ® °HiOS developer account¸}; ‘— 8 4 4 4
«¢ šAA ¡µprototyping‰Fg‰F7CŠ¸§)f†MŒJ
h‹˜ 4 4 4 4

77. Retrospective Meeting
‧ 每個Sprint結束都需要召開此會議
‧ 團隊每個人都需要發表以下看法：
‧ 這個Sprint作的很好、並且應該繼續維持的事情
‧ 這個Sprint作的很不好、並且應該停止繼續做的事情
‧ 在這個Sprint要感謝的事情或人

78. 團隊與Scrum
‧ 每隔一兩周或者一個月，每個人都可以看到實際並可以運作的產品，
此時團隊可以決定接下來要直接發佈，或繼續下一輪的功能加強
‧ 每個Sprint沒做完的功能就放棄，或排入下一階段
‧ 提供成員自由度，但非常仰賴團隊成熟度，因為除了完成主要工作
外，還需要經常溝通 (沉默寡言、對工作以外事情不感興趣的成員
會很難帶動)
‧ 先解決核心問題，再來處理小的需求
‧ 團隊要合作的很緊密，人員不可抽調
‧ 需要更多的規劃，而非更少的規劃，過度樂觀預估時程、專案開發
被干擾與中斷，往往都是Sprint檢討經常看到的問題

79. 溫習重點
‧ 加入新創公司的心態
‧ 用精實創業的思考方法檢視產品開發
‧ Work as one team的心態
‧ 以使用者為中心的產品設計
‧ 運用Scrum 作小規模、高度控制的專案管理
‧ 利用協作平台及工具提昇效率

80. Q A
farcloud@gmail.com