《解構產品經理》讀書筆記


本文是劉涵宇先生所著的《解構產品經理》的讀書筆記前端

I 解構產品經理

1 解構基本概念

1.1 什麼是產品

產品是指能夠知足某種用戶需求,由人類加工生產,可供給市場用於交換的任何東西。面試

1.2 什麼是好產品

能夠恰到好處地知足用戶需求,擁有完善的技術實現方式,同時可健康持續地創造商業價值的產品,就是「好產品」。瀏覽器

  1. 需求:恰到好處地知足用戶需求安全

    • 知足需求(有用):能解決用戶問題,知足用戶需求,提供給用戶價值。
      • 案例1:交流工具的演變,其核心價值都是爲了知足人們「交流」的需求。
      • 案例2:不一樣時期流行的移動數據存儲及同步產品,都在當時知足了用戶的需求。
      • 案例3:12306 的體驗一度很糟糕,但由於其有用,仍是有不少人使用它。
    • 用戶:討論一個產品的好壞,必須是針對它的目標用戶來進行。
      • 案例1:專業相機的手動檔,讓操做變得複雜,但對於攝影師是個好產品。
      • 案例2:廣場舞能夠知足「大爺大媽」的需求,但讓附近居民遭殃。
      • 案例3:倒車影像對於一部分用戶有用,但對於另外一部分用戶基本沒用。
    • 恰到好處:並非給用戶的東西越多越好,在合適的時候爲用戶提供合適的功能,實現需求,但不添亂最好。
      • 案例1:某房地產客戶端在用戶選中城市爲「深圳」後,其展現的樓盤信息無一在深圳,爲推廣推送額外的信息無可厚非,但原則是不能影響用戶核心需求。
      • 案例2:某電商網站基於商品的類似性,爲用戶推薦短時間內不會重複購買的已購買商品,顯得有些多餘。
      • 案例3:某資訊類應用在用戶閱讀過程當中,不按期彈出反饋提示對話框,粗暴地打斷用戶的沉浸式體驗,卻僅僅是爲了提示用戶能夠搖動手機反饋問題。
  2. 技術:擁有完善的技術實現方式微信

    • 實現:若是一個方案很優秀,但現有技術沒法實現,或者沒法保證其可靠性和質量,那麼這個方案是辦法成爲好的產品的。
      • 案例1:龍珠裏的「膠囊」,雖然很神奇,但以目前的技術沒法實現。
      • 案例2:Windows在20世紀80年代末的UI,如今看來顯得簡陋,這是由於當時的計算機硬件沒法處理更精細的圖形,相關技術跟上以後,圖形界面才真正發揮出應用的價值。
    • 完善:在一個充分競爭的市場環境下,只「實現」出來是遠遠不夠的,還必需要作到「完善地實現」。
      • 案例1:搜狐對技術的不夠重視,錯過了搜索這班車。
      • 案例2:Siri的不完善,或許是其仍未得到普遍應用的緣由之一。
      • 案例3:Note7手機的爆炸:技術的不夠完善,讓創新變成了嚴重的事故。
  3. 商業:可健康持續地創造商業價值網絡

    • 商業價值,並不徹底等同於賺錢:有的產品自己不盈利,但可輔助其餘產品盈利,這也創造了價值。
      • 案例1:微信的基礎部分雖然不盈利,但它在遊戲分發等方面,依然間接地創造了巨大的價值。
      • 案例2:當年的打車大戰,騰訊和阿里真正爭奪的是「近場支付」這個重要場景 。
      • 案例3:作公益不能直接創造商業價值,卻能副作用於商業。
    • 持續:靠一些手段也能夠得到價值,但不可持續。
      • 案例1:誘導短信。
      • 案例2:遊戲盈利模式從單純售賣軟件,到售賣點卡、道具等模式,變得更加可持續。
    • 健康: 「健康」與「持續」相輔相成,前者每每可使後者走得更遠。
      • 案例1:養老保險。

產品經理在策劃產品過程當中所須要關注的核心:當想到一個「點子」的時候,能夠嘗試從需求、技術、商業三個方面來分析它是否「靠譜」。事實上,優秀的產品經理老是可以在這三者之間找到最佳的平衡點。函數

1.3 什麼是用戶體驗

