怎麼將用戶轉換為產品需求

㈠ 如何將顧客需求轉化為產品特性

如何將顧客需求轉化為產品特性
3、顧客需求轉化為產品需求的方法——QFD（質量功能展開）
作為一種面向顧客需求的產品開發思想和方法論的質量功能展開（QFD），在將顧客需求轉化為產品特性的過程中，它提供了有力的理論指導和操作方法，並已經得到實踐的檢驗。QFD藉助質量屋，量化分析顧客需求與工程措施之間的關系，通過對顧客需求進行多次展開，轉化為產品的設計要求、零部件特性、工藝要求和生產要求，已經指導產品設計和質量保證，充分體現了以市場為導向的產品開發指導思想。
QFD是一種顧客驅動的產品開發系統化方法，採用系統化、規范化的方法調查和分析顧客需求，並以矩陣或圖表的形式將顧客需求轉化成產品開發階段的工程特徵、零部件特徵、工藝特徵和質量控制參數和方法等產品特性信息，以使產品能真正全面的滿足顧客需求。
QFD包括兩個基本過程：顧客需求的提取和顧客需求的瀑布式分解過程。顧客需求的提取時通過各種市場調查和各種渠道收集原始的顧客需求，然後進行分類和整理，並用加權表示顧客需求的相對重要度。顧客需求的提取是QFD中最關鍵的一步，他直接關繫到QFD的成功與否。顧客需求的瀑布式分解過程由產品規劃、零件規劃、工藝規劃和生產規劃四個階段組成。通過四個過程，顧客需求逐步展開為設計要求、零件特性、工藝特性和生產要求等一系列可測量的、可操作的活動或指標。在展開過程中，上一步的輸出就是下一步的輸入，構成瀑布式分解的過程。
在顧客需求逐步展開過程中，QFD採用了質量屋（HOQ）.質量屋是實現QFD思想的一種工具，是QFD基本原理的核心組成部分，質量屋提供了將顧客需求轉換為產品技術需求和零部件特性並配置到整個研發過程的結構。
現以產品規劃過程來說明質量屋的構成，在這一階段的質量屋中，顧客需求被展開為設計要求。
產品規劃矩陣用於將顧客需求轉換成技術需求，並分別從顧客角度和技術要求對市場上的同類產品進行評估，在分析舉證的各部分信息的基礎上，確定各個技術需求的目標價值以及在零件配置階段需要的技術需求 。對上圖各部分的解釋說明：
1）顧客需求及權重是矩陣最基本的輸入，他們是通過廣泛的市場調查得到的，在確定顧客需求是應避免主觀想像，注意真實性和全面性。在圖中（1）是顧客需求欄。
2）根據市場調查得到的顧客需求，確定最終產品所應具有的技術需求，他們直接與顧客有關，並將有重點的配置到設計、工藝、製造中去。在圖中（2）為技術需求欄。
3）通常用一組符號或數字來表示顧客需求和技術需求之間的相關程度。如用5表示技術需求與滿足其對應的顧客需求強相關程度；3表示中等程度相關；1表示弱相關。如果關系矩陣中相關符號很大部分是弱相關，則表示技術需求沒有足夠的滿足顧客需求，應對應進行修正。圖中（3）為顧客需求和技術需求的關系矩陣欄。
4）顧客競爭性評估，是指從顧客的角度對本公司產品和競爭者產品在滿足顧客需求方面的評估。他反映了現有產品的優勢和弱點以及產品需要改進的地方。評估數據一般通過顧客調查獲得。圖中（4）為顧客競爭性評估欄。
5）技術性競爭評估，與顧客競爭性評估不同，是從技術角度對產品的競爭力進行評估。在圖中（5）是技術競爭性評估欄。
6）技術需求之間常常是相互影響的，改善其中的某一項技術需求的措施可能有助於改善另外一個技術需求，或者將對另外一個技術需求產生負影響。有助於改善的叫正相關，影響另一技術需求的叫負相關。如圖（6）中為技術需求相互關系欄。
7）技術需求目標值，根據顧客需求及權重、顧客需求與技術需求的關系矩陣以及產品的優勢和弱點，確定技術需求的目標值。在圖中（7）為技術需求目標值欄。
基於下道工序就是上道工序的顧客的思想，QDF還包括其他矩陣，如零件配置舉證，工藝規劃矩陣和質量控制規劃矩陣等，以進一步把顧客需求展開到產品的全過程。
零配件配置矩陣從產品規劃中獲得技術需求，並作為零件配置矩陣的輸入。包括：技術需求、關鍵性零件特性、技術需求與關鍵性零件特性關系矩陣、關鍵性零件特性目標值等，其質量屋的構成與產品規劃相似。
工藝規劃矩陣和林間配置矩陣相似，他從零件規劃中獲取去零件特性作為輸入。主要包括關鍵零件特性、關鍵工藝特性、關鍵零件特性和工藝特性關系矩陣，工藝規范等。
質量控制規劃矩陣以工藝規劃矩陣輸出的關鍵工藝特性作為輸入，將其轉化為相應的質量控制要求和具體控制辦法。

