起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識當收到用戶新需求或吐槽，怎么開始進行產品優化改造？
收到了用戶的需求，但是要怎么開始做的？怎么開始設計呢？或許本文可以給你借鑒的方法，enjoy~
部門最近新入一個產品實習生，完全小白一只，沒有任何的設計經驗。
放假前一天，她很苦惱地說：“我知道她的問題是什么，但是我不知道怎么開始設計……”
很多人剛開始做產品的時候，可能也會遇到這樣的問題。收到了用戶的需求，但是要怎么開始做的？怎么開始設計呢？剛開始的切入可能會非常的困擾和艱難。
那么，今天我要分享的是，“當收到客戶需求或吐槽以后，怎么開始進行產品優化改造？”
獲得新需求開始設計的過程中，需要幾個關鍵步驟：
- 了解你的系統，熟悉產品所有流程和細節
- 明確用戶痛點，了解“需求”背后的真是原因；
- 分析你的產品，看產品當前是哪里有缺陷或需要更改；
- 設計你的方案，檢驗用戶需求是否得解決。
第一關鍵步驟：了解你的系統，熟悉產品所有流程和細節
作為產品經理，你應該比所有人更熟悉你的系統。作為一名產品小白，最基本的要求就是快速、全面熟悉你的產品。你得理解產品當前所有的現狀，如果有可能，了解到每個功能背后的“故事”。
怎樣才能快速熟悉系統？親手整理系統的每個功能模塊，自己親身體驗系統的每個功能特性。把你對系統的理解，整理成為像“功能說明書”。找到團隊的相關人員，像他們了解你所疑惑的每個問題的背后故事，這些故事能幫你更全面、深入了解產品現狀以及為什么是這樣。
怎么評估算熟悉一個系統？當用戶提出一個需求，你能馬上判斷出來是哪個功能模塊解決，或者什么樣的組合方案解決，那么恭喜你，你已經了解產品的全部。
當然，很多產品小細節可能你會逐漸才發現，但是產品的主體框架、流程、模塊/功能需要快速了解。只有對產品有熟悉度，你才能更有效跟用戶進行需求溝通。這將會幫你做需求的最初始評估，客戶需求當前系統能滿足嗎？哪里不滿足？
第二關鍵步驟：明確用戶痛點，了解“需求”背后的真實原因
帶著對系統的理解，你可能開始跟用戶進行溝通他遇到的問題或需求。究竟什么是“用戶需求？用戶痛點” 用戶對你描述的就是他想要的嗎？
用一個老生常談的例子，老板對你說，“給我一杯水”，“水”是老板現在的需求嗎？
如果這時候不去探究他為什么要這杯水，那么你可能會再遇到以下幾種情況：
（1）給了老板一杯熱水（內心獨白：喝熱水好，你覺得老板肯定覺得很暖心）~
結果怎樣，老板大發雷霆，給我熱水干什么，你想熱死我啊… 這時候你才發現，老板大汗淋漓，他可能是太熱了~
這時候如果你換為的解決方案是“把老板空調打開，給他一杯涼開水，再備上一杯冰飲” 老板可能會對你刮目相看~
（2）給了老板一杯熱茶（內心獨白：平時老板都喝茶，他肯定需要喝茶了）~
結果，老板說你豬腦子啊，用熱茶我怎么能澆花… 澆花?。?！ 你不知道，老板最近迷上綠植，讓你給他水，實際上是要給綠植澆水…
這時候，你如果跟老板交流一下養花心得，白天澆水不是最佳時機，晚上澆水對綠植最好，然后告訴老板說，我先接杯水，放半天，晚上給他帶過來，還能去除水中的氯氣，老板肯定會對你贊不絕口。
這是一個非常經典的案例，老板對你發出的是，是明確的指令，是他給出的一個解決方案。老板為什么要這杯水？他真實背后的需求痛點是什么？這才是我們需要去探索明確的。如果用戶實際的痛點不明確，你可能會頻繁被對方KO，你做的解決方案可能會被對方改來改去。
用戶常常覺得他就知道什么方案是最好的，因此他跟你溝通的時候會直接告訴你他想要的解決方案。因此，在和用戶溝通的時候，你會發現對方已經直接幫你做好設計了，他已經跟你說了需要加什么功能，哪里需要改成什么。如果客戶對你描述的已經是跟產品功能特性相關的內容，那么他已經在描述自己的解決方案了。
如果遇到上面的客戶，你就得多問問他實際要解決什么問題？有一種快速的方法是，追問客戶，他為什么要？解決了他什么問題？如果系統按他的提議做了，那么他的工作會有什么變化？
用戶的解決方案是從他的認知范圍提供出來的，作為產品經理的我們，可能會為他的痛點提出更好更合理的方案建議。因此，了解到客戶提出的“需求”的背后更真實的原因，通常能讓我們更好提出系統優化方案。
第三步驟：分析你的產品，看產品當前是哪里有缺陷或需要更改
通過第二個步驟，你已經非常明確當前客戶的需求痛點，并跟你的團隊確認了本期需要解決的關鍵問題是什么？那么，你需要確定本期改造的目標，也就是系統將改造成什么樣來滿足用戶什么痛點。
通常，你可以用這樣的文案結構來描述你的目標：
“本期我們希望通過提供什么的特性，幫助什么樣的人，解決什么樣的問題”
確定好目標以后，你需要重新分析你的產品。這一次的分析跟第一個環節的分析目標不一樣，主要目的是為了了解，系統當前究竟哪些環節、哪些模塊有問題影響了用戶需求的滿足。因此，你需要去重新整理系統，將不滿足的環節或功能模塊標記出來。
這意味著，為了解決用戶本期的需求，我們需要在這些有問題的點上做改造。
第四步驟：設計你的方案，檢驗用戶需求是否得解決
找到了影響點，產品經理最能發揮效用的一個環節出來，你需要開始設計你的解決方案。在原來的環節中。需要怎樣改造？
如果是產品的流程有問題，可能你改造的是系統的流程；如果是之前的規則有問題，可能你改造的僅僅是個簡單的規則；如果只是原因功能的缺失，可能你設計的就是一個新特性。
根據不同問題的分析結構決定了最終我們的設計方案，因此方案可能有大有小，可能有的方案就是一個線下行為，告訴用戶怎么用即可，并不一定體現在我們的系統。
那么，對于我的方案究竟是否OK，怎么來檢驗呢？這樣又回到了我們的第二個分析環節，用戶實際痛點。你可以假設自己的產品已經按照自己的設計實現，那么實現以后用戶提到的問題解決了嗎？如果能夠解決，那么恭喜你，你的設計方案最起碼從用戶的場景出發已經滿足了。
當然，一個設計方案是否最終OK，除了用戶的需求滿足了，還有很多其他的考慮點，比如，技術可行性，時間成本，人力成本，而其他這些影響因素是小白需要在做好方案跟團隊相關人員去討論溝通的。
很多小白可能覺得，如果不多增加一點功能，或者不改點交互，那么我做的是什么呢？在我們部門的小白本期負責的改造中，其實她不需要動任何的流程和步驟，改造的可能僅僅是換一個極其微小的“規則”，這個規則對于界面來說，可能沒有任何改變。所以她很心虛，覺得我做了什么呢？就這樣ok了嗎？實際上，用戶需求的解決很可能就是這么小，小到很多人看不到，但這就是一種最簡單的方案。
小結
當收到用戶需求以后，你需要做的是：
1）反思你理解系統嗎？
2）追問用戶真實的痛點和他想解決的問題；
3）分析系統中有什么不滿足的點，或者需要在哪些點上改造才能實現目標；
4）針對不滿足的系統流程或功能進行改造或新設計，然后來檢驗是否改造方案能解決用戶痛點。
本文由 @lieut 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Pixabay，基于 CC0 協議
受用啦
追問用戶痛點的例子舉得通俗易懂。
不得不說是教科書級的！幫助極其大！
逼格可以啊
受教了，對于我們這些小白來講，通俗易懂又受用，謝謝啦