優(yōu)秀的產品經(jīng)理要具有人文關懷，而不是一切以數(shù)據(jù)為導向。明確角色是誰？體驗流程的繁瑣程度如何？改變其中一點，也許就能讓用戶呈指數(shù)級增長。

“如果你根本不知道自己在討論什么，那么對其強求精確是毫無意義的?！?/p>

——馮諾依曼

在紛蕪中梳理需求，判斷取舍，對一位產品經(jīng)理而言，有時比最后的交付更有價值。

一、? 需求分析：場景浸入式思考

“需求分析”的定義：試圖發(fā)現(xiàn)用戶期望的東西的過程，所以我們用“產品”去表示那些試圖滿足用戶“復合的、一系列期望”的產物。

在我看來，需求分析是初、中級產品經(jīng)理最重要的一項基本素質。

借鑒查理芒格的思維方法，如果你不確定一個需求的真?zhèn)危敲淳腿ジF舉一萬個idea去證明它的不可實現(xiàn)性：

• 為什么TA有這個痛點？
• 這是TA的真實想法么？
• 如果我不做，TA能否忍受現(xiàn)狀？
• 如果我做了，TA一定會使用這個產品么？
• …

需求分析的方法論很多，浸入場景式思考，我認為是很關鍵的一項，且以港版微信為例，說明“場景化”的代入感，對于抓住用戶痛點的重要意義。

案例分享：港版微信新服務We Remit，支持菲傭匯款

移動支付的便利在這一刻發(fā)揮了重要的功用，通過We Remit，幫助數(shù)以萬計的菲傭解決最真實、最切身的需求。

她們身上有眾多標簽：中英文水平低、收入低、文化水平低、非互聯(lián)網(wǎng)用戶、薪水低…

并且非常關注匯款通道的安全性、速度、資金安全，根深蒂固的觀念是寧可騰出一下午時間也要堅持去銀行匯款給在國內的家人。

我佩服微信團隊的這項設計，透過背后折射出的是一種對用戶的關懷。將自己擺在用戶立場上去想：

• 我需要雇主給我提供更靈活的工作時間方便我去匯款么？
• 我需要更便捷的交通線路通往銀行么，比如更快的巴士？
• 我需要銀行更快的排隊-接待-填寫匯款單-轉賬-確認到賬的服務么？

…Nein！

對此，微信給出的思路是——“匯款直通車”。

在demo完成后，團隊又去實地做可用性測試，觀察用戶對MVP產品的接受程度，及真實場景下的使用情況，從而去優(yōu)化流程和交互。

“浸入式”思考讓產品設計者去深入探索用戶想要的是什么，MVP輸出后還要看用戶的切換成本有多高。

同理還有淘寶的圖片找商品，這是“搜索”的一大進步。對象在七浦路市場淘到一件寶貝，怕老板亂報價，需要去淘寶確認下價格，拍照-圖片搜索-找到SKU-查詢價格即可，整個流程對于慣用淘寶的妹子而言，非常輕松，而這一項設計也是很巧妙。

如果大家去一個陌生理發(fā)店剪頭發(fā)，會發(fā)現(xiàn)鏡子旁有13英寸左右的led廣告屏，輪播著廣告、電影短片、歌曲mv、旅游節(jié)目等，這樣避免了我們在疲憊、心情煩躁、內向害羞等情況下，不得不與理發(fā)師尬聊的處境。

思考場景化，是對用戶的尊重。

二、尊重個體人，即使TA不是你的用戶

優(yōu)秀的產品經(jīng)理，多半是個感性、悲天憫人的人，而不是一切惟商業(yè)價值為導向的冷冰冰設計者。

TA不必深諳心理學，不必會講故事，但必須懂得尊重人，懂得與隊友、用戶和陌生人進行“非暴力溝通”。

摒棄你心中的功利主義，只有這樣，你才能突破自己的枷鎖。

明確角色是誰？體驗流程的繁瑣程度如何？他們心中不快卻又不愿說出來的“隱疾”。改變其中一點，也許就能帶來指數(shù)級的增長。

且看真實的2個例子：

1. 體諒年老的用戶