㈡ 如何理解產品需求和用戶需求

用戶需求是用戶自以為的需求，也是用戶提出的解決方案。比如一匹更快的馬，很明顯這不是用戶真正的需求和最好的解決方案。產品需求是經過分析找到用戶需求背後的真實需求，並為之提供解決方案。汽車是福特為用戶提供的更好的解決方案。

從用戶需求到產品需求的過程就是需求分析的過程，找到用戶內心真正的渴望，也就是「 速度 」，福特用汽車滿足了它，現在的解決方案更多了，高鐵、飛機、火箭。

此外，產品要做的並不僅僅是將用戶需求轉化為產品需求，更要設計詳細的解決方案，帶領團隊實現產品滿足客戶需求。也就是整個過程包括前端收集需求，分析需求；中端處理轉化需求，設計產品找到解決方案；後端實現，帶領團隊設計產品為客戶提供解決方案。

需求，不是通過技術來實現，是通過技術滿足客戶的內存多個層級的需求，或重點在哪個層級的需求。也就是說，用戶的需求本身就是分層分級的，如上所述，隨著時間與環境、形勢的變化，原來的某一層次的需求，可能就躍遷到了不同的層級。

如原來喝飲料只求解渴，現在可能需要符合自己的個性甚至社會層次特徵。也可能產生升級式變化，比如說對手機的需求原來就是一個通話的工具，那麼現在可能就是生活的一種依賴了，需要通過它來拍照、溝通、學習、購物、互動等等。

㈢ 如何將用戶需求轉換為產品功能特性需求

在產品生命周期中，需求是一個動態變化的過程，產品可分為：導入期、成長期、成熟期和衰退期，產品在不同階段有著不同的需求，而且需求的種類也不同。

👉 從對象角度來看，需求有：基本需求、易用性需求、可操作性需求；
👉 從產品運營來看，需求有：產品運營需求、政策及法律需求；
👉 從系統角度來看，需求有：安全性需求、性能需求、可維護和可移植性需求；
👉 從來源看，需求有：客戶需求、公司內部需求、運營和市場需求。
公司有成熟的需求收集、評審、管理機制。在判斷需求優先順序的時候會採用KANO模型，判斷是魅力需求、期望需求、必備需求、無差異需求還是反向需求。比如前面提到的折疊屏，正反拍照、應用間交互，就屬於魅力需求。應用分屏屬於期望需求。折疊的可靠性屬於必備需求。

㈣ 用戶需求VS產品需求

      用戶需求不一定等同於產品需求，那這兩個概念有什麼區別呢？

      用戶需求：用戶自以為的需求，並且經常表達為用戶的解決方案。

      產品需求：經過我們的分析，找到的真實需求，並且表達為產品的解決方案。

      太多的時候，用戶說與做不一樣，真正的需求不一定那麼多容易發現。所以才會有需求分析，從用戶提出的需求出發，找到用戶內心真正的渴望，再轉化為產品需求的過程。

      就如混沌里經常講的，用戶說要一匹快的馬，福特卻給了一輛車。產品需求是這個產品的價值，一個代表企業滿足用戶需求的解決方案。

      雖然這個產品需求寫的這么簡單，這是書上寫的沒有競爭對手，如果有大把的競爭對手，同質化的產品，要從中突圍，是難事。此時選擇權在用戶手上，看誰能成為讓用戶最後付費的動力。

      這里我想到梁寧講的，用戶分為三類：小白、大明、笨笨。大概是小白是完全不懂的用戶，有需求、時間、錢，需要引導消費沖動。大明，就是理智性的人，會分析，有點像理工男一樣，打動他的可能是性能、性價比等。笨笨就是閑下來需要打發時間和無趣。

      可能需要把用戶畫像寫得清晰，精準找到他們，也可能需要小圈試用，這個產品是不是他們心中所要。產品的MVP很重要，這是增長飛輪的第一推動力。

    回到我自己，我可能要做的新項目，面臨的就是在競品中突圍，我也需要做MVP，做影響力。我不確定可以做到什麼效果，可試，需要時間，也不確定市場給的時間有多少，這是一個未知的變數。