用戶體驗(User Experience, UX)是一種在用戶使用產品過程當中創建起來的純主觀感覺。工具

  1. 用戶:對於不一樣的目標用戶來講,即便他們的需求看起來一致或者差很少,但在具體使用產品的過程當中,「用戶體驗好」的定義也多是不一樣的。學習

    • 案例1:美圖秀秀和Photoshop,均可以處理圖像,它們分別更適合「愛漂亮的妹子」和專業設計師。
    • 案例2:針對黑人用戶優化了拍照功能的某手機品牌,風靡非洲。
    • 案例3:樂天商城的域名對於中國用戶來講難以記憶,遠不如淘寶、京東乃至亞馬遜的域名。
  2. 過程當中:在設計產品的時候,須要考慮具體使用過程當中的環境和場景。測試

    • 案例1:閱讀類產品的夜間模式
    • 案例2:Wi-Fi與數據網絡的自動切換
    • 案例3:iPhone的單手操做
  3. 主觀感覺:用戶體驗只是主觀感覺,可是做爲產品經理,必須去挖掘用戶主觀感覺背後的真實的需求,不要被主觀的、表象的東西所迷惑。任什麼時候候,產品經理都要從實際出發,全面、客觀地去思考。

    • 案例1:「若是我問客戶想要什麼,他們只會說更快的馬。」——亨利·福特

1.4 定義互聯網產品經理

  1. 互聯網產品經理的通常職責

    • 產品規劃:產品經理須要結合公司的發展方向、團隊狀況、技術難度、市場環境等因素,明確哪些需求是必定要作的,哪些不能作,哪些要優先實現,哪些能夠慢慢來。
    • 產品設計:明確要作什麼以後,產品經理須要具體設計相應的功能邏輯,主要有三件事:業務邏輯是什麼、分支邏輯怎麼辦、邏輯的表達。
    • 推進研發:承擔部分項目管理的職責,對各環節保持關注,確保需求的最終落地。
  2. 產品經理的能力模型

    • 底層能力
      • 邏輯思考能力:產品經理的工做須要極強的邏輯性,不能「想固然」。
      • 自我認知迭代:有能力意識到本身過去認知的不足,有勇氣認可本身當下認知的缺陷,同時有動力去經過不斷的學習和實踐來構建新的更加完善的認知體系。
      • 理想:保持理想。
    • 應用層能力:見下表
序號 能力 入門級產品經理 有經驗的產品經理
1 執行力 把上級交代的具體任務按時、保質、保量完成。 根據一個或許是很是模糊的方向來指定全套方案,並預知風險及作好防控預案。同時須要經過流程、方法論總結等方式提高整個團隊的執行力,避免短板。
2 產品設計 完成相對單一的功能、模塊的產品設計。根據不一樣的團隊和產品形態,可能包括產品邏輯、操做流程、UI等設計。 更加深挖用戶的需求和場景、深挖人性特徵,更多地思考各模塊之間的關係、總體的產品定位、用戶體驗與商業之間的權衡等
3 產品規劃 對用戶需求有一點深刻思考,排列一些簡單的優先級順序 以產品規劃的方式推進產品「成功」。須要明確地意識到,「成功」的因素是多元的。須要帶領團隊在對的時間作正確的事情,甚至須要忍受外界的批評和指責,但堅持把資源投入到當下真正最重要的事情上。
4 用戶研究 使用經常使用的用戶研究方法,如問卷、訪談等進行簡單的調研工做。關注並收集整理用戶反饋 深入意識到,不一樣用戶的需求是不一樣的。在進行任何分析、思考、策劃時,都能從用戶行爲出發,客觀、理性地推導用戶場景,發現其需求,並深刻挖掘這些現象、場景、需求背後的緣由和邏輯,而後再以此爲根據設計產品
5 市場研究 對市場容量、競品狀況等信息進行收集,以及作簡單的橫向對比 深刻研究並思考主要競品的特徵、優點和劣勢,以及其方向和打法。結合一切可獲取的信息,對市場發展趨勢作預判,並結合自身狀況,發現機會點,幫助產品建構優點
6 學習能力 在工做須要時,能相對主動、快速地去學習新知識、新技能 能把腦中諸多知識造成體系,融會貫通。將知識造成觀點和方法論,輔助工做
7 溝通能力 能夠流暢、準確地與用戶,以及平常工做中有合做的同事溝通。能把事情講清楚,讓對方理解,便於執行 根據不一樣角色、不一樣對象的特徵和性質,採用不一樣的溝通方法,達到最優的溝通效果
8 行業理解 瞭解行業的基本歷史、趨勢、分工和模式(包括常見的產品模式和盈利模式) 深刻理解行業,包括但不限於:行業事件、產品模式、盈利模式背後的邏輯,發展趨勢及驅動力,不斷嘗試行業內的新產品和新玩法,並思考其內在邏輯及預判其趨勢、發展方向、優缺點
9 運營及數據分析 瞭解經常使用運營手段,瞭解所負責的產品主要數據、核心指標;能作簡單的數據對比、數據計算,並給出分析結論 總結提煉適合所負責的產品運營手段,深刻分析數據,構建分析模型,並找到提高關鍵指標以及優化產品的方法
10 項目管理 跟蹤項目進度 對工做量、複雜度有必定預估能力,可與開發、測試同事一塊兒拆解工做量,作精細化管理。跟蹤項目進度,及時發現並處理風險,預見潛在問題。協調內外部資源,找到共同目標和利益點,推進執行
11 其餘相關知識和技能

