一個功能的DNA

• 需求轉(zhuǎn)化-->確定基本屬性-->分析商業(yè)價值-->初評實(shí)現(xiàn)難度-->計(jì)算性價比
  • 用戶需求和產(chǎn)品需求是多對多的關(guān)系
  • 需求的基本屬性：編號，提交人，提交時間，模塊，名稱，描述，提出者，提出時間，Bug編號*
  • 產(chǎn)品5±2個模塊比較合理，再多也可增加基本屬性：“二級模塊”
  • 需求種類：新增功能、功能改進(jìn)、體驗(yàn)提升、Bug修復(fù)、內(nèi)部需求
  • 產(chǎn)品需求列表：模塊，子模塊，F(xiàn)eature，任務(wù)描述，商業(yè)價值描述，商業(yè)屬性，商業(yè)優(yōu)先級，開發(fā)量，性價比，備注

• 價值評估

  • 參照“產(chǎn)品原則”目標(biāo)部分的定義，明確當(dāng)前產(chǎn)品最看重的指標(biāo)是什么。如果有多個指標(biāo)，加權(quán)合并。

  • 考察每個功能點(diǎn)實(shí)現(xiàn)后，對上述指標(biāo)的幫助大不大。

    • 廣度：潛在用戶數(shù) X 單用戶價值
      • “天花板”
      • 具體操作時，先從某些細(xì)分用戶切入，再逐步擴(kuò)大到所有潛在用戶
    • 頻度：需求頻次 X 單次復(fù)雜度
      • 需求頻次高

      • 單次需求的復(fù)雜度高，單價高，也有很大的價值可以挖掘（婚紗。。）

        
        
        image.png
    • 強(qiáng)度：不可替代、緊急、持久
      • 真實(shí)剛需：當(dāng)你沒有做這個產(chǎn)品功能時，用戶是不是在設(shè)法解決，甚至已經(jīng)在用某種低效的方式來解決這個問題？
      • 可替代性：包子-->饅頭 vs 豆?jié){
      • 緊急程度
      • 持續(xù)時間

  • 不同階段的產(chǎn)品各有側(cè)重

    • 早期的驗(yàn)證階段：強(qiáng)度。測驗(yàn)留存率高低。
    • 拉新階段：廣度。依賴的是需求和功能覆蓋的廣度是否足夠大。
    • 瓶頸期：頻度。先主攻“單用戶獲取成本”低的場景。

  • 實(shí)用工具的突破

    • 墨跡天氣
    • 工具性產(chǎn)品困境：單用戶價值低，可替代性強(qiáng)
    • 增加用戶黏性：實(shí)景功能，引流。。。
    • 一個產(chǎn)品要大成，靠的就是用戶與你產(chǎn)生復(fù)雜的積極性情感

  • 智能硬件：KOL營銷

• 成本評估

  • 首先判斷成本的瓶頸在哪里，例如開發(fā)量

  • 確定性價比

    
    
    image.png

• 功能分類（KANO模型）

  • 一些基礎(chǔ)功能非做不可，工作量較大，性價比不高

  • 基礎(chǔ)功能Must Have

    • 這類功能沒有實(shí)現(xiàn)，用戶“極其不滿”。做得再好，也是“理所應(yīng)當(dāng)”
    • 無法帶來滿意，只會消除不滿

    • 不需要看性價比，留足資源先搞定

      
      
      image.png

  • 領(lǐng)域知識

    • 如果沒有功能A，你覺得如何？很滿意、一般、無所謂、不滿意、很不滿意
    • 如果有了功能A，你覺得如何？

  • 亮點(diǎn)功能Excited to have

    • 習(xí)以為常-->贊不絕口
    • 亮點(diǎn)是忠誠度、口碑傳播的基礎(chǔ)
    • “用戶沒見過”“未經(jīng)市場檢驗(yàn)”“如果被認(rèn)可，就能獲得巨大回報(bào)”

    • 對用戶人性的理解

      
      
      image.png

  • 期望功能Nice to Have

    • 對產(chǎn)品而言，這類功能多多益善
    • 先做性價比高的

    • 缺乏驚喜不大可能主動傳播

      
      
      image.png

image.png

• 無差別功能

  • 做不做用戶對產(chǎn)品的感受是沒有變化的（后臺數(shù)據(jù)）
  • 低成本驗(yàn)證是不是無差別功能

• 反向功能

  • 滿意”，針對某一種客戶可能是反向的，針對另一種客戶卻可能是正向的
  • KANO往往只針對一種用戶，通常是核心用戶
  • 用戶的多邊形和多樣性

• 價值由產(chǎn)品背后的用戶需求（問題）決定，成本由產(chǎn)品功能（解決方案）決定。性價比=價值/成本。

功能打包，確定MVP

• 盡可能多放棄
  • “用戶愿意用，最好愿意付費(fèi)”“用戶易于使用”“團(tuán)隊(duì)有能力實(shí)現(xiàn)”的最小功能集合
  • 多快好省，范圍大、時間短、品質(zhì)高、資源?。═RQ: Time, Resource, Quality, Quantity）
  • MVP的限制因素
    • 不同功能，不同對策
      • 基礎(chǔ)功能必做，要留足資源
      • 在產(chǎn)品初創(chuàng)期，先實(shí)現(xiàn)個別低成本的亮點(diǎn)
      • 對期望功能，先做性價比高的
      • 無差別功能無需做，低成本驗(yàn)證即可
      • 對反向功能，權(quán)衡各方利益后決定
    • 考慮功能依賴關(guān)系
    • 考慮功能相似性：通過業(yè)務(wù)邏輯圖的方式可視化，可以更直觀講解
    • 粒度大?。盒枨罅斜淼娜我庖恍?，工作量做好不超過“5人天”
    • 考慮非功能需求（性能需求，培訓(xùn)需求，運(yùn)維需求，可擴(kuò)展需求，內(nèi)部數(shù)據(jù)分析需求）
  • MVP的表達(dá)：產(chǎn)品架構(gòu)圖
  • 功能分分合合的本質(zhì)：不同用戶角色背后的自然人重合度高不高

BRD

• 項(xiàng)目背景：列出項(xiàng)目的必要性，我們在哪里，為什么要做這個項(xiàng)目，解決什么問題
• 商業(yè)價值：我們?nèi)ツ睦?？?。。?/li>
• 功能需求描述
• 非功能需求描述
• 資源評估
• 風(fēng)險和對策

需求的DNA

• 編號
• 提交人
• 提交時間
• 模塊
• 名稱
• 描述（無歧義，完整性，一致性，可測試）
• 提出者
• 提出時間
• Bug編號
• 分類（新增功能、功能改進(jìn)、體驗(yàn)提升、Bug修復(fù)、內(nèi)部需求）
• 層次（基礎(chǔ)、期望、興奮）
• 重要性
• 緊迫度
• 持續(xù)時間
• 商業(yè)價值
• 開發(fā)量
• 性價比
• 狀態(tài)（待討論、暫緩、拒絕、需求中、開發(fā)中、已發(fā)布）
• 負(fù)責(zé)PD
• 開發(fā)工程師
• 項(xiàng)目名稱
• 發(fā)布時間
• 備注（被拒絕的理由；被暫緩的理由和重啟條件；其他文檔）

需求的生命周期

image.png