本文作者將結合自身經驗，與你分享作為一名合格的產品經理應做到的幾點內容。enjoy~

好產品一定出自好的“產品媽媽”，我感知和認識的好產品經理應該具備以下幾個方面：

• 流程上對產品從0到1的操作熟悉，掌握相應工具和技能
• 思想上用發展的眼光規劃產品
• 意識上保證產品形態與經濟學規律一致
• 執行上既要有主人翁的擔當又要有用戶思維
• 發散上讓創新Idea強大產品
• 總結上做好數據分析

1、對產品從0到1的操作熟悉，掌握相應工具和技能

萬事開頭難，產品經理要對產品研發的過程有一定了解，才能開展工作，否則就會陷入各種“懟”，產品的產生過程一般會經過6個步驟，在每個步驟中產品經理要做些什么，要有一定了解。

獲取需求階段：要知道怎么獲取需求？需要什么技能？

需求來源有內部需求和外部需求，內部需求來自你的上級，公司戰略，同事建議，數據分析和自己的體驗等等；外部需求則來自合作客戶，用戶反饋，競品對比，行業政策趨勢等等?？梢哉f你要接收方方面面的需求信息，這個時候要有好的溝通和理解能力。

分析需求階段：要明白分析需求的目的？需要什么技能?

分析需求是為了確定產品的目標對象，業務范圍，業務可行性，你要站在公司角度，用戶角度（不同群體，不同年齡段）結合背景因素，給出一個產品考量標準，實現去偽（需求）求真 （需要）。要有嚴密的邏輯分析能力，知識面和認知要比較高，既要感性又要理性，還要借助一些工具，如Excel，Xmind等。

解決方案階段：要清楚解決方案怎么設計？需要什么技能？

需求方向確定后就要為每個需求項設計解決方案，是戰術層面的事，這時你要根據公司的財力，物力，人力，緊迫程度等實際情況出方案。需要產品經理有：一定的大局觀，能考慮到后續功能的擴展；創新精神，設計出高大上方案；掌握 Axure，word， visio等工具。

開發上線階段：保持和開發團隊的溝通合作

這個階段主要是開發人員和測試人員的工作，產品經理要向項目經理反饋進度，配合運營，同時要解答開發過程中遇到的需求問題，從技術層面上多做一些了解，多站在開發人員的角度考慮一些問題，避免被技術“懟”。

數據分析階段：要認識到為什么要數據分析？

產品的第一個版一般情況下是不完善的，產品上線后要對用戶的反應快速做一些數據分析，對迭代產品的設計做一些指導和根據。

優化方案階段：要知道優化方案包括什么？

改Bug，擴大業務功能，增強功能，防風險，完善產品鏈，都屬于優化階段要做的事，目的是要提升之業務數據，用戶體驗，效率和收益。

2、用發展的思維思考產品

關于為什么要用發展的思維思考產品，我是這樣得出來的：設想在2000年的時空里去看當時的阿里，騰訊，在當時的市場情況下，阿里巴巴和騰訊開展的業務是不可取的，因為當時，電腦價格很貴，絕大多數家庭都沒有電腦，在電腦上去使用QQ，在網上買賣東西的群體很小，使用電腦的學習成本也比較高，也還沒有這個意識。 簡單說就是，沒有市場，沒有大量用戶，沒有這個意識，硬件成本高。

到06,07年的時候，大部分電腦價格在3千元左右，出現了很多電腦培訓學校幫人們提升了電腦使用的技能，很多家庭都擁有了電腦，相比02年的時候我堂哥花了7個月的工資才成為整個高中部第一個有電腦的老師，這種發展速度的確令人難以想象。

如果2000年時的阿里和騰訊不用發展的思維看產品，應該就沒有QQ，淘寶，支付寶，如果不看移動互聯網的發展趨勢，也就不會布局移動端的微信，支付寶。

社會總是在發展向前的，產品經理要解決時代需求，那就必須要用發展的眼光看產品。一味局限于目前的認識做產品，很容易會出現產品剛做出來，就已經被時代拋到了腦后。

3、保證產品形態與經濟學規律一致

用戶在經濟活動中面臨權衡取舍，產品是經濟活動中的載體，在產品選擇上，他們也會考慮使用成本和產品價值。

有人想過沒有：為什么在互聯網時代最早興起的是B2B模式，后來又發展到了B2C，O2O,后面會發展到C2C+O2O模式。

B2B興起時，電腦貴，只有企業有一定的經濟實力購買電腦，這是硬件和經濟共同決定的。 后來電腦在家庭普及，C端已經準備好了，用戶直接向供應商購買比經過多次轉手要便宜，因此B2C流行了。 再后來商店數量大量增加，而客戶數量總體不變，每個店的平均獲客量下降，O2O的模式可以在保證固定客人的情況下可以借助移動端/網絡拓寬獲客的渠道。 未來，機器人會代替部分勞動力，有一些勞動力密集型行業人員會失業，國家會鼓勵創業，這種創業不會是創立很多大企業，而是很多分工精細的個人企業，借助移動互聯網優勢，會出現C2C+O2O的混合模式，出現了滴滴拼車，滴滴順風車，一畝田，小豬短租及很多撮合一對一上門服務的產品。

產品設計的初衷都要求它能帶來一定的經濟效益，產品經理要確保產品和經濟發展相一致。

4、既要有用戶思維又要有主人翁的擔當