1.5 互聯網的職能分工

  1. 互聯網產品的邏輯結構

    • 《用戶體驗要素》五層級

    用戶體驗要素

    • 互聯網產品四層級(本書做者主張)
      • 決策層:一切產品的基礎,解決「作什麼」、「爲何作」、「怎麼作」三個核心問題。產品具體的方向、目標用戶羣、核心功能等都是在這一層產生並迭代的。
      • 邏輯層:產品功能具體的邏輯及實現,包括業務邏輯、商業邏輯、程序代碼邏輯等。
      • 信息層:該層負責全部交互層面的問題,包括 UI 上的任務流程、信息的展示、提示等。
      • 表現層:即用戶具體看到的產品是什麼樣子的,包括顏色、大小、形狀、材質、明暗等。
  2. 互聯網產品的技術結構

    • 在網頁上登陸(B/S結構)
    • 在手機客戶端上登陸(C/S結構)
  3. 研發流水線簡述

研發流水線

2 解構基本觀點

2.1 用戶價值高於用戶體驗

在絕大多數時候,用戶價值的重要性高於用戶體驗,前者是後者的基礎。

  1. 兩個需求層次理論

    • 馬斯洛需求層次理論:較低層次的需求必須在較高層次的需求以前獲得充分的知足。
    • ERG理論:人在同一時間可能不止一種須要起做用,如高層次的需求被抑制,那麼人會對低層次的需求更加渴求。
  2. 用戶價值與用戶體驗關係

    用戶價值與用戶體驗關係

    • 有用:產品能知足用戶的某種須要,即能提供用戶價值。
    • 可用:產品的目標用戶,以起現有條件可用順利使用該產品,這一層混合了用戶價值和用戶體驗。
    • 易用:對目標用戶來講,產品易操做易上手,不須要付出過多的成原本掌握和學習,這是用戶體驗的範疇。
    • 用戶會同時對上述三者產生需求,但在絕大多數狀況下,可用和易用必須創建在有用的基礎上。
    • 在一個非充分競爭的領域中,傾向於更關注用戶價值。
    • 在一個充分競爭的領域中,傾向於在確保用戶價值的前提下,更多地關注於用戶體驗。
  3. 關於用戶價值和用戶體驗關係的案例

    • 案例1:臉萌提供了較高的用戶體驗,但因爲其缺少更核心的用戶價值做爲根基,走向了沒落。
    • 案例2:街旁網雖紅極一時,但在用戶體驗的新鮮感被耗盡以前,其未能肯定真正的用戶價值,所以迅速地被人遺忘。
    • 案例3:在網上辦理政府事務,處於一個非充分競爭的環境中,用戶價值被放大,而讓人能忍受其較差的用戶體驗。
    • 案例4:海底撈能一炮打響,偏偏是在當時服務廣泛不怎麼樣的餐飲行業,提高了用戶體驗的緣故。

2.2 用戶體驗是一條線,不是一個點

