起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識從微信的冷門服務，看產品如何尊重用戶
優秀的產品經理要具有人文關懷，而不是一切以數據為導向。明確角色是誰？體驗流程的繁瑣程度如何？改變其中一點，也許就能讓用戶呈指數級增長。
“如果你根本不知道自己在討論什么，那么對其強求精確是毫無意義的?！?/p>
——馮諾依曼
在紛蕪中梳理需求，判斷取舍，對一位產品經理而言，有時比最后的交付更有價值。
一、? 需求分析：場景浸入式思考
“需求分析”的定義：試圖發現用戶期望的東西的過程，所以我們用“產品”去表示那些試圖滿足用戶“復合的、一系列期望”的產物。
在我看來，需求分析是初、中級產品經理最重要的一項基本素質。
借鑒查理芒格的思維方法，如果你不確定一個需求的真偽，那么就去窮舉一萬個idea去證明它的不可實現性：
- 為什么TA有這個痛點？
- 這是TA的真實想法么？
- 如果我不做，TA能否忍受現狀？
- 如果我做了，TA一定會使用這個產品么？
- …
需求分析的方法論很多，浸入場景式思考，我認為是很關鍵的一項，且以港版微信為例，說明“場景化”的代入感，對于抓住用戶痛點的重要意義。
案例分享：港版微信新服務We Remit，支持菲傭匯款
移動支付的便利在這一刻發揮了重要的功用，通過We Remit，幫助數以萬計的菲傭解決最真實、最切身的需求。
她們身上有眾多標簽：中英文水平低、收入低、文化水平低、非互聯網用戶、薪水低…
并且非常關注匯款通道的安全性、速度、資金安全，根深蒂固的觀念是寧可騰出一下午時間也要堅持去銀行匯款給在國內的家人。
我佩服微信團隊的這項設計，透過背后折射出的是一種對用戶的關懷。將自己擺在用戶立場上去想：
- 我需要雇主給我提供更靈活的工作時間方便我去匯款么？
- 我需要更便捷的交通線路通往銀行么，比如更快的巴士？
- 我需要銀行更快的排隊-接待-填寫匯款單-轉賬-確認到賬的服務么？
…Nein！
對此，微信給出的思路是——“匯款直通車”。
在demo完成后，團隊又去實地做可用性測試，觀察用戶對MVP產品的接受程度，及真實場景下的使用情況，從而去優化流程和交互。
“浸入式”思考讓產品設計者去深入探索用戶想要的是什么，MVP輸出后還要看用戶的切換成本有多高。
同理還有淘寶的圖片找商品，這是“搜索”的一大進步。對象在七浦路市場淘到一件寶貝，怕老板亂報價，需要去淘寶確認下價格，拍照-圖片搜索-找到SKU-查詢價格即可，整個流程對于慣用淘寶的妹子而言，非常輕松，而這一項設計也是很巧妙。
如果大家去一個陌生理發店剪頭發，會發現鏡子旁有13英寸左右的led廣告屏，輪播著廣告、電影短片、歌曲mv、旅游節目等，這樣避免了我們在疲憊、心情煩躁、內向害羞等情況下，不得不與理發師尬聊的處境。
思考場景化，是對用戶的尊重。
二、尊重個體人，即使TA不是你的用戶
優秀的產品經理，多半是個感性、悲天憫人的人，而不是一切惟商業價值為導向的冷冰冰設計者。
TA不必深諳心理學，不必會講故事，但必須懂得尊重人，懂得與隊友、用戶和陌生人進行“非暴力溝通”。
摒棄你心中的功利主義，只有這樣，你才能突破自己的枷鎖。
明確角色是誰？體驗流程的繁瑣程度如何？他們心中不快卻又不愿說出來的“隱疾”。改變其中一點，也許就能帶來指數級的增長。
且看真實的2個例子：
1. 體諒年老的用戶
春節過年回家，看到長輩也能熟練使用微信，字體的擴大，方便了老人閱讀。微信的老年用戶月活超過5000萬，極為克制的微信沒有再去壓縮用戶路徑，而是將通過視覺和交互設計優化，體現了對老人的尊重與關心。
同理還有滴滴司機版的大按鈕，輔以暖暖的橙色，方便中老年司機去觸碰，在車不熄火，在深夜光線不好時，安全有時超過便利。
最貼近生活的就是：交規規定機動車必須避讓斑馬線上的行人，汽車的前包圍使用塑料而非鋁合金等，也是為了保護行人。
2. 體諒非互聯網用戶
筆者的小舅是名英文0基礎的軍人，喜歡跟外聘專家——一位美國老外，討論政治、槍支等話題，而微信的翻譯功能則提供了一個良好的契機。
雖然時隔13小時的時差，但微信通過精確的實時翻譯給兩位跨國好友提供了一座溝通順暢的橋梁，有時候，對于一位學歷不高的非互聯網用戶而言，這是很溫馨和實用的。
三、需求明晰在產品交付中的重要意義
1.敷衍需求，你的產品就沒有生命
作為產品經理，那就是產品的owner，要知道自己做什么，而不是被動得去“接收需求”.我見過不少產品經理都是被老板or領導牽著鼻子走，淪為“產品助理”，失去了自己的靈魂，與扯線木偶有何兩異？在自我懷疑中不斷沉淪，最終也是曲終人散。
這樣的你，不是PM，而是產品總監高級助理（畫圖，出文檔，跟開發掰手腕…）
2.? 追求效率，還是交付質量？
兩者的極端，就是scrum開發流程（快）與漫長審批流（慢）的錯誤理解與應用。
很多創業公司會快速試錯，每磨出一款MVP產品，就更換一位產品。為了追求快，我們輕評審重開發，看起來是“摸著石頭過河”，其實這種方法蘊含了很大風險，既白白浪費開發資源，亦加劇團隊動蕩。
我們都知道：需求的更迭如果發生在立項早期，代價最小，而在測試驗收前夕，則可能給整個team帶來災難性的影響。
也許你會問，如果評審本身就很敷衍和粗糙，仍然要堅持開發么？
“如果你根本不知道自己在討論什么，那么對其強求精確是毫無意義的?！?/p>
——馮諾依曼
所以，請立即回到原點，好好梳理下需求，決定做不做比做什么更重要。
須知：在不同階段，變更需求對開發進度和交付質量的影響各不一樣，在需求分析和梳理階段，能以最小的代價穩定開發進度和交付質量。
筆者見過在UAT驗收時，業務方需求再次變更，雖然最終強行上線，但開發撥出了3天的時間來debug，這一切都與需求立項階段，需求方含糊其詞，而產品經理也并未深究到底，給開發同學挖了深坑。前述案例發生前后如下：
背景：XXX公司財務系統開發前中期
Java：收付款后需要財務審批么？還是僅作“確認”？PRD里這段沒有寫清楚哦。
PM：這個我也不知道，你先做吧，我還要去問下業務。
Java：…這伙計到底是不是專業的料?。?？？
像這樣坑開發的案例，相信大家都遇到過。1，還是0，在給開發同學的PRD里必須明確，否則本模塊不可用，還會影響后置流程的設計。
四、結語
好的產品經理疏導需求，有理有節地“分+析”，明確哪些可以暫時放下，哪些暫時功用低但對后面的規劃有重要作用。
產品不是功能的堆砌，大家公認產品也是有生命周期的，也許少折騰，把自己的想法克制住，對于產品的成長更為重要吧。
本文由 @ Guardian丶 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基于 CC0 協議
- 目前還沒評論，等你發揮！