㈤ 如何將用戶需求轉化為產品功能特性需求

客戶需求、市場需求、產品需求、設計需求、業務需求、內部需求、外部需求、特性、規格、功能需求 --- 需求工程的基本術語說明
需求分析和管理對產品開發成敗至關重要，這一點大家都非常清楚，正因如此，相關的管理體系都對需求進行詳細定義和描述，不同體系不同的定義，導致需求術語混亂，筆者結合10多年的需求工程經驗，詳細分析不同術語區別如下：
客戶/用戶需求：基於客戶認知，更多是客戶的直觀要求，體現了用戶個體的訴求，往往是理想狀態，例如：「需要一個功能強大的手機，同時價格要相對便宜」、「我想要的汽車要外觀時尚，性能卓越。」，用戶需求往往無法直接開發實現，同時用戶對自己的需求往往也是模糊的，實際開發中就需要藉助類似原型（demo）、參照物等方法，使客戶需求具體化。
市場需求：很多人理解的市場需求就是客戶需求，個人認為市場需求和客戶需求還是有很大差別的，客戶需求更多描述客戶的訴求，而市場需求不但要描述目標客戶的訴求，更需要描述競爭對手針對此需求的反應，例如，競爭對手是如何實現的？如果我們不實現被競爭對手替代的可能性有多大？如果實現我們是否如何做才能超越競爭對手？所以可以理解市場需求是經過產品經理分析後的客戶需求，體現了客戶和競爭的情況。
產品需求：針對產品需求，個人認為IPD的定義是合理的，IPD把產品需求定義為「產品包需求」，之所以叫「產品包需求」是因為我們給客戶交付的不是孤立的產品，而是一個解決方案，同時客戶是否購買一個產品不僅僅看產品本身，還會關注品牌、服務、渠道等因素，產品需求要廣而不深，需要把產品相關的方方面面都考慮清楚，而不是要針對一點定義的多麼精細，需要更多從客戶購買決定的全過程來思考，所以一般就會涉及：價格、渠道、包裝、性能、易用性、保證、服務、社會接受程度、品牌等；另根據需求理論一般產品需求會在25~99條之間，實際研發項目時，產品需求會直接讓領導層來判斷該產品的價值、競爭地位等，最終判斷該產品是否值得繼續做下去。
設計需求：設計需求故名詞意就是 設計 + 需求，經常遇到研發人員說設計與需求有時候很難區分開來，其實到了設計需求階段，設計和需求已經融合在一起了，同時也正是融合在一起，需求才能落實為設計，設計也才能承載需求;對比產品需求，設計需求定義時一定要在深度上下功夫，細化到能夠通過設計來實現，並且能落實到具體的物理模塊來承載。那麼設計需求怎麼來的呢？根據需求工程理論設計需求是通過產品需求分解而來，業界常用HD（層次分析法）來分解產品需求，關鍵問題是大家一定要掌握，一個產品需求需要從哪些方面來分解，從而保證分解的完整性，根據IPD需求工程定義，一個產品需求通常需要從如下：功能、環境、性能、強健性（魯棒性）、可靠性、可維護性、可用性、安全性、重量、電源、尺寸大小、可運輸性/可移動性、靈活性等方面進行分解，當然並不是每個產品需求都要一定分解為這些方面，分解後就形成了與此產品需求相對應的設計需求清單。
規格：我們經常講：產品需求規格說明書，說明需求和規格本來就是一體化的，規格就是需求的具體說明，例如：「OA要支持IE瀏覽器」 是需求，那麼如果具體定義：「需要具體支持Ie6、Ie7、Ie8」，那麼就叫規格；「聲音要達到120分貝~190分貝」，這本身就需求 + 規格。
特性：軟體行業和軍工標准中，經常提到特性這個詞語，例如國軍標中定義：「特性 --- 識別和區分各類產品或服務的屬性，這種屬性包含物理、化學、功能或其他可識別的性質。」；所以模糊來講特性就是產品需求，如果更精確來講，特性是產品需求中的與其他產品有明顯差異的個性化需求，通常我們把產品需求劃分為3類：BSA（Basic、Satisfied、Attractive），分別為基本需求、最好滿足的需求、更具有吸引力的需求；所以可以理解特性為：A的需求。
測試需求：什麼叫測試需求，很多人認為測試需求是基於對產品需求的分析，測試人員提煉出來的需要重點測試的點，故名詞意：測試需求。不管別人怎麼認為，本人認為測試需求是本身是個變態和錯誤的做法，只所以有測試需求，原因是實際研發中產品需求、設計需求定義不清晰，開發人員就糊里糊塗地進行設計和開發了，但測試人員無法基於需求提煉出來測試點，迫於無奈，不得不給需求定義人員擦屁股，將需求細化到能夠提煉到測試點的級別。正規做法應該如此：需求定義人員詳細定義產品需求和設計需求，而同時測試設計人員直接針對此需求分析該需求如何測試，重點測試哪些內容，所以測試需求，本身應該叫：需求的可測試性分析，其實是需求的屬性之一，這樣做的好處是：可以直接判斷需求定義是否具體，是否可驗證，凡是不能驗證的需求都是錯誤的需求；後續測試用例開發人員針對需求的可測試性分析，直接編寫對應的測試用例。
內部需求：實際產品需求定義時，我們更關注的是外部客戶的需求，因為外部客戶直接給我們錢，但其實產品也有內部客戶，也需要關注內部客戶的需求，誰是內部客戶呢？例如製造、客服就是內部客戶，如果設計時，沒有考慮到製造的要求，直接導致製造效率低下、良品率低，最終影響產品的市場表現；製造部門的需求、客服部門的需求，也需要在產品開發前期就識別，成為產品需求和設計需求的一部分，並在設計開發中實現。
外部需求：對照內部需求，外部需求是客戶、渠道、合作商、用戶等，外部關聯單位的需求，具體分析時就需要通過銷售過程分析，詳細分析產品從生產線下來，到最終客戶手裡需要經過哪些環節，而這些所有環節的需求統稱外部需求，所有外部需求都是我們需要重點關注的，一個環節不滿足，產品可能就到不了最終客戶手裡，就無法轉化為實實在在的商業利益。
業務需求：針對業務需求業界缺少標准一致清晰的定義，個人認為業務需求更多是從客戶的業務發展、財務、戰略出發，更多體現了客戶高層的要求，涉及產品整體宏觀上的要求；例如針對ERP，「庫存周轉率提高50%」，針對電信設備，「能夠無縫升級到下一代網路，從而節約投資成本」，針對銀行系統，「提高客戶的資金周轉效率30%」；針對網路游戲，「使單個用戶的費用貢獻提高50%」，等等