在通常的互聯網產品中,至少有四個主要因素會影響用戶體驗,分別是產品邏輯、UI、技術和運營。

  1. 產品邏輯:產品自身的邏輯會直接影響用戶體驗,而且有的時候產品層面和體驗層面會有一些衝突,在一些狀況下,要選擇性地調和雙方的衝突。 2.UI:絕大多數互聯網產品都要經過 UI 與用戶實現交互。
  2. 技術:技術的好壞,可能關聯到一個互聯網產品的運行速度、穩定性、安全性等重要因素。
  3. 運營:拉新、客服、推廣營銷、渠道銷售、平常數據分析等均可以算做運營體系。

2.3 產品經理沒法定義「用戶價值」

真正的用戶需求應該是用戶「決定」的,大多數時候產品經理只能「發現」這些需求,而後設計相應的功能,經過知足用戶需求的方式爲用戶創造價值。

  • 案例1:團購網站並無創造出新的用戶需求,而是「發現」了消費者和商家已存在的需求。
  • 案例2:共享山地車和共享充電寶,並無真正的爲用戶提供價值,既不是剛需也難以盈利。

2.4 用戶體驗部沒法統籌「用戶體驗」

現行的用戶體驗部沒法統籌完整的「用戶體驗」,而產品經理做爲除老闆之外惟一一個有機會統籌全局的角色,必須關注到包括用戶體驗在內的全部必要環節。

2.5 人人都設計師

  1. 狹義的設計:全部基於表現層的,都是狹義的設計。
  2. 藝術與設計:「設計」意味着其做品要有明確的目標,而「藝術」則不必定具備明確的目標。
  3. 廣義的設計:全部事情聚類起來只有兩種,去「想」的叫設計,去「作」的叫工程。

3 解構基礎工具

3.1 需求分析工具:用戶場景

  1. 用戶場景的定義:一種對過程邏輯的闡述方法,幫助產品經理理清用戶使用產品的核心邏輯,涉及如下幾個關鍵因素,並與用戶體驗定義的內容相對應。

    用戶場景與用戶體驗定義的關係

    • 用戶是
    • 在上面樣的條件下
    • 有了怎樣的需求
    • 會用什麼方式實現
  2. 用戶場景案例:以滴滴打車爲例

    • 場景:出租車司機在沒有載客的時候,須要尋找乘客以便於載客賺錢,因此他們一邊在路上行駛,一邊留意路邊是否有乘客向其招手,若是有,就停車載客。
    • 表述:出租車司機(誰)涉及在沒有載客的時候(條件下),須要尋找乘客以便於載客賺錢(需求),因而他們打開手機應用,應用會自動向其推送附近乘客發出的需求,他們能夠選擇合適的需求搶單,而後去接該乘客(方式),以便於達到載客賺錢的目的。
  3. 用戶場景的功能

    • 將用戶、條件、需求、方案四者分開,以便於產品經理逐一審視其合理性
    • 將上述四者組合在一塊兒,以便於產品經理判斷需求的輕重和方案的好壞
    • 方案肯定後,也便於其餘環節(如設計、開發)高效、準確地理解相關產品功能的目標、邏輯和價值,以支持相應的工做。
  4. 基於用戶場景的思惟方式

    • 用戶場景除做爲一種有用的工具使用以外,更重要的是,它是一種相比於「業務思惟」和「功能思惟」來講,更加適合產品經理的思惟方式。
    • 案例1:銀行轉帳功能只需用戶填寫幾項重要信息便可完成匯款,而不是先列出全部可用的匯款方式,增長用戶的認知負擔和操做步驟。
    • 案例2:在用戶進行相關操做時,才提示須要哪些權限並告知爲何,而不是首次進入便要求用戶必須受權。

3.2 市場分析工具:SWOT分析法

  1. 價值

    • 全面瞭解市場狀況和市場潛力
    • 明確全部競品各自的優點和劣勢,結合自身狀況,找到最合適的「核心競爭力」
    • 爲以後的產品策劃提供大方向的依據
  2. 構成

    • 組織內部因素:SW(優點、劣勢),包括企業品牌、獨有資源、起步時間、內部生態
    • 組織外部因素:OT(機會、威脅),包括政策走向、需求輕重、行業壁壘、競品狀況、盈利模式

3.3 功能梳理工具:功能列表與思惟導圖