記得，剛接觸產品經理崗位時，會無意識根據自己的認知和經驗去設計產品。有一次設計Hotel 旅客資料填寫頁，由于不同房型的容納人數不一樣，一般情況下國內酒店每個房間填一個入住人就可以了，產品設計時，為節省移動端展示空間，每個房間都設計成只允許輸入一個入住人。當時覺得為用戶減少了輸入量，但是反饋效果卻不好，客人以為移動端的房間都只能入住一個人，反而影響了訂單量。 這就是沒有用戶思維導致的設計缺陷。所以做產品不能主觀武斷，而要結合用戶需求和公司戰略，做產品時一定要清楚用戶是誰？ 是否能解決用戶真實需求？

產品打磨的過程中，會遇到一些困難，產品經理是沖在最前面的人，他要為后續工作的開展排憂解難，以主人翁的擔當去主動推進和解決問題，保證產品順利出品。

5、創新Idea，強大產品

創新是產品經理手中最鋒利的刀，很多偉大的產品都有很多貼近實際的創新。

上家公司的產品，列表頁有大量的數據，滾動列表時，用戶老是不清楚目前查看的數據位置，本想借鑒其他APP的做法，發現別人也沒這功能。后來關聯想到：出低保真時，中繼器里的每條數據的展示高度是固定的，如果獲取到列表數據的Y值，除以單個展示框的高度向上取整，就可以知道當前數據是第幾條。按這個想法找開發了解了一下情況，技術上可行，就有了下圖這個功能。

團隊游產品的后臺頁面，有一個單張頁面，每點一次下一步就會生成一個單張，但是用戶對這個單張修改很頻繁，導致保存的單張很多，與用戶期望只保存一個單張數據不符，但是具體“保存哪一個”“什么時候保存”用戶也說不清。有人說強制保存第一個或者最后一個，也有人說指定XX賬戶操作時才保存……最后設計是這樣的：下一步時不保存單張，在下一步按鈕旁邊新增一個生成按鈕，允許操作一次，如果OP認為單張符合條件那就點生成保存這個單張到數據庫。

最近，我在網上看到篇文章，說QQ農場新增了看門狗的功能，這個時候有人說要新增打狗棒。但是后臺數據統計發現，只有2%的用戶使用了需要付費的看門狗，因此打狗棒的功能沒必要加。

我認為這樣不好玩，如果我是QQ農場的產品經理，我一定會加上打狗棒。我的思路如下：

1. 由于之前有很多因農場偷東西，導致一些朋友之間都鬧矛盾，那增加看門狗就是必要的；
2. 但看門狗需要付費，導致用戶少，但是需求還是有的；
3. 如果我設置看門狗免費，那么很多的農場主都會放置看門狗，這時偷菜的成本變大；
4. 偷菜不容易，這個時候可以添加打狗棒，打狗棒設置為收費服務，這種情況下的付費用戶絕對要大于2%。
5. 農場主買看門狗是防盜，買狗付錢會損失，不買狗農作物被偷了也是損失，他總是損失，何必買條狗多損失一些呢。
6. 打狗棒是服務偷菜者，對其來講打狗棒能保證偷到別人的農作物，打狗棒雖然付費，但可以幫助偷到更多的農作物，如果不買打狗棒我就偷到的農作物少，那也不好，于“小偷”來說總體是賺的，那么他會樂意買打狗棒。
7. 如果很多小偷都買了打狗棒，農場主在與小偷的博弈中又處于劣勢了，那我就設置賣不同的狗糧，有些狗糧需要錢，有些狗糧免費，狗吃了需要購買的狗糧則法力大增，能很好的保護農作物，吃免費狗糧的狗法力低，不能保護好所有的農作物。 在這樣一個互動的環節中，就無形的增加了趣味同時也增加了打狗棒的付費用戶。

關于產品創新，我一直相信，辦法總比困難多，只要多發散思維，多嘗試。

6、數據分析不僅僅是看數據

以前產品表現不佳時，產品經理只能靠猜，現在借助數據分析，能快速準確定位一些產品問題，對產品優化起指導作用，數據分析一定要透過表象看到本質問題。

16年11月份的時候，經理在會議上說“上個月系統是不是有問題？怎么因為訂單數量跟2015年同期相比增加幅度不大，10月份的訂單數據相比9月份環比減少”

從總數據來看，機票，酒店，度假訂單全線減少，從日均曲線來看，有連續幾天訂單數減少比較厲害，以前系統出問題時出現過這種曲線。先想到是系統問題，找運營同事是否有監控到系統報警，反饋那段時間沒報警記錄，也沒一級事故。后來想到了之前攜程網癱瘓導致我們調用攜程的接口全部不能用，看是否外部接口問題導致，但是新接口都是聯調了的，同時攜程內部郵件沒記錄有事件通報?？紤]外部因素時，猜想是競爭對手搞促銷活動導致，后來無意間看了下天氣，發現剛好那幾天有多個臺風影響香港，大量航班取消，停止營業，這才是導致訂單下降的根本原因。

后來我就意識到數據分析一定不能只看數據的表象，要深入研究每個指標，著眼大局，要考慮到天氣，地質災害，政治因素，戰爭，經濟下行壓力，節假日的分布，人群空閑度（寒暑假），競爭對手因素，使用習慣，是否有突發事件，匯率變動，潮流影響，系統問題，是否黑客攻擊，全球網絡癱瘓等等。

我現在開始寫一些文章，記錄一些體驗和心得，是因為最近意識到總結的重要性，好記性不如爛筆頭，同時也幫我理清自己的思路，有很多不足的地方，歡迎大家拍拍磚。

本文由 @飄雪的南方小城 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Pexels，基于 CC0 協議