㈥ 如何把潛在客戶的購買慾望轉化為購買力

對潛在客戶進行桌游成交地溝通是為了將潛在客戶轉化為成交客戶的第一步，除此之外，企業還要通過各種營銷手段將產品或服務的有關信息傳遞給潛在客戶，以便促進他們向成交客戶轉化，在促進潛在客戶向成交客戶轉化的過程中，企業必須做好以下五個方面：

1、從客戶需求出發——為客戶提供不可抗拒的產品

企業只有強調產品的特點和品質與客戶需求之間的一致性，潛在客戶才會逐漸接受該產品和服務；否則，盡管產品的特點和品質再好，但如果他們與潛在客戶的需求不符，客戶對企業的產品仍會視而不見。

所以，在與客戶溝通時，企業要對潛在客戶的需求、個性、品味、客戶對產品的評價標准進行充分了解。對潛在客戶來說，根據這些信息制定的營銷和溝通策略才是最不可抗拒的。

2、你不是在單純地買產品——而是在為客戶制訂解決問題的方案

企業一定要有這樣的理念：企業是為了解決客戶的問題才提供產品或服務的，為客戶提供的是解決問題的方案，而不是單純地銷售產品或服務。因此，客服人員要把自己定位為該行業的專家，以客戶的參謀或朋友的姿態出現，對客戶有著很強的同理心。

永遠站在客戶的角度，把自己專業的想法坦誠地告訴客戶，與客戶同呼吸、同命運，為客戶創造價值。這樣才能夠贏得客戶的心，贏得客戶的認同，潛在客戶自然就變成了成交客戶。

