從問題中做分析,產品才能準確到位

閱讀 ?·? 發(fā)布日期 2016-09-01 16:25 ?·? admin

分析對象不同,思考的內容不同。

一、項目初期,對可行性的分析

可行性=市場環(huán)境+用戶需求+產品邏輯+自身能力

1. 市場環(huán)境

1.1 背景和趨勢:

這個方向是不是很火(O2O)?

會不會是未來互聯網的趨勢(VR)?

1.2 競品情況:

有多少團隊在做?

BAT 是不是在涉足,或者計劃涉足?

他們目前的市場份額如何?

1.3 當下市場規(guī)模:

所在的垂直市場有多大?

所在的大類市場有多大?

市場的空間多大?

藍海還是紅海?

2. 用戶需求

2.1 需求定義:

是到底要解決什么問題(沒問題存在的需求都是偽需求)?

這個問題是不是特別嚴重?有沒有詳細的場景描述(XXX時,特別討厭做XXX,要是XXX就好了)?

有多少用戶會遇到這些問題(比如是你和你老婆會遇到,還是你確定所有人都會遇到)?

2.2 需求剛弱:

是不是很痛點、很貼切的需求(比如上門洗車并不是剛需)?

能不能解決實際問題(比如不解決真實性的問題,只是把租房信息放平臺上有意義嗎)?

目前用戶的需求是不是已經充分滿足(比如我為什么要特地下個舞蹈教學愛屁屁而不是在優(yōu)酷看)?

2.3 需求真?zhèn)危?/p>

是不是大家都認可這個問題需要解決(比如「我胖但我不想減肥」)?

大家說的需求是不是大家真正的需求(什么是「偽需求」?能否舉例說明? – 蘇杰的回答)?

3. 產品邏輯

3.1 功能邏輯:

功能能不能真正滿足需求(比如我要的是方便快捷,但上門理發(fā)反而更折騰)?

有沒有不合理的漏洞(比如我們希望記錄用戶的信用,但用戶交易卻不會通過我們進行)?

要怎樣實現目標功能(配合的具體運營、技術、產品要怎么做)?

3.2商業(yè)邏輯:

離交易是不是足夠近(不要做到最后發(fā)現成了公益平臺)?

用戶價值在你的產品上會不會體現(比如付費時的交易、創(chuàng)作時的內容、社交時的關系鏈)?

4. 自身能力

4.1 團隊情況:

運營、技術和產品的能力能否實現目標的功能(類似人工智能、團購大戰(zhàn)不是小團隊可以碰的)?

創(chuàng)始團隊是否有能力勝任其職責(創(chuàng)始團隊無法 hold 住更多牛人的加入)?

4.2 資金情況:

按照預想的盈利方式、收支計劃,錢夠不夠花?

在下一次融資前,公司的發(fā)展能否達到可以談融資的地步?

雖說很多都是創(chuàng)始人該想的,但落實到產品上,就應該是產品經理搞明白的。

另外,這部分寫完后,我發(fā)現跟厲哥在 商業(yè)計劃書(BP)應該包含哪些點? – Roy Li 的回答 中提到的你是誰(自身能力)、你想解決什么問題(用戶需求)、市場和競爭情況(市場環(huán)境)和怎么做(產品邏輯)不謀而合。供參考。

二、產品設計時,對功能交互的用戶體驗的分析。

用戶體驗=有用性+易用性+友好性

1. 有用性

1.1 需求類別

需求是基本型、期望型還是興奮型(參考 作為產品經理,如何給用戶需求排序)?

需求所要求的功能是目前是重要的還是緊急的還是其他(比如聊天記錄都會丟失時要不要美化圖標)?

1.2 可操作性

功能使用是不是能夠達到效果(比如老人機模式卻沒有讓字體夠大)?

有沒有考慮到用戶的使用場景(比如移動數據下提供純文字省流量的模式)?

在使用時會不會經常打斷用戶(頁面跳轉太多、需要完成的步驟太多)?

1.3 容錯可靠

所有錯誤情況是不是考慮到了(比如「啊,這個空白頁面是什么意思居然沒有解釋」)?

在極端狀況下是不是能夠可靠(比如便簽字數太多就根本不能用了)?

2. 易用性

2.1 學習成本

用戶的學習成本是不是足夠低(比如要先給用戶看一百字的新手教程嗎)?

邏輯的一致性是不是夠好(比如按鈕長得不一樣、信息格式不一樣)?

用戶再次使用時需不需要重復學習(用過一次就完全能夠掌握并記憶)?

2.2 信息傳遞

文案是不是都能通俗易懂(比如「現在無法停止通用卷設備」)?

用戶需要的信息是不是都能找到(比如我是滴滴的司機,卻找不到獎懲規(guī)則)?

提醒和警告是不是完整(告訴用戶發(fā)生了什么、因為什么、能做什么)?

2.3 高效完成

現在的方式已經是最好的了嗎?有沒有更好的方式(比如 Windows 下操作彈出 USB 設備還可以再簡化)?

有沒有在處理特殊情況時的高效方法(比如能不能有多選和批處理的功能)?

3. 友好性

3.1 視覺效果

是不是美觀?

會不會造成不適感?

3.2 簡潔清晰

界面元素還能再減少嗎?

視覺焦點是在重要信息和功能上嗎?

三、在項目管理和個人管理上,要做問題分析。

1. 定義問題(What、Who、Why)

要解決什么問題(嚴重 BUG,功能缺失,項目延期還是文檔有誤)?

[項目] 責任人是誰(是產品經理沒有發(fā)現、測試沒有意識到還是開發(fā)有疏漏)?

具體起因是什么(比如技術并不了解業(yè)務背景所以做錯)?

2. 解決問題

有哪幾種解決方案(不是先處理人,而是先處理問題、羅列方案)?

每種方案的利弊是什么(比如有的會影響產品進度但節(jié)省成本、有的會耗費公司財力但速度快等)?

[項目] 利益相關者認同哪個方案(比如關乎運營的方案不能繞過他們、改動設計的地方也不能不通知設計師)?

從長遠來看哪個方案獲益最大、損失最小(比如臨時的解決方案雖然快,但可能會埋下隱患)?

3. 復盤問題

造成問題的深度原因是什么(比如技術水平本身有問題、工作流程設計有誤)?

問題如何暴露的,在之前為什么沒有暴露(誰發(fā)現的問題、在其他時間為什么沒發(fā)現)?

從根本上解決問題的方法有什么(比如招募專家、改進工作流程)?

檢查異常的機制是不是需要改進(比如在哪個環(huán)節(jié)加入總監(jiān)的評審)?

4. 提高效率/節(jié)省成本

工作中比較復雜的、步驟繁瑣的事務能不能簡單處理(比如需要大量對賬結算的方案可以簡化邏輯,實際不影響效果)?

簡單處理的事務能不能形成標準化的流程機制(比如對賬結算在固定周期、用固定方法完成)?

標準化的流程機制能否實現自動化(比如對賬結算用程序實現自動化)?

我數了數,大概有 60 個問題。如果作為產品經理在做各種分析的時候全都搞明白,應該差不多了。