一個專案帶你走進產品經理的世界(2)需求分析

佐珥發表於2019-04-23

上一篇:從收到一個需求談起 我們主要介紹了收到需求之後應該怎麼和需求方溝通,這一篇將介紹具體怎麼分析這個需求。

一個專案帶你走進產品經理的世界(2)需求分析

產品經理收到需求之後,切記不要急著開始畫原型圖,深入分析思考是第一步。磨刀不誤砍柴工,全面得思考可以讓後續的步驟走得越來越穩、越來越快。

首先,要判斷這個需求是某個產品的一個功能,還是一個相對獨立的產品。如果是某個產品的一個功能,則這個需求相對較小,需要考慮怎麼相容產品現有的功能。如果是一個相對獨立的產品,那麼恭喜你,輪到你上場表演了,擼起袖子準備幹吧。

針對上文早報的需求,很明顯,是一個相對獨立、功能完整的產品,姑且稱之為「簡報生成器」。

這個產品定位可以簡單總結為:生成使用者想要的簡報。

一個專案帶你走進產品經理的世界(2)需求分析

那這種型別的產品應該怎麼做需求分析呢?

首先,這個產品的使用者是誰?使用者有什麼特點?

你是不是和剛入行的我一樣以為回答這個問題,需要做大量的使用者調研、使用者訪談,然後還得畫一個高大上的使用者畫像(persona)。當然掌握使用者調研、使用者訪談、使用者畫像的技能也是 okay 的,但是大多數情況下,公司不會給你太多資源、太多時間去做這件事,你只能自己想辦法。

同時,調研 100 個使用者和調研 10 個使用者帶來的結果可能相差不大,前提是你找到了「對的人」,而不只是尋求調研的使用者數量。

在早報這件事情上,因為我本身就是資深使用者。所以,就「憑經驗」簡單分析下,早報的使用者群體分為兩種:

1. 一幫因為工作而整日奔波在各個公司使用者社群的社群運營或運營實習生;

2. 一幫管理興趣愛好組和其它學習小組的兼職(義務)運營。

那這幫使用者有什麼特點呢?

不同點:

做事目的不同。第一類使用者是出於工作的目的,期望高效得完成工作任務。第二類使用者是出於興趣,期望獲得群體的認同感,位於馬斯洛需求層次的較高階別「尊重的需要」。

早報格式要求不同。第一類使用者要求的早報格式相對比較正式,第二類使用者要求的早報格式可能偏向活波。

相同點:

早報的內容素材(比如,AI 產品早報、黃金每日行情等)都是相似的,不會有較大變動。

其次,這個產品滿足了使用者什麼需求?解決了使用者什麼問題?

最好能用一句話回答這個問題。為什麼?因為面試官喜歡這麼問。

這個產品滿足了使用者快速生成每日自定義早報內容的需求,節省了使用者整理早報的時間,提高了輸出每日早報的效率。

再次,使用者在什麼情況下有這個需求?不同場景下的需求是一樣的嗎?

「簡報生成器」的使用場景:使用者需要在自己管理(運營)的社群裡傳送早報 / 午報 / 晚報的時候,才需要用到這個產品。相對來說,這個需求是一個很低頻的工具類需求,而且不同場景下的需求是一樣的。

插句題外話,你認為使用者是不是每天必須要開啟「簡報生成器」,才能完成自己的任務?

如果這個產品是一個商業產品,面臨生存和盈利的壓力,那作為產品經理的你是需要仔細考慮一下這個問題。不過,作為使用者,效率是第一位的,能在不開啟這個產品的情況下達到自己的目的當然是最好的了。

很多時候,儘可能高效得滿足使用者的需求和儘可能多得創造商業價值之間是存在衝突的,具體怎麼權衡就要依情況而定。如果你運氣很好,遇到一個不在乎 KPI 只在乎產品質量的老闆和公司,那麼你真的是燒了高香了。

最後,現在沒有這個產品,使用者是怎麼做的呢?現在的解決問題有沒有什麼問題?