春節(jié)過年回家，看到長輩也能熟練使用微信，字體的擴大，方便了老人閱讀。微信的老年用戶月活超過5000萬，極為克制的微信沒有再去壓縮用戶路徑，而是將通過視覺和交互設計優(yōu)化，體現(xiàn)了對老人的尊重與關心。

同理還有滴滴司機版的大按鈕，輔以暖暖的橙色，方便中老年司機去觸碰，在車不熄火，在深夜光線不好時，安全有時超過便利。

最貼近生活的就是：交規(guī)規(guī)定機動車必須避讓斑馬線上的行人，汽車的前包圍使用塑料而非鋁合金等，也是為了保護行人。

2. 體諒非互聯(lián)網(wǎng)用戶

筆者的小舅是名英文0基礎的軍人，喜歡跟外聘專家——一位美國老外，討論政治、槍支等話題，而微信的翻譯功能則提供了一個良好的契機。

雖然時隔13小時的時差，但微信通過精確的實時翻譯給兩位跨國好友提供了一座溝通順暢的橋梁，有時候，對于一位學歷不高的非互聯(lián)網(wǎng)用戶而言，這是很溫馨和實用的。

三、需求明晰在產品交付中的重要意義

1.敷衍需求，你的產品就沒有生命

作為產品經(jīng)理，那就是產品的owner，要知道自己做什么，而不是被動得去“接收需求”.我見過不少產品經(jīng)理都是被老板or領導牽著鼻子走，淪為“產品助理”，失去了自己的靈魂，與扯線木偶有何兩異？在自我懷疑中不斷沉淪，最終也是曲終人散。

這樣的你，不是PM，而是產品總監(jiān)高級助理（畫圖，出文檔，跟開發(fā)掰手腕…）

2.? 追求效率，還是交付質量？

兩者的極端，就是scrum開發(fā)流程（快）與漫長審批流（慢）的錯誤理解與應用。

很多創(chuàng)業(yè)公司會快速試錯，每磨出一款MVP產品，就更換一位產品。為了追求快，我們輕評審重開發(fā)，看起來是“摸著石頭過河”，其實這種方法蘊含了很大風險，既白白浪費開發(fā)資源，亦加劇團隊動蕩。

我們都知道：需求的更迭如果發(fā)生在立項早期，代價最小，而在測試驗收前夕，則可能給整個team帶來災難性的影響。

也許你會問，如果評審本身就很敷衍和粗糙，仍然要堅持開發(fā)么？

“如果你根本不知道自己在討論什么，那么對其強求精確是毫無意義的?！?/p>

——馮諾依曼

所以，請立即回到原點，好好梳理下需求，決定做不做比做什么更重要。

須知：在不同階段，變更需求對開發(fā)進度和交付質量的影響各不一樣，在需求分析和梳理階段，能以最小的代價穩(wěn)定開發(fā)進度和交付質量。

筆者見過在UAT驗收時，業(yè)務方需求再次變更，雖然最終強行上線，但開發(fā)撥出了3天的時間來debug，這一切都與需求立項階段，需求方含糊其詞，而產品經(jīng)理也并未深究到底，給開發(fā)同學挖了深坑。前述案例發(fā)生前后如下：

背景：XXX公司財務系統(tǒng)開發(fā)前中期

Java：收付款后需要財務審批么？還是僅作“確認”？PRD里這段沒有寫清楚哦。

PM：這個我也不知道，你先做吧，我還要去問下業(yè)務。

Java：…這伙計到底是不是專業(yè)的料??？？？

像這樣坑開發(fā)的案例，相信大家都遇到過。1，還是0，在給開發(fā)同學的PRD里必須明確，否則本模塊不可用，還會影響后置流程的設計。

四、結語

好的產品經(jīng)理疏導需求，有理有節(jié)地“分+析”，明確哪些可以暫時放下，哪些暫時功用低但對后面的規(guī)劃有重要作用。

產品不是功能的堆砌，大家公認產品也是有生命周期的，也許少折騰，把自己的想法克制住，對于產品的成長更為重要吧。

本文由 @ Guardian丶 原創(chuàng)發(fā)布于人人都是產品經(jīng)理。未經(jīng)許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協(xié)議