Please enable JavaScript.

Coggle requires JavaScript to display documents.

產品經理 - Coggle Diagram

- - - - 問題：
        1.可能因為缺乏價值、缺乏易用性、、缺乏可實行性、缺乏商業可行性而停擺
        2.結果不會這麼快產生，甚至需要經歷不同項目的產品探索，但公司的利害關係人會將探索項目視為交付承諾，導致產品團隊只是在交付功能項目
        
        替代方案：結果導向的產品路徑圖
      - 類型
        1.利益關係人導向的路徑圖：以交付功能為主
        2.結果導向的路徑圖：以「解決商業問題」為主
    - - 產品願景和策略：描述組織想達成的大局及實現大局的計畫
        
        產品策略：為了逐步實現產品願景，而打算推出的產品或版本序列。有可能指一種產品多個版本、也可能指一系列不同或相關的產品、或一系列的里程碑。
      - 商業目標：企業在一定時期的經營活動所要達成的成果
    - - 與利害關係人培養關係的秘訣
        
        對顧客、分析、技術、產業、事業都有深入的了解
        
        跟利害關係人坐下來談，聆聽他的想法與限制
        
        使用簡報在大型會議上溝通商業可行性是一個很嚴重的錯誤
        
        每個人關注的面向不同，簡報太模稜兩可 ->高擬真原型是比較好的方法
        
        集體開會的產出反而比較低，跟多個利害關係人私下開會，比較能獲得洞見
- - - - 機會評估技術（適用於小團隊或以上規模）
        回答4個關鍵問題
        
        這個任務是為了達成什麼專業目標（目標）
        
        你怎麼知道目標達成了（關鍵結果）
        
        這可以幫助顧客解決什麼問題（顧客問題）
        
        我們關注哪種顧客（目標市場）
      - 客戶信技術（適用於中大型團隊）
        
        由對公司非常滿意的顧客寫給執行長的信，說他真心認為新產品如何改善他的生活
        
        附上執行長對產品團隊的虛構祝賀信
      - 創業圖技術（公司草創時期）
        
        跟商業模式圖（business model canvas)、精實圖（lean canvas）同樣可以使用，儘快找到獲利的商業模式並降低風險
      - 了解4個關鍵風險
        
        顧客會購買或使用嗎？（價值風險）
        
        顧客知道如何使用嗎？（易用性風險）
        
        能打造出來嗎？（實行性風險）
        
        這個方案有助於事業發展嗎？（商業可行性風險）
        -財務風險
        -事業開發風險
        -行銷風險
        -銷售風險
        -法務風險
        -道德風險
    - - 故事對照技術（story map, 又稱為故事地圖）
        
        Jeff Patton 所創
        
        橫軸放時間或是顧客活動的描述順序、縱軸按細節的細膩度排列
        
        為每項主要活動增添內容後，可以把他們編成一組任務，並為每組任務增添故事
        4.因為是一系列的流程，所以可以看到故事與故事之間的串連
    - - 顧客訪談
  - - - 第一次使用易用性測試，一定要告訴參加者這只是原型，不是最終產品，且不是對參加者做測驗，而是對原型做測驗
      - 想辦法讓用戶待在使用模式，抽離批判模式
      - 根本上，你是想了解用戶如何思考問題，並在原型中找出軟體呈現的模式與用戶思考問題不一致的地方，這就是所謂的「反直覺」
    - - 質化的價值測試技術
        目的：了解客戶對於產品的「為什麼」
        不會從客戶反饋中直接獲得答案，但可以像拼圖一樣持續拼出需求
        
        步驟
        
        先訪談
        
        易用性測試：只有當客戶了解產品是如何使用，談價值測試才有意義，否則會變成客戶對產品流程的空談
        
        價值測試時要使用「高擬真的用戶原型」。但大家通常很和善，不願意說出真心話，此時有四個東西可以反應用戶的真實心聲：以金錢來證明價值、以聲援來證明價值、以時間來證明價值、以使用權來證明價值
      - 量化的價值測試技術
        目的：收集證據，收集有統計顯著結果的資料
        
        A/B 測試
        注意⚠️：「探索A/B測試」和「優化A/B測試」是不一樣的東西，後者是用來測試不同的call to action、按鈕不同的顏色等等。兩者概念上相同，但優化測試通常是表面、低風險的改變，例如分裂測試（50%50%）；前者則是讓99%用戶看到既有產品，1%客戶看到即時資料原型
        
        邀請型測試
        使用時機：當沒有足夠的流量時，可邀請一些用戶與客戶加入，雖然這些人的特性都偏向早期的產品使用者，但仍然可以獲得實際客戶資料
        
        探索客戶計畫
        參考探索客戶
        
        核心分析工具
    - - 假門測試（fake door demand test)
        (針對新功能）把按鈕或功能項目加入我們認定的用戶體驗中，但是用戶點擊按鈕時，不是把用戶帶到新功能，而是帶到一個頁面說明你正在研究這個新功能，如果他們有興趣可以留下email或電話，讓用戶報名當測試者
      - 登錄頁需求測試（Landing page demand test)
        （針對新產品）在網頁上，描述新產品的方式就像真的推出一樣，差別是讓用戶看到你們公司在構思這個新產品，有興趣的用戶可以加入一起討論開發
  - - - 目標應該是質化的：關鍵結果需要是量化/可衡量的
        
        關鍵結果應該衡量「商業結果」，而不是衡量產出或任務（套用到個人層面就是有價值的成果）
        
        產品、設計、技術團隊的目標應該鎖定部門目標，而不該被個人目標或職能目標給混淆視聽
        
        為部門找到一個合適的節奏（一般而言，部門目標是每年為基礎，團隊目標是以季為基礎）
        
        部門和團隊目標和關鍵結果不能太多，1-3個目標最好，每個目標有1-3個關鍵結果
        
        每個產品團隊必須持續比較進度和目標（通常每週比較）
        
        目標不用涵蓋團隊做的小事，但必須涵蓋團隊需要完成事情
        
        想辦法讓團隊對目標達成負責
        
        整個部門要認同關鍵結果的衡量方式
        
        建立一套方法來顯示何時關鍵結果是「高誠信的承諾」，即只有兩種結果-達成跟沒達成
        
        產品團隊努力的目標與目前的進度都應該要透明化
        
        管理階層要為部門的OKR負責；產品長跟技術長要為產品團隊的目標負責
  - - - 建議
        
        運用原型
        
        體會痛苦
        
        分享願景
        
        大方分享學習心得分享
        
        大方分享功勞
        
        學習如何做出出色的產品示範（說服工具）
        
        做足功課（成為用戶和顧客的專家、熟悉競爭對手在做什麼）
        
        真心感到興奮
        
        學會展現熱情
        
        多花點時間和團隊相處
  - - - 產品部門必須發掘與培養一群參考客戶，同時探索及開發實際的產品。根據Marty Megan的經驗，企業級用戶最好至少有6家；若是API產品或是消費者產品，數量與對象都不太相同，但核心概念是找到參考客戶，持續合作來找到適合的產品發展方向。
  - - - 實行性原型技術
        由工程師打造，看實作上是否會太複雜
      - 用戶原型技術
        用戶原型是驗證問題的工具，並無法證明如產品是否暢銷等問題
      - 即時資料原型技術（live data prototype ）
        https://uxplanet.org/prototype-with-live-data-get-better-results-292f9fa91b38?gi=607e5a148929
      - 混合原型技術