先發散,後聚焦。結合需求、場景和團隊目標,把產品的功能列表梳理清楚,而後排優先級,再去細化具體的功能邏輯。

  1. 功能列表:將全部功能列出來,就成了功能列表。功能列表至少應包含如下 5 部分:編號,模塊,功能名稱,功能簡述,優先級。
  2. 思惟導圖:使用思惟導圖,可讓功能、模塊之間的邏輯和從屬關係表達得更清晰。

3.4 邏輯梳理工具:流程圖

繪製流程圖可用幫助產品經理創建起對本身產品詳細功能層面的宏觀把控。

3.5 優先級及版本規劃工具:四象限與 MVP 混搭

  1. 敏捷開發:使用小步快跑、快速迭代的方式推動產品研發。最初的版本只有簡單的功能閉環,以後的每個版本只完成一小部分優化和新功能,不斷重複這個過程,最終迭代出相對全面、完善的產品。
  2. 四象限:將全部功能按照「重要」和「緊急」兩個維度進行分類,從而排列優先級。
  3. MVP:指一個只有重要的核心功能,沒有其它多餘的功能,並可提供給用戶的產品版本。
  4. 先使用四象限方法,排列優先級;再借鑑 MVP 思惟,一個版本若上線某功能,則必需要保證與其相關聯的主要功能也同步處於可用狀態,以保證產品的「功能閉環」。

3.6 原型設計工具:線框圖

  • 目的:從用戶視角去審視功能、流程的完整性和合理性。
  • 原則:便於修改、便於標註、善用標準化組件。

3.7 需求表述工具:需求文檔

  • 用途:記錄和沉澱需求,跨團隊、跨部門協做,輔助傳承和交接。
  • 圖文形式的需求文檔:
    • 文檔標題和變動記錄
    • 背景介紹(可選)
    • 用戶角色描述(可選)
    • 流程圖、結構圖(可選,建議提供)
    • 功能名稱、優先級和詳細描述
  • 帶 UI 的流程圖形式的需求文檔

4 解構宏觀產品設計原則

任何原則都不能機械地套用,而是要在理解其本質和適用範圍的基礎上,針對具體的用戶、場景進行具體的運用。

4.1 基於用戶心理模型來思考

心理模型是指人們遵循生活中某些習慣或經驗而創建的對世界的認知。從用戶的「心理模型」出發,而不是機械地執行業務邏輯,從而幫助用戶更高效地完成任務,同時得到更好的用戶體驗。

4.2 用合適的方式交流

使用目標用戶聽得懂的「語言」、看得懂的「方式」與用戶進行交流和人機交互。另外一方面,「有效」的交互不只僅是將信息傳遞出去,更重要的是喚起用戶的有效認知。

4.3 形式追隨功能

對於互聯網產品來講,其全部外在的表現形式,都應當爲場景和功能服務。且針對不一樣的用戶羣,因爲他們的場景和需求不盡相同,每每須要提供相適應的不一樣表現形式。

4.4 Less is More

少便是多在互聯網產品的角度上,有四層解釋:

  1. 簡化裝飾:反對過分的裝飾,由於過分的裝飾不但沒法起到正向的效果,相反還可能阻礙用戶的使用。
  2. 簡化功能:將核心功能作好,同時簡化、去除相對邊緣的功能元素。
  3. 簡化認知:儘可能減輕用戶的認知成本,「Don't Make Me Think!」
  4. 「減法」並非惟一的選擇:對於一些特定的用戶和場景,作「減法」並不適合。

5 解構微觀可用設計原則

產品首先是要給人用的,互聯網產品的盈利每每創建在用戶先「使用」的基礎上,因此不少時候可用性顯得尤其重要。

5.1 一致性

  • 定義:在一個(或一類)產品內部,在相同或類似的場景、功能上,應儘可能使用表現、操做、感覺等相一致的設計。
  • 目的:下降用戶的學習成本,下降認知門檻,下降誤操做的機率。
  • 通用標準:當在某一類產品、某行業中造成更大範圍的一致,並獲得廣泛的認可時,一致性便成了通用的標準,這個標準被越多的人所遵照,整個社會的協做效率就越高。
  • 設計規範:在系統或產品內部,應有統一的設計規範,這會極大地下降用戶的學習和使用門檻。

5.2 及時且有效的反饋和解釋

