產品經理先修班

Transcript

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

2. ᾣ℩ࢺℚ
   ! ! Y\E(Cloud Chen)`.8O& >0`4]Yahoo!^ miiiCasa^M @_Yahoo!+.T8>!`PQM CMobile>!?U
   H+<3_ miiiCasa

   UED team T8)[`',L( DA52`<BN#-1
   V$` 
   >!6 G'%6 7 Z_miiiCasa 2011 "CES Innovation Honoree
   W ` : ?U
   A5/*R?`JF
   A5XKS];^ /Tablet App^TV_

3. ᗫ׵Ң ‧ travelmob : 台灣區行銷業務總兼 (Startup:2歲) ‧ miiiCasa / D-Link:使用者經驗設計總監

   (Startup: 3歲) ‧ Yahoo APAC : Mobile產品經理 ‧ Yahoo 奇摩 : 網站製作人 ‧ 亞太電信：網站企劃 ‧ Gigamedia：網站企劃

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

5. ࠠᓃ݊˜؂ਕ™ 服務 社群(Social) 的串連 系統間的 用戶 手機 通訊 錄 服務的用戶

   使用情境 裝置的串連

6. ̋ɝอ௴ʮ̡

7. อ௴ʮ̡ ‧ 產品及市場不確定性大 ‧ 資金有限，先算好你能燒多久，控制預算、認真看待每一筆 營收、每一個機會 ‧ 目標隨時變動，團隊成員心臟要夠強、隨時整隊重新出發 ‧ 組織扁平，避免官僚

   ‧ 團隊合作需要更緊密、避免掉球 ‧ 可能加班、薪水打折 ‧ 要做全球市場的產品

8. ᗫ׵ɛʑٙ፯኿ ‧ 找到心態正確的人 - 能做小事、也能做大事 ‧ 丟掉大公司的習氣，比你想像中困難 ‧ 成員同質性高好嗎？ ‧

   一群資深、聰明人一起工作可能是場災難？！ ‧ 主動性格：願意幫你的前、後棒想 ‧ 組織需不斷調整，沒有最佳組合

9. Ңܙཀٙอ௴ʮ̡
   ଡ଼ᔌҖό
   " 使用者經驗設計 程式開發 行銷暨客服 產品經理(Researcher) 架構、互動設計 視覺設計 產品團隊的leader背景：產品

10. 產品開發 產品團隊的leader背景：程式開發 業務 行銷 營運暨客服 程式開發 視覺+架構+互動設計(UX) 專案經理 Ңܙཀٙอ௴ʮ̡
    ଡ଼ᔌҖό
    #

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

    反應，評估公司(產品)發展方向是否需要進行軸轉(Pivot)， 抑或該堅持下去 !

12. ෂ୕ପۜක೯ݴ೻ٙࠬᎈ ! ‧ 將猜測當作是事實，在跟第一個真正的客戶聊過之前， 開始設計產品和花大錢。 ‧ 上線之後開始發現當初預先設想的流程不符合實際需求 ‧ 行銷計畫過於花錢 ‧

    忙著擴張市場卻一天到晚作賠本生意 ‧ 客戶群開始逐漸萎縮但公司視若無堵的繼續擴張計畫 Concept/ Seed => Product Development " => Alpha/Beta Test => Launch / 1st Ship

13. ၚྼක೯ٙλஈ
    -FBO
    %FWFMPQNFOU ‧ 就算做出來的是一個沒人要的爛產品，也比延後推出要強 ‧ 推出市場後，就能驗證後的學習心得：那些顧客會用你的 產品，以及為什麼他們會用？ ‧ 找客戶聊聊，驗證策略是否有問題？ ‧

    學習創造顧客要的價值！

14. .71
    ௰ʃ̙Б׌ਠۜ 與Prototyping跟Concept testing不同，他不是用來回答 設計或技術上的問題，而是為了要測試重要的商業假設 MVP是為了幫助創業家儘快開始學習的過程，可以讓 「開發-評估-學習」循環的時間減至最低、又不費工夫 製作的一個產品。目的是要啟動學習的過程，而不是終 結學習的過程。 MVP不必完美，因為銷售對象是有遠見的Early

    Adaptor，引起他們興趣不需要一個完美的商品，他們可 以接受只能解決八成問題的產品。(iPhone第一代)

15. ଻Έ׳ɽd͟ʃЪৎ
    – Zappos 從簡單的商品做起，只為了回答一個最重要的問題：是否已 有相當比例的消費者，希望能夠在網路上獲得令人滿意的購 鞋經驗。

16. (SPVQPOٙʈɛ౽ᅆ.71 http://web.archive.org/web/20090907045001/http://www.groupon.com/

17. Ыঐટա.71෗k ‧ 創業家(產品經理)的願景是改變世界的高品質主流產 品，而不是一個尚未完成、只有小部分人願意嘗試的 產品。 ‧ 挑戰傳統產品開發觀念對於品質的要求 ‧ 但是，如果我們不知道顧客是誰，我們也不知道品質 是什麼

    ‧ 精實創業(產品開發)不反對生產高品質的商品，但必 須是在贏得顧客的心為前提下進行。必須將傳統的專 業標準放一旁，儘快展開驗證學習。

18. ൿᔷЫٙପۜ ‧ 無論MVP測試出來的結果是什麼，都不可以放棄希望， 這是學習旅程的開始。 ‧ 經歷多次重複的過程後，就能發現產品或策略存在某些 缺失，必須改變前進的方向，就是所謂的軸轉 (Pivot) ‧ 軸轉通常不需要丟棄所有過去完成的工作才能重新出發，

    而是要賦予已完成的工作新的目的，將學習到的資訊用 在新的策略上，以便找出更正確的方向
 (註：Pivot 在英文當中，不是旋轉，也不是跳躍，更不是轉進、改變，而就是上述的「軸轉」。以動作來說，最 接近籃球運動中，持球者必須固定一腳，以該腳為支點，而移動另外一隻腳來改變身體方向，進行傳球或進攻)

19. ପۜ຾ଣٙʈЪ

20. ່֛ପۜ • ;”B
    c"girxGº ! • ;”y>/V! • ;”y> q5!

    • ž9,%
    œ–IQ`{º^’
    ŠL ¶º! • ;”y>!m
    ˆ‚¸; ?!
    pˆim ! • ;”y>iY… _w&+
    >•dº! • ;”y>bD
    y>;Sf³›|n&º

21. ࠅٝ༸ٙҦஔॆٙλε

22. ੭ჯྠඟᔾ૶ਪᕚd
    Ͼʔ݊Іʉࡽ᎘Ҭഈࣩ

23. ਗ਼Ыซجீཀඝ୨
    ՟੻΍ᗆ O: ¹ http://www.mint-tastic.co.uk/

24. ! ֛ಂᛘࣣึ

25. ఃᛇઞӺʔΝٙ༆ج

26. Android Box (miiiTV) Apple TV MOD/Cable Notebook Xbox $છϞ̋ʱ iPhone

27. ʔᏑk
    ఱ੽ልႡ˼ɛٙ຾᜕ක֐
    

28. ኪ୦
    ˸Դ͜٫މʕː
    ٙணࠇ˙ج

29. 6TFS
    $FOUSJD
    %FTJHO
    ცࠅ዆ࡈணࠇྠඟٙਞၾ ΍ΝމପۜԴ͜٫ࠋப O: ¹http://maajoun.com/blog/2010/12/01/shimal/

30. ᜫהϞணࠇྠඟ౤Ϙ ̋ɝীሞ

31. ɓৎਂᘩۜ޼ӺdԨ˲ቃݴʱԮ

32. ଣሞ˙ج઺Ыݖ࿴ܠϽ

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

34. ʱ̈ʔΝԴ໊͜᜗ʿ
    Դ͜ცӋ

35. ܔͭЫٙԴ͜٫ɛي౜ࠑ
    
    1FSTPOB
    ‧心智模式：對世界、自我、組織、環境所抱持的根深蒂固信念 與假設(assumption) ‧動機跟目標 ‧在類似的服務工具上遭遇到的挫折 ‧用這個服務工具主要的用法是什麼、使用頻率 ‧一次使用的量有多大：例：一次處理一千張照片 ‧使用這個服務或工具是非常享受、還是有其他目的非得要使用 ‧技術程度及使用熟練度

    O: ¹http://www.flickr.com/photos/nnova/2081056587/

36. މʡჿࠅܔͭQFSTPOBT ‧ 對設計小組來說，使用者的需求跟目標需要變成一個大家共同的努力的方向 ‧ 設計小組可以專注在一個可被操控的角色內設計功能，而不是設計功能給所 有人 ‧ 設計小組可以容易的尋找到persona的使用群體，並且快速的針對這個群體 作訪談、開發跟測試 ‧

    更容易確認需求，這也可以避免去開發一些使用者說他們要的功能，但實際 上這並不是最主要他們會使用的功能 ‧ 設計的需求開發清單可以容易的被排序 ‧ 設計小組在開發上的設計決議若有衝突，大家可以用Persona來做參考以便 作裁決 ‧ 所有的設計細節可以經常用persona來做反思跟檢討，可以避免掉高成本、 頻繁的使用者測試

37. ܳ൨Դ͜٫ٙ͛ݺ༧ఃλ

38. O:]¹http://adpearance.com/blog/using-personas-in-web-design! http://ebiinterfaces.wordpress.com/2011/12/01/personas-for-the-ebi-resdesign/ 1FSTPOB
    ٙҖό
    (­±¹http://wiki.fluidproject.org/display/fluid/Fluid+Personas

39. ܔͭԴ͜ઋྤ
    6TFS
    4DFOBSJP ‧建立任務導向的使用情境 ‧先從一個觸發的事件開始，然後開始描述這個事件的資 訊流向、使用者作了什麼動作、結果是什麼，利用 5W1H(Who, what, where, when, why,

    how)來描述 ‧描述使用者遇到的一些障礙情境 ‧從這個使用情境開始創造基本的需求清單 - 內容需求、 功能需求、需要的品質

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

    到iPad去，但如此一來，爸媽一個月才能看到一次孫子的照 片，實在有點不方便....

41. 1SPEVDU
    #BDLMPH   ...
    ...  !   1

    2 Sharon jŸiPhone< [:_ †M
    iPad †M0j
    U ²
    [: uTŸK '-¬R
    /v¸=† M"¸ ´ª eŽ 1 l  • (Product backlogtPs€ http://www.mountaingoatsoftware.com/blog/a-sample-format-for-a-spreadsheet-based-product-backlog

42. ɓ֛ࠅί୞၌ண௪ɪ಻ ༊ʝਗணࠇ

43. ΢၇1SPUPUZQJOHٙ˙ό WO:]¹http://www.hcii.cmu.edu/M-HCI/2010/MicrosoftStudio/process.html

44. ͟ʈ೻ࢪਂҦஔ 1SPUPUZQJOH

45. Դ͜٫಻༊
    
    ᝈ࿀΂ਕ዁Ъًر

46. ணࠇྠඟীሞᝈ࿀಻༊ٙഐ؈

47. ᜫΌྠඟɓৎርପۜl

48. "‡£¯8Xz/¤E ഛ͜ථ၌՘Ъ̨̻ழ᜗

49. л͜(PPHMF՘Ъ̨̻၍ଣਖ਼ࣩ 8JLJ

50. л͜(PPHMFථ၌೷ဿ၍ଣ˖΁

51. л͜(PPHMFڌఊЪඎʷሜݟ O: ¹www.inote.tw

52. л͜"YVSFႡЪ TJUFNBQ XJSFGSBNF ʝਗ˖΁

53. л͜ථ၌̨̻՘Ъӻ୕ݴ೻ྡ https://cacoo.com/lang/zh_tw/tour?ref=header

54. εᏍЫٙɨɓಏซɓӉ
    Visual Guideline±

55. ഛ͜4DSVNਖ਼ࣩ၍ଣ˙ό
    ̋੶ྠඟΥЪᎰ۰ʿࣖଟ

56. 4DSVN
    ʃϾߕ
    છՓࠬᎈ
    !

57. 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

58. 4DSVNٙක೯˙ό O: ¹http://www.agilebuddha.com/trainings-workshops/agile-scrum-training-workshop/

59. 4DSVN
    5FBN ‧ 一般的團隊有 5-9 人 ‧ 跨功能團隊 ‧ 程式、測試、用戶經驗設計等 ‧

    全職團隊成員，不能被抽調 ‧ 特殊職能可以例外 (例如, 資料庫管理員) ‧ 團隊自我組織和管理、包括task及時間的估算都是自己承諾管理 ‧ 理想上都沒有職稱，但實際上很難做到 ‧ 在Sprint之間調整團隊成員的變

60. 1SPEVDU
    0XOFS ‧ 訂定產品功能 (Product Backlog) ‧ 決定產品發佈的內容及日期 ‧ 對產品的利潤負責 (ROI)

    ‧ 根據市場價值決定產品功能優先順序 ‧ 如有需要，調整每個Sprint的產品功能和優先順序 ‧ 接受或者拒絕產出成果

61. 4DSVN
    .BTUFS ‧ 專案的直接管理，不一定是PM，但是要有管家婆性格 ‧ 領導團隊進行Scrum專案 ‧ 排除團隊遇到的困難 ‧ 確保團隊能勝任工作並保持高生產率 ‧

    促使團隊中所有的角色及其功能緊密合作 ‧ 保護團隊不受外來打擾，必要時必須阻擋來自高層干預

62. 4DSVNၾ6$% ‧ Scrum 是為了要去對應需求難以在前期明確界定的專案類型。 但 因為大部分專案都還是有嚴格的時間限制。 所以Scrum將把管理 重心放在需求澄清、以及需求控制上，並以時間限制的方式來做為 管理的核心限制。 ‧

    所以Scrum或是Agile等方法的核心概念就是 - 既然使用者很可能無 法一下子定義出自己的真實需求，很多東西也很難紙上靠流程圖或 規格書來解釋清楚，那為何我們不盡快的做個Prototype？ ‧ 這Prototype不用很完美，也不用一次就完整，只要能每次精進一 些。 每次都讓使用者能多看到些東西、能按些按鈕、能有些反饋， 這才會知道產品到底跟他想像的有沒有任何差異。 然後隨著逐次 使用者的回饋，每次重新計畫，讓下一階段的Prototype能越來越 朝向正確的方向。 ~ ¹http://www.projectup.net/blog/index.php?option=com_content&view=article&id=6651%3Ascrum&Itemid=19

63. 1SPEVDU
    #BDLMPH   ...
    ...  !   1

    2 Sharon jŸiPhone< [:_ †M
    iPad †M0j
    U ²
    [: 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
    c" g™7...

64. 4QSJOU
    #BDLMPH
    
    #VSO
    %PXO
    $IBSU ~ ¹http://www.mountaingoatsoftware.com/scrum/sprint-backlog    Owner  D1

    D2 D3 D4 jŸiPhone< [:_ †M
    iPad¸†M#  ²[: ¥*}a “3 ©¦iOS guideline·4\wireframe 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

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

    在這個Sprint要感謝的事情或人

66. ྠඟၾ4DSVN ‧ 每隔一兩周或者一個月，每個人都可以看到實際並可以運作的產品， 此時團隊可以決定接下來要直接發佈，或繼續下一輪的功能加強 ‧ 每個Sprint沒做完的功能就放棄，或排入下一階段 ‧ 提供成員自由度，但非常仰賴團隊成熟度，因為除了完成主要工作 外，還需要經常溝通 (沉默寡言、對工作以外事情不感興趣的成員

    會很難帶動) ‧ 先解決核心問題，再來處理小的需求 ‧ 團隊要合作的很緊密，人員不可抽調 ‧ 需要更多的規劃，而非更少的規劃，過度樂觀預估時程、專案開發 被干擾與中斷，往往都是Sprint檢討經常看到的問題

67. ๝୦ࠠᓃ ‧ 加入新創公司的心態 ‧ 用精實創業的思考方法檢視產品開發 ‧ Work as one team的心態

    ‧ 以使用者為中心的產品設計 ‧ 運用Scrum 作小規模、高度控制的專案管理 ‧ 利用協作平台及工具提昇效率

68. 2
    
    " farcloud@gmail.com