產品經理應該如何解決各種需求

4 評論 8594 瀏覽 53 收藏 8 分鐘
🔗 B端产品需要更多地依赖销售团队和渠道合作来推广产品,而C端产品需要更多地利用网络营销和口碑传播来推广产品..

編輯導語:作為產品經理,日常工作中少不了解決各種需求的時候,本文作者分享了產品經理解決需求的相關方法,根據自身工作經驗分析了解決需求的思路等,一起來看,希望對你有幫助。

A同學:啊好煩吶,公司其他部門每天怎么提出來這么多需求??!

B同學:真是無語!剛入職一周就要處理這么多需求,都是一些前幾個月沒有解決的需求都要壓在我身上了!

作為產品經理來說,每天會面對不同人員提出的不同需求,那么我們面對這么多的需求,我們是如何做判斷的呢,如何去整理歸納呢?

哪些需求是當下最應該解決的需求呢?以下我為大家去總結了一些個人的一些經驗供大家參考使用。

一、真、偽需求

需求可以分為真?zhèn)涡枨?,真需求就是用戶真正的需要,比如:我們去商場買一條裙子,這個裙子很好看,價格對我來說也挺合適,那么我就買了這一條裙子,我的真需求就是這個夏天缺一條這樣的裙子。

偽需求就是,用戶有某種需求但在某種場合不好意思說出口。

同樣去商場買裙子,這個裙子很好看,很合適,但是由于價格太高,我不好意思說出來,那么一般就會說,這個裙子的顏色不好看,等等理由,那么這時,我提出的顏色不好看就是屬于偽需求了,我就是覺得價格貴,不好意思說出口,說出來了會讓人笑話。

所以產品經理需要對需求進行自己的分析整理,往往在工作中,用戶可能表達出來的需求并不是真實需求,我們需要對需求進行深挖,發(fā)掘用戶的根本目的是什么。

再去對照需求去實現(xiàn)相對應的功能,不然這些功能做出來也無濟于事。所以這里我也也想說,產品經理不是為了功能去做功能,要去看用戶為什么需要這個功能。

二、需求的收集、整理、分析三部曲

做過To C的產品朋友應該都知道,產品是更注重拉新、促活、留存、變現(xiàn),產品的方向是更偏重于運營。

往往產品都是免費給普通大眾去使用的,產品的也比較容易上手去使用的,用戶的逃離成本也比較低。

包括盈利模式也是以流量變現(xiàn)、廣告變現(xiàn)為主。

To B的產品往往是面對于企業(yè)的,客戶使用往往是需要支付費用的,系統(tǒng)也是有一點的復雜程度的,需要產品經理等研發(fā)人員去培訓客戶,所以客戶的逃離成本也比較大。

盈利模式也是以買斷或收取年費等為主,所以在收集需求方面也會有一定的不同,偏重點也會有變化。

1. 收集

那么C端產品在0-1的開發(fā)時,前期需求的來源有很多方式:競品、行業(yè)分析報告、行業(yè)資深人士的訪談、用戶的問卷調查、公司內部不同崗位的頭腦風暴、甚至是老板的需求等等。

B端產品往往需求的來源會比較簡單:做外包就是甲方客戶為主導,通過對甲方公司的不同人群的狙擊訪談等方式,在這里需要注意的是面對不同身份的訪談需要注意方式方法。

系統(tǒng)是公司自己研發(fā)的,給內部去使用,需求的來源肯能更多的就是本公司的人員、老板。

那么在時間上外包項目也是比較趕工期的,肯能在時間把控上需要進行控制,自研的給公司內部使用的系統(tǒng)研發(fā)時間包括項目的排期可能會比較寬松,按部就班,哪一步出了問題就停下來去解決。

所以面對不同的公司不同的行業(yè)要講究收集的方式方法以及經驗。

2. 整理

根據以上的需求進行收集后,我們前期講究的是橫向收集,也就是收集需求不問對錯,注重收集需求的廣度以及數量。

在有了這么多的需求后,我們產品經理要做的是把他們都放在需求池里,在需求池里進行分析整理。

3. 分析

就是縱向分析,像一個T字形,對需求的本質進行深挖。那么剛剛提到過的需求池是什么呢?

就是把需求做定義,誰提出的、用戶提出的需求內容是什么、這個需求的底層需求是什么、以及運用Kanon模型把需求分為:必備型、期望型、魅力型、反向型、無差異型。

通過分析提煉出當下符合產品的版本、公司目前的情況的需求,那么我們在分析時需要分析需求的廣度(多少人需要的)、需求的頻率(用戶多長時間需要一次)、時間節(jié)點(哪個版本該上)、用戶的痛度(這個需求的痛點有多痛,用戶離開這個需求還能不能繼續(xù)使用產品)。

還有一些方法,比如馬斯洛需求原理等方式去對需求進行分層等等在這里就不細說了,感興趣的同學可以私信我或度娘一下。

三、需求落地

以上通過收集、整理、分析了需求之后,我們產品經理需要對需求進行落地,通過需求分析文檔、需求的優(yōu)先級排表、去把用戶的痛點找到后,提出解決方案,把這些解決方案再去交給客戶、公司內部的技術人員去看、這里我經常是開一些需求評審會議。

通過會議的方式讓不同人員用不同維度進行需求的評定,這里我們需要組織和記錄、產出一些會議紀要,再根據會議的內容去修改需求,反反復復,一直到需求評審會議里找不到問題后,再進行原型功能的設計。

所有的工作一多了就會顯得一些枯燥無味,那么我們要學會找到方式方法去面對這些困難!知難而退,碌碌無為,只有因難而上,才能無堅不摧!

 

本文由 @汪仔6447 原創(chuàng)發(fā)布于人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基于 CC0 協(xié)議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 大多數的時候,需求文檔和原型是一起產出的,需求文檔修改幾遍,業(yè)務原型也需要反復修改,這來來回回的時間,都是算在需求建設周期之內的,現(xiàn)在的需求來了就是急活,沒有那么多反復確認的過程

    來自吉林 回復
    1. 根據每個業(yè)務的習慣、公司的流程、實際產品的情況而定,感謝您的意見~

      來自湖北 回復
  2. 知識點滿滿的文章,作者分享產品經理解決各種需求的方法非常適用。

    來自江蘇 回復
    1. 感謝您的支持~

      來自湖北 回復
专题
13265人已学习13篇文章
随着数字化的发展,企业都在进行数字化转型发展。那么,对于传统第三产业企业来讲,数字化升级是什么?如何做数字化?本专题的文章分享了作者的见解。
专题
15802人已学习13篇文章
生活中,我们会看到路标、指示面板、箭头指引诸如此类的常见的导航,其实网络中也有很多导航指引。导航有什么用呢?导航设计又要遵循什么规范?本专题的文章分享了导航设计指南。
专题
12996人已学习13篇文章
产品设计与用户的体验感息息相关,但是很多时候产品经理在产品设计过程中会忽略掉可能影响到用户体验感的一些因素,比如一些异常状态的出现会让用户产品卸载的想法。本专题的文章分享了产品异常场景设计指南。
专题
17588人已学习13篇文章
本专题的文章对整个商业模式进行了一个清晰的梳理和设计,并说明了商业模式如何变成可执行的路径。
专题
16044人已学习12篇文章
数据中台是处于业务前台和技术后台的中间层。本专题的文章分享了如何搭建数据中台。