多數時候,用戶是不耐煩的,若是用戶發出指令後,產品在很長的時間內都沒有給用戶反饋,用戶每每會離開。所以,反饋和解釋必須及時且有效(注意,這二者缺一不可)。

5.3 信噪比

在可用性設計和UI設計中,應當儘可能放大信號,減小噪聲。尤爲「大而全」,不如突出核心功能,由於少數核心功能應該能夠知足多數用戶的需求

5.4 漸次呈現

當用戶須要在產品完成某種任務時,每每須要將任務分步驟,依次引導用戶走完流程。確保用戶在每個步驟中只須要思考簡單的邏輯,進行簡單的操做,以便於更加高效、順利地完成全流程

5.5 防錯與容錯

  • 優秀的產品應給予用戶能糾正錯誤的提示和引導,甚至能猜到用戶的一些當心思,幫助其避免錯誤,而不是生硬地告訴用戶「出錯了」。
  • 一些容易存在風險的操做應有相應的機制進行提示。
  • 部分操做提升容錯性,能夠下降用戶的使用成本,提高用戶體驗。

6 橫向擴展:用戶研究與運營分析初步

6.1 以產品經理的視角看待用戶研究

  • 用戶研究定義:
    • 廣義:只要可以幫助咱們更多、更深刻地瞭解用戶的工做,均可以看做用戶研究範疇。
    • 狹義:指在專門的「用戶研究工程師」主導下,使用特定的科學方法所進行的一系列研究工做。
  • 從產品經理的視角:
    • 用戶研究的結論每每不是終點,如何把它們運用到具體產品中,變成「方案」纔是關鍵。
    • 用戶研究的結論不該左右產品決策,只能供產品經理參考。

6.2 深度訪談

  • 定義:是用戶訪談的一種,一般是由專業的訪談者對受訪者進行一對一的自由式訪談,以便於深刻挖掘用戶的需求、產品使用場景、主觀觀點等內容。
  • 優點:
    • 能夠深刻、細緻地討論一個話題,對用戶的態度、動機、需求、行爲等進行深刻挖掘。
    • 得到的信息量大,內容豐富。
    • 靈活性強。
  • 劣勢:
    • 成本高(時間、金錢)。
    • 對訪談技巧和邏輯性有必定要求。
    • 難以量化分析。
  • 前期準備:
    1. 肯定訪談目的
    2. 選擇訪談對象
    3. 列提綱:儘可能選擇相對開放式的問題。
    4. 選擇訪談場所
  • 問題設計:
    1. 避免專業術語
    2. 避免引導性問題
    3. 避免過於模糊、過大的問題
    4. 追問:表述不明確,或有挖掘空間,應進一步追問。
    5. 避免打斷
    6. 給足時間,不要提醒
    7. 用問題回答受訪者問題

6.3 問卷調查

  • 定義:將所但願瞭解的問題列成清單,供受訪者一一做答,從而瞭解受訪者對這些問題的見解和意見。
  • 優點:
    • 在短期內,快速手機大量樣本信息。
    • 豐富的傳播渠道。
    • 可匿名,對於敏感性問題的收集優於其它形式。
    • 易量化,易統計分析。
  • 劣勢:
    • 沒法深刻追問,沒法瞭解受訪者在答案背後的邏輯。
    • 不易精確選擇樣本。
  • 問卷設計:
    1. 問卷開頭:目的、主要內容和保密措施,激勵措施(若有,喚起受訪者興趣)。
    2. 問卷正文:
      • 以封閉式問題爲主
      • 注意問題順序
      • 注意措辭
      • 留有出口:設置「不知道/其它」選項,設置測謊題。
    3. 問卷結尾:對受訪者表示感謝,及其它相關事項。
  • 問卷投放和回收:
    1. 選擇投放平臺
    2. 選擇投放渠道
    3. 問卷回收

6.4 可用性測試

  • 定義:讓一羣具備表明性的用戶對產品的典型任務進行操做,同時用戶研究工程師和產品經理在一旁進行觀察,聆聽,以便於發現問題。
  • 優點:
    • 針對調查人員最關心的功能任務讓測試者實踐,目的性和可控性強。
    • 能夠集中發現產品問題。
    • 配合訪談和相關研究,能夠探求問題背後的緣由。
  • 劣勢:
    • 成本高(時間、金錢)。
    • 通常須要在方案肯定甚至已經開發完成的時候進行,如遇重大問題,難以及時推翻原有方案並作大幅度修改。
  • 制定任務:梳理被測試的產品/版本中的關鍵任務。
  • 進行測試:在測試過程當中,儘可能不要交流,且不要打斷被測試者的操做,以觀察到的事實爲主。