3、了解客戶成交的阻力——及時採取措施，化解成交阻力

潛在客戶准備購買產品的決策過程中往往會遇到各種各樣的阻力。這些阻力可能來自經濟方面，也可能來自社會、時間、心理和競爭者的影響等其他方面，他們影響著潛在客戶購買的決策。

企業要及時了解潛在客戶所面臨的購買阻力是什麼，並及時採取有效措施，對產品營銷和客戶溝通策略進行有針對性地調整，盡量消除客戶購買的阻力，使潛在客戶轉化為成交客戶。

4、識別客戶資料——准確鎖定客戶，句句說到客戶心坎上

營銷人員可以根據自己掌握的資料，對潛在客戶進行篩選，選擇最有可能和最具有購買實力的准客戶進行拜訪。鎖定客戶後，營銷人員應該尋找恰當的拜訪時間和拜訪方式，精心准備拜訪話題，精心設計拜訪方案。

雖然是陌拜，但由於對客戶資料已了如指掌，這樣就做到了有的放矢，句句切中要害，說到客戶心坎上。同時，營銷人員給客戶介紹公司成功案例，用事實證明公司的能力和信譽，以贏得客戶認可，促進成交。

5、盡量降低客戶的交易成本——除了降低價格成本外，你還可以降低其他成本來贏得客戶

客戶購買產品的交易成本包括價格、時間成本、經理成本和心理成本。有的時候，盡管客戶有產品方面的需求和慾望，但他們卻不一定付諸行動，原因往往是他們認為交易成本太高。

很多企業在考慮降低客戶的交易成本時，往往只考慮價格，對客戶為購買產品而耗費的其他成本視而不見，這是極其錯誤的。企業不僅要降低客戶購買產品的價格成本，還要為客戶提供各種便利條件，節約客戶時間，提高客戶滿意度。

㈦ 怎樣才能有效的將用戶需求轉化為產品需求

下面以「網路地圖的公交導航沒有公交車的實時進度提示」，來說明如何將用戶需求轉換為產品需求，分為還原、價值和設計這三個步驟。

用戶需求

一、需求還原：需求是什麼

這個需求在現實情況下，應該是這么被提出來的「哇靠，網路地圖不行啊，公交車到哪了都不知道」、或者 「等了這么久，還說是最佳方案，結果公交車到現在都沒來，方案不準吧」，然後用戶可能把問題或者需求反饋給客服。一般產品經理接到手的需求可能是轉過幾手的，不一定是初始需求了，所以一定要做需求還原的工作，盡可能把用戶的真實需求還原出來。

1、誰有需求

在還原用戶需求的時候需要明確需求的主語是誰，比如是老闆、運營、客服還是市場等，並且盡可能詳細的描述出來。這里不能直接寫成是網路地圖的用戶，這樣就無法區別是駕車導航的用戶還是公交導航的用戶，而駕車導航的用戶根本就沒有這個需求。很多時候，產品經理一頭扎入需求的細節當中去，到最後卻忘了給誰做的，所以做出來的產品也就有很多問題。

2、什麼場景下發生

還原需求發生的場景，需要站在用戶的角度去思考，並且盡可能全面的描述出來有哪些場景。描述場景一般主要從時間、地點、人物、行為、心理這5個方面去描述（描述心理狀況是最能看清楚是否真實的），目的是還原需求發生的場景，證明其存在的真實性，後面亦可用於指導需求的方案設計。

3、解決什麼問題

需求場景雖然真實存在，說明有一定的合理性；但此時再問一遍自己，這個需求到底解決什麼問題。因為人們真正的需求，往往隱藏在表面問題之下，即問題是有層次的。比如開頭的「等了這么久，還說是最佳方案，結果公交車到現在都沒來，方案不準吧」這個問題，乍一看是說推薦方案不準確，其實仔細分析一下用戶在抱怨「等了好久，公交車還沒來」，問題也就是不知道公交車到哪了，但如果一開始就知道公交車還有好多站要等，是不是就不會抱怨了。

二、需求價值：要不要做，什麼時候做？

1、企業價值

可以從品牌增值與收入增值兩個點分析，塑造品牌是企業長期價值所在，收入是更看得見的價值。對2C來說提升用戶體驗就相當於品牌增值，因為體驗好就會黏性強，也就會吸引更多人使用，而流量就是收入。