現在沒有「簡報生成器」,使用者都是手動儲存簡報格式,修改日期等資訊,然後手動複製各大新聞網站的新聞標題到預定的簡報格式中,最後將整理好的簡報傳送至各大社群。

現在的解決方案主要問題是重複性工作比較多,比較浪費使用者的時間。複製格式、複製標題、複製標題、複製標題…轉發到對應的社群,其它沒有什麼問題。

####最後的最後,你有沒有比現在的解決方案更好的方案?

嗯,是的,你沒看錯,答案肯定是有的。比如複製標題的那部分,機器(爬蟲)完全可以替代人工,這一步的簡化已經可以節省 90% 的工作量了。

那還有沒有更好的解決方案?

比如,設定一次,終生免費的那種。咳咳…不要跑偏,我說的是設定一次,然後就可以靜靜地當個讀者那種。當然是有的了~

「簡報生成器」將自動生成使用者期望的早報內容,並可以自動傳送至使用者。終端使用者只需要複製轉發到各大社群即可。如下圖,紅色圈出來的部分是使用者需要完成的步驟,其餘步驟均可通過產品實現。當然,前提是提前設定好早報格式。

一個專案帶你走進產品經理的世界(2)需求分析

有的時候,你辛辛苦苦整理了很久的使用者反饋,做了很久的需求分析。但最後,卻找不到比當前解決方案更好的方案。這種事情也是會經常有的,可能是技術不夠成熟,也可能是資源不夠,也可能老闆覺得有更重要的事情要做。產品經理就是一個看似很厲害但實際上權力還不夠大的虛名「經理」。當然,這並不影響產品經理改變世界。

到這裡,我們就完成了從使用者需求到初步的產品解決方案的形成,也就是需求分析的部分,下一步我們將初步的產品解決方案變成具體的產品功能列表。

總結

———

1、需求分析究竟分析些什麼?

使用者:產品的使用者是誰(有幾類)?有什麼特點?

場景:使用者會在什麼情況下有這個需求(對我們的產品感興趣)?不同場景的需求一樣嗎?

需求:產品滿足了使用者什麼需求?解決了使用者什麼問題?

當前解決方案:現在沒有這個產品,使用者是怎麼做的呢(當前解決方案是什麼)?現在的解決問題有沒有什麼問題?

產品解決方案:你有沒有比現在的解決方案更好的方案?

2、怎樣做一次讓領導滿意的需求分析?

把事情說清楚。找一個不懂業務、不懂邏輯的人看看,看他能不能看懂。當然,不一定適用。很多時候,很多人就是為了分析得高大上、分析得讓別人讀不懂,方才顯示自己的牛逼。

比需求方想得更遠。以「簡報生成器」為例,這個產品的使用者是發早報的人,但最終消費「簡報生成器」生成的內容的卻是讀者,如果你能在滿足使用者需求的前提下讓最終的讀者滿意,那麼使用者又有什麼理由拒絕你的產品呢?

3、如果別人質疑你的分析結果?

首先,不要怕被挑戰,不要怕被質疑。產品經理在日常工作中很容易被挑戰,大到老闆、領導,小到團隊的 UI、研發、測試,所有人都有充分的理由挑戰你。試想如果你的分析結果和所有人想得都一樣,那還有誰會質疑你。被質疑恰恰說明你想到了別人沒有想到的點。

其次,產品這個東西本身主觀性比較大,你覺得這個產品很爛,但有可能你的領導就會覺得這個產品很好。不是說領導品味有問題,只是每個人思考問題、看待問題的方式不同。當別人質疑你時,大膽說出你的思考過程就好。

4、接下來要做什麼?

將產品解決方案落地為具體的產品功能。


好的,今天這篇文章到這裡就結束了,我們的《一個專案帶你走進產品經理的世界》系列文章完成進度如下:

黃色為當前進度~

一個專案帶你走進產品經理的世界(2)需求分析

— The End —

擴充閱讀 ———

一個專案帶你走進產品經理的世界(1)從收到一個需求談起

相關文章