6.5 運營分析初步:經常使用指標與漏斗模型

  1. 常見數據指標:

    • PV:即頁面瀏覽量,通常只按次數,不區分用戶、地域和頻次等。
    • UV:即獨立訪問量,須要定義「什麼是獨立訪問」。
    • DAU:即日活躍用戶數,通常用戶只要打開一次就算一次「活躍」。
    • MAU:即月活躍用戶數。
    • 轉化率:指在一個統計週期內,完成轉化行爲次數佔推廣信息總點擊次數的比率。
    • 留存率、流失率:在一個任務中,某步驟的UV / 上一步的UV,就是主觀步驟的留存率,相反則是流失率。
  2. 其它數據指標:

    • 渠道分佈
    • 版本間數據對比
    • 業務核心指標
  3. 漏斗模型

    • 構建漏斗模型:每一個產品都會有用戶的核心任務和流程,將流程每個步驟及其對應的數據拼接起來,就會造成漏斗。
    • 分析漏斗模型,進行優化。
    • 案例:應用商店的漏斗模型,使用>下載>安裝>激活。

6.5 數據分析初步:Excel 經常使用函數簡述(略)

7 縱向擴展:互聯網產品盈利模式淺析

7.1 流量變現

  1. 普通廣告:廣告是流量變現的基本方式。

    • 案例1:門戶網站上的廣告
    • 案例2:feed流廣告
    • 案例3:驗證碼廣告
    • 案例4:網盟廣告
  2. 匹配廣告:根據用戶須要的內容來匹配廣告,投放更精準。

    • 案例1:Google 搜索關鍵詞廣告
    • 案例2:Facebook 精確匹配廣告
  3. 導航站:將流量導給其它互聯網產品。

    • 案例1:hao123
    • 案例2:瀏覽器
  4. 移動應用分發:在移動互聯網時代,移動應用分發纔是主流的流量分發產品形態。

    • 案例1:第三方 Android 應用商店
    • 案例2:應用商店
    • 案例3:分發平臺
    • 案例4:換量
  5. 預裝分發:與手機廠商合做,將應用預裝在未出廠的手機中。

    • 案例1:手機出廠前預裝。
    • 案例2:手機管理工具。

7.2 增值服務

  1. 基礎功能免費,高級功能收費:使用免費功能來彙集用戶黏性,而後將一部分用戶轉化爲付費用戶,產生商業價值。

    • 案例1:QQ 會員
    • 案例2:標準版和專業版
  2. 遊戲道具:遊戲道具已成爲當今大多數手機的主要盈利方式,其本質就是一種增值服務。

    • 案例1:王者榮耀中的英雄
    • 案例2:直播平臺中的虛擬禮品
  3. 高品質內容:向用戶提供更高品質的內容。

    • 案例1:QQ音樂的無損品質
    • 案例2:騰訊視頻的清晰度選
    • 案例3:視頻片頭廣告
    • 案例4:艾瑞諮詢的收費研究報告

7.3 佣金與分紅

  1. B2C平臺

    • 案例1:天貓的軟件服務費
  2. 第三方支付

    • 案例1:支付寶的收款佣金
    • 案例2:iOS 的支付手續費
  3. 開放平臺

    • 案例1:人人網開放平臺
    • 案例2:遊戲聯運
  4. O2O

    • 案例1:易到用車

7.4 收費服務及售賣變現

  1. 技術服務

    • 案例1:阿里雲提供的雲服務
  2. 付費軟件:全部功能都須要付費使用,沒有「基礎功能免費,高級功能收費」的增值服務模式。

    • 案例1:全面戰爭等單機遊戲
  3. 付費內容:直接售賣內容。

    • 案例1:騰訊視頻的付費內容
    • 案例2:獲得 APP
  4. 網上渠道:僅僅將互聯網做爲售賣渠道的產品。

    • 案例1:小米商城
    • 案例2:賣花的公衆號
    • 案例3:餘額寶(基金銷售)