2、可行性與成本

產品經理可以不了解技術實現的細節，但必須要了解實現需求的可行性及其投入成本。這個需求其實網路的產品經理絕對是想到過的，並且也深入分析了，畢竟高德地圖都做出來有一段時間了。為什麼沒做？因為要實現這個需求，必然需要知道每一輛公交車的實時到站數據。

根據價值、可行性與成本的分析，對需求進行優先順序的排序，比如優先順序P幾，跟著哪個版本研發。這個需求還是需要提案出來，進行商定的，需要做的前期准備較多。 以上，需要確定需求的價值，即要不要做，什麼時候做。

三、需求設計：怎麼實現？

關於需求設計這塊，主要是講如何把需求落地到可研發的產品需求，即業務流程、功能清單、原型設計等方面的詳細描述。這個階段切記不要覺得自己腦海里有方案了，然後馬上打開sketch或axure開始畫原型了，結果畫著畫著發現某個流程沒考慮清楚，又開始推到重來浪費工時。一開始要做的事情先把大的框架搭好，如需求背景、用戶場景、業務流程、功能規劃等分析好，然後在這個框架梳理清楚之後，再去設計原型，這時會覺得順很多。原型更多的是考驗體驗設計、邏輯閉環等細節層面的功力，需要仔細琢磨、推敲。

所以，深入的去分析一個用戶需求，並將它轉化為靠譜的產品需求，是一件可以做的很復雜的事情。

㈧ 如何將用戶需求轉換為產品需求

可學習產品經理相關的知識技能

㈨ 如何把用戶需求轉化為產品需求

1.需求的判斷

產品經理先要判斷這個需求是否靠譜，判斷的標准就是需求是否有「 價值 」，這個價值，具體包括：

用戶價值 ：對什麼樣的用戶，解決了他們什麼問題，之後有什麼好處？ 如果這個需求解決了產品核心用戶的關鍵問題，滿足之後能極大提升用戶訪問時長和留存率，那就是有用戶價值的。

商業價值 ：在滿足用戶價值的前提下，企業消耗多少成本？有何收益？ 如果僅通過簡單的開發，能帶來大量廣告點擊，那就是有價值的。

社會價值 ：實現需求後，對社會有何貢獻？ 這一點會再成熟產品上見到，比如支付寶的種樹活動，不僅對用戶，對社會也是有正面作用的。

具體到判斷方法，簡單羅列一些，有興趣的同學可以自行網路：

商業模式畫布、KANO模型、收益預測、維格斯法（WIEGERS』 Method）、PEST模型

2.需求的挖掘

有些時候，用戶所提的需求，也許實現後確實有價值，但往往實現後，用戶卻並不買賬，這時候就要產品經理提前 判斷某個需求背後到底隱藏著 用戶什麼樣的真實想法。
3.需求的描述

覺得需求有價值，也判斷出真實需求了，接下來就要用「 產品語言 」將用戶需求轉化成產品需求，方便後續的實施團隊理解。

所謂的產品語言，包括： 需求樹+用戶故事+用戶任務

需求樹 。就是採用樹形結構，以某個功能參與角色角度出發，分別描述不用的角色，在什麼場景下，希望完成什麼任務，需要什麼功能。務必做到不重復、不遺漏，符合MECE原則。
用戶故事 。就是用講故事的方法，描述一個用戶，具體使用產品、使用功能的場景。

用戶任務 。就是用格式化語言，描述某個用戶，具體使用某個產品功能，完成某個任務的過程，並賦予這個任務的價值和成本

通常需求樹用於產品結構描述，用戶故事用於產品背景描述，用戶任務用於產品某個需求的描述。

㈩ 產品方法：如何將用戶需求轉換為產品需求

前兩天在知乎上有人邀請我回答這個問題，一開始覺得自己工作中經常碰到就嘗試回答了下，但下筆後又發現又有點復雜。很多時候，用戶的需求是一個問題、一個想法或者是一個吐槽，但是想要轉換為產品需求，這中間的過程會有很多坑。下面拿一個例子就是之前我吐槽「網路地圖的公交導航沒有公交車的實時進度提示」，來說明如何將用戶需求轉換為產品需求，分為還原、抽象和設計這三個步驟。