7.5 其它類

  1. 付費開發:靠售賣開發能力來爲客戶開發軟件來盈利。
  2. 金融增值:靠「帳期」來賺取金融增值部分的利潤。
  3. 第三方付費:技術公司負責開發,客戶與第三方進行必定的利益置換,由第三方付費。

II 推廣產品思惟

8 以產品思惟應聘產品經理職位

8.1 找到用戶:誰會負責簡歷的篩選(略)

8.2 明確需求:讀懂職位描述(略)

8.3 設計UI:寫簡歷(略)

8.4 釐清邏輯:與面試官相談甚歡的套路(略)

8.5 快速迭代:「等通知」期間能夠作什麼(略)

8.6 畢業生與轉崗:沒經驗怎麼辦(略)

9 以產品思惟溝通

9.1 與設計師溝通:咱們一塊兒改變世界(略)

9.2 與工程師溝通:我很靠譜,跟我乾沒錯(略)

9.3 與上級溝通:明確目標與給出方案(略)

10 「互聯網+」產品思惟初探

「互聯網+」 就是 「互聯網+各個傳統行業」,但這並非簡單的二者相加,而是利用信息通訊技術以及互聯網平臺讓互聯網與傳統行業進行深度融合,創造新的發展生態。

10.1 「互聯網+」的三個階段

  1. 階段一:渠道、媒體與工具(從前)

    • 最初,對於「傳統行業」來講,互聯網是一種通訊和宣傳渠道
    • 在這個時期,互聯網與傳統行業的鏈接每每是很簡陋的。
    • 案例1:易趣網的賣家身份驗證須要經過線下的郵件完成。
    • 案例2:噹噹網的支付渠道,當年還包含「郵局匯款」。
  2. 階段二:業務融合,改造與重構(如今)

    • 如今的「互聯網+」更多的是互聯網與傳統行業的「融合」
    • 在將來幾年,互聯網會愈來愈多地與傳統行業深度融合,改造甚至重構一些行業及其內部的體驗
    • 案例1:滴滴出行事實上是對城市客運這個行業的資源產生了「動態調節」的做用。
    • 案例2:「互聯網+醫療」正在慢慢改造甚至重構這個古老的行業
    • 「互聯網+」仍是「+互聯網」,是一個僞命題,誰都不可能顛覆對方,想作事,必須深度合做
  3. 階段三:思惟方式融合(將來)

    所謂「互聯網思惟」,在將來將不只僅是指「適應互聯網行業的思惟方式」,也不只僅是指所謂的快速迭代、試錯、用戶體驗等,而是會繼續昇華爲「以互聯網等行業爲表明的,社會上最早進的人才、機構所相對的思惟和行爲方式。」

10.2 如何策劃「互聯網+」產品

互聯網產品就像一座冰山,用戶在前端可見的只是冰山浮在水面的部分。而「互聯網+」產品則像一個更大的冰山,其隱藏在水下的、普通用戶沒法直接看到的邏輯更加龐大和複雜。

  1. 「互聯網+」研發鏈條中的角色:

    • 傳統行業人士:不只僅是B端用戶,也許還會扮演多種徹底不一樣的角色, 不能盲目地接收其建議,而是要用互聯網的思惟與其碰撞,進行融合和重構,纔有可能更加蓬勃的創新出現
    • 合做方:在融合的過程當中,每每須要引入一些合做方填補縫隙,應儘可能「用好」合做方,將專業的事情交給專業的人去作,但要注意對方向和質量的把控
    • 社會機構:有可能涉及一些社會機構的輔助和監督,在此背景下,對大環境的趨勢必定要有足夠的把握和理解,使用合法、合理的方式推進產品發展。
  2. 「互聯網+」產品的策劃方法

    互聯網產品和「互聯網+」產品研發流程對比

    • 行業解構:與通常的行業調研、用戶調研不同,「互聯網+」的行業解構要求更深刻,既須要知道需求,也須要知道緣由,還須要研究「需求」之外的目標(如行業慣例、政策及法律限制)。
    • 結合行業現狀思考產品方案:採起恰當的結合現狀的產品方案,解決用戶核心需求。
    • 構建並迭代商務邏輯:必須同步深刻思考商務邏輯,而思考的過程每每須要從雙方各自的資源、目標出發,思考對雙方都有利的方案。
相關文章
相關標籤/搜索