1、需求還原：需求是什麼，是否真實、合理？

     這個需求在現實情況下，應該是這么被提出來的「哇靠，網路地圖不行啊，公交車到哪了都不知道」、或者 「等了這么久，還說是最佳方案，結果公交車到現在都沒來，方案不準吧」，然後用戶可能把問題或者需求反饋給客服。一般產品經理接到手的需求可能是轉過幾手的，不一定是初始需求了，所以一定要做需求還原的工作，盡可能把用戶的真實需求還原出來。

    1.1、誰有需求。在還原用戶需求的時候需要明確需求的主語是誰，比如是老闆、運營、客服還是市場等，並且盡可能詳細的描述出來。這里不能直接寫成是網路地圖的用戶，這樣就無法區別是駕車導航的用戶還是公交導航的用戶，而駕車導航的用戶根本就沒有這個需求。很多時候，產品經理一頭扎入需求的細節當中去，到最後卻忘了給誰做的，所以做出來的產品也就有很多問題。

    1.2、什麼場景下發生。還原需求發生的場景，需要站在用戶的角度去思考，並且盡可能全面的描述出來有哪些場景。描述場景一般主要從時間、地點、人物、行為、心理這5個方面去描述（描述心理狀況是最能看清楚是否真實的），目的是還原需求發生的場景，證明其存在的真實性，後面亦可用於指導需求的方案設計。這個需求的場景如下：

    1.3、解決什麼問題。需求場景雖然真實存在，說明有一定的合理性；但此時再問一遍自己，這個需求到底解決什麼問題。因為人們真正的需求，往往隱藏在表面問題之下，即問題是有層次的。比如開頭的「等了這么久，還說是最佳方案，結果公交車到現在都沒來，方案不準吧」這個問題，乍一看是說推薦方案不準確，其實仔細分析一下用戶在抱怨「等了好久，公交車還沒來」，問題也就是不知道公交車到哪了，但如果一開始就知道公交車還有好多站要等，是不是就不會抱怨了。

    一般描述問題可以寫一個表面的用戶問題，以及深層的問題（問題的本質）。不需要分層太多，分的太多說明沒有了解問題的本質是什麼。如下是這個需求要解決的問題：

以上，基本可以說明需求是什麼，並且是否真實與合理。

    2、需求價值：要不要做，什麼時候做？

    2.1、用戶價值。主要說明這個需求對於用戶來說，處於什麼價值區間。可以用東京理工大學教授狩野紀昭提出的KANO來描述如下圖（具體描述可以自己查下），分數代表用戶體驗增減。這個需求是可以落在期望需求之列，因為首先這個對導航工具來說不是必備功能，但是提供後可以提升用戶體驗；而用戶在查看導航方案之後，是期望有一個公交車進度提示的（算不上興奮，因為用戶在具體的情景下是想得到的）。

    2.2、企業價值。可以從品牌增值與收入增值兩個點分析，塑造品牌是企業長期價值所在，收入是更看得見的價值。對2C來說提升用戶體驗就相當於品牌增值，因為體驗好就會黏性強，也就會吸引更多人使用，而流量就是收入。

    2.3、可行性與成本。產品經理可以不了解技術實現的細節，但必須要了解實現需求的可行性及其投入成本。這個需求其實網路的產品經理絕對是想到過的，並且也深入分析了，畢竟高德地圖都做出來有一段時間了。為什麼沒做？因為要實現這個需求，必然需要知道每一輛公交車的實時到站數據，這里簡單描述下可行性（沒有深入研究過這里的可行性）：

    2.4、排定優先順序。根據價值、可行性與成本的分析，對需求進行優先順序的排序，比如優先順序P幾，跟著哪個版本研發。這個需求還是需要提案出來，進行商定的，需要做的前期准備較多。

    以上，需要確定需求的價值，即要不要做，什麼時候做。

    3、需求設計：怎麼實現？

關於需求設計這塊，主要是講如何把需求落地到可研發的產品需求，即業務流程、功能清單、原型設計等方面的詳細描述。可以參考： 《產品方法：需求處理的正確姿勢》

   所以，深入的去分析一個用戶需求，並將它轉化為靠譜的產品需求，是一件可以做的很復雜的事情。稍微拔高下，相當於你有一個idea，打算把它當成是一個創業項目，去拉團隊、拉VC，結果每一個人說你「想多了，怎麼可能」。整個過程叫做如何將你的夢中Idea變成靠(苦)譜(逼)的創業項目。

鏈接：https://www.jianshu.com/p/1d37aac4c80c