狹義的使用者思維只聚焦在產品使用者這一個使用者視角，而PM應該擁有廣義的使用者思維，善於發現隱藏的所有使用者。本文從決策分析、需求分析、產品方案、產品開發、交付使用5個方面講述產品經理的“廣義使用者思維”。
使用者思維的概念，其實就是從使用者出發，關心使用者要什麼；然後企業/個人提供對應產品滿足使用者需求。
之所以倡導使用者思維，目的就是讓產品開發人員換位思考；用同理心感受使用者場景，最終能讓產品/服務更加貼近需求本質。
但是一個產品的面世過程，會有多人協作，且經歷非常多的環節才能完成，而每次溝通都有不同程度的資訊衰減。
一些人理解的使用者思維，更多是狹義的，只聚焦在產品使用者這一個使用者視角。而我卻認為PM更應該擁有廣義的使用者思維，善於發現隱藏的所有使用者。
開始正文之前，我先定義2個概念：
接下來，我會以業務中臺產品經理的視角，聊聊我所認為的“廣義使用者思維”。
為了便於大家理解，我們搭個框架，一次按照產品設計的關鍵環節逐一切入來看。
不同場景中，我會不斷代入以上2個概念，去問使用者是誰？使用者遇到的問題是什麼？
首先，第一環節是決策分析，也是最重要的一個環節。
對一些純使用者產品或B端商業化產品，市場/商業分析就屬於這個範疇。宏觀上會根據市場、公司戰略、資源、競爭等綜合資訊來判斷一個產品是否要做，如要做還要明確大框架上的一些體量、收益、資源投入等關鍵指標。
而對業務中臺（支撐類）產品經理，這個環節更多決策是某個業務需求要不要做，什麼時候做，投入資源如何。
這裡我們虛構一個案例，便於下文講解：
案例：業務A、業務B分別給我（業務中臺產品經理）提了【積分】功能和【優惠券】功能。
我接收到這個需求，第一步應該怎麼做，是直接跟他聊我們已經有這個功能？聊怎麼實現成本最小？聊我們資源排不上？
答案：都不是。
在這裡，我們首先明確下這個場景下的使用者和使用者遇到的問題：
看到以上表格，大家就發現了，其實我們面對的不僅僅是業務A和業務B這兩個使用者，其實還有公司和中臺部門這2個使用者，並且不同使用者之間是有優先順序的。
所以，最終我們想要很好解決掉這4個使用者的問題，必須先從整體上進行決策分析，而非直接去聊【積分】【優惠券】功能。
經過綜合分析，作為中颱產品經理，你應該首先依次確定以下問題：
針對以上問題的發問，我們稍微加工，可以得到以下資訊：
接下來，根據和業務的溝通協調，得到以下決策資訊：
提醒：資源有限和業務B優先順序低於A，這些客觀因素都可以讓中臺拒掉業務B的需求，但這只是60分的做法。而中臺去幫業務B想變通方案儘量滿足業務需求才是更高階的做法。
大家發現了麼？
中臺在這個角度，所做的事情就是收集全“使用者”問題並盡最大程度都解決掉，而決策分析其實就是獲取更多資訊得到最優解的過程。
以上決策分析環節，更多是從宏觀層面判斷一個需求做不做。在這個環節雖然也會有部分需求的溝通，但是顆粒度會粗很多。
而當決策一個需求確定要做之後，就會轉到需求分析環節，而這個環節就會深入去聊許多需求細節。
接下來，我們就繼續沿著上述案例往下拆解。
看看我們需求分析的物件是什麼？僅僅是【積分】的功能邏輯開發麼？
答案：不是的。
我們來看看此刻我們的使用者和使用者問題：
對於需求分析，一定不是直接切入到【積分】功能層面的溝通和設計，更多應該是找到所有相關的使用者，以及定位各個使用者的使用者問題。
在這個環節，不僅要跟直接業務去聊，同時還要去跟積分功能實現的所有上下游部門去溝通，聊資源、聊實現、聊協作。
總之，需求分析是產品主導深挖業務背後真正需求；進而確定各部分需求範圍、優先順序、需求時間節點等資訊的過程。
在這個過程中，有2個點兒需要特別說明下：
1） 優惠券功能屬於上游業務自助開發部分，中臺需要關心麼？
當然需要關心，你需要關心他們怎麼實現。怎麼去底層積分系統進行聯動，因為目標只有一個——就是讓業務B實現這個需求，進而實現業務目標；
2）風控、客服、資料跟中臺部門屬於平級關係，中臺需要關心麼？
當然也需要關心。因為某一塊的進度或者實現，都是影響業務需求最終可以被解決的變數，中臺有動力需要去推動這類問題的解決。
這裡插一句，在我自己現實的工作中，我也在嘗試推動《中臺間虛擬組織》的建立，力爭共同為業務提供【一攬子解決方案】，後續有實踐成果再跟大家分享。
在需求分析環節完畢之後，產品經理就會獲取到全量的業務層資訊並轉化為了需求list，接下來就會進入到比較詳細的產品方案階段。
在這個環節，產品經理的注意力會更多放在產品邏輯和頁面設計上，也就是一般產品經理“最擅長”的工作上。
在這裡，我不會闡述這個需求的產品方案細節該怎麼去寫，更多還是聚焦分析使用者和使用者問題：
在這個環節中，普通產品經理基本都能夠做到功能設計的完整度。而高水平的產品經理，應該要意識到，“產品方案”環節不僅是方案本身，更是連線上游業務需求和下游研發實現的核心中樞，就像一個漏斗一樣；這一層有衰減，就會使得最終的結果大打折扣。
所以產品經理在這個環節，表面是在畫互動和寫PRD，但是動滑鼠和鍵盤的每一刻，內心都要考慮以下問題：
可能有人會疑惑，難道畫每一個按鈕就需要考慮這麼多？
是的，產品的每一個互動和每一句文件描述，上邊羅列的各種使用者都是其受眾；他們的視角會care各自關心的內容，所以就需要產品經理具備這樣的方案能力。
同時滿足多個使用者的需求是產品經理需要修煉的能力。從小需求做起，保持同理心，日積月累，“使用者思維”就會變為自己的習慣。
產品方案需求評審之後，就會進入產品開發階段，在這個環節產品的“主導權”就會轉由技術GG們接手。
那麼在這個環節內，PM同學就可以撒手不管了麼？
答案：不是的。
雖然coding咱不會，但是咱要做的事情還是不少的，來看看這個環節的使用者和使用者問題：
中臺產品經理跟業務保持實時雙向溝通。對業務既要保持專案進度的實時反饋，管理好業務預期，哪怕遇到專案風險，及時的反饋溝通也能給予業務不太差的感受；另外還要保持對業務動態的瞭解，儘量降低需求變更的風險。
產品經理對研發團隊要做好答疑支援，不要需求一提交不管不問了，每一個“疑問”的忽視都會影響產品最終的質量。另外，產品經理要隔離掉上游業務其他人員對研發GG的“騷擾”，為其提供一個良好的coding環境。
還有，再說點老生常談的。專案過程中，要讓研發GG工作有幹勁，加班不抱怨，產品經理一定要發揮程式設計師鼓勵師的作用。噓寒問暖不能少，破費買吃的喝的“孝敬”一下效果更佳喲，哈哈！
產品開發環節完成之後，就到交付使用了。
同樣，我們看下這個節點我們需要關注哪些使用者和哪些使用者問題：
寫操作說明和產品培訓屬於常規操作了，不再贅述。
這裡面著重聊一個容易被產品經理忽視的或者做的不太夠的點——發上線郵件。
在這裡，我們也用下使用者思維，看看上線郵件應該怎麼寫：
專案上線是專案的重要里程碑，發上線郵件是儀式感的體現，所有的人都希望自己的付出被認可、被讚美。
對於比較大型專案，團隊比較辛苦，產品經理組織個飯局犒勞下技術GG們是非常有必要的。哈哈！
另外，上線一段時間後，例如2周。產品經理一定要及時找業務童鞋要對應的產品效果反饋，進而對專案組成員進行同步。如果業務同學能有階段化運營成果彙報，讓專案成員參與也會起到很好的效果。
總之，任何的付出都希望有迴音，哪怕是專案上線效果不好，至少也是一種反饋。
以上分析，我們是代入進了一個具體的專案，其實迴歸到每個人的崗位工作，也同樣適用使用者思維。
白話來說，就是在這個協作合作的過程中，每個使用者各自的核心訴求是什麼：
產品經理作為業務和研發資源的轉化紐帶，本身的水準直接決定了資源變為業務助力的轉化率。
一個好的產品經理，給人的直觀感受就是能解決“各類使用者”的“各類問題”，不僅僅是專案本身。
我一直信奉一句話：最高階的利己是利他。
“使用者思維”其實沒那麼難，無非就是多為他人真誠地著想。
作者：減形簡遠，微信公眾號：產品雜談（life_pm）
本文由@減形簡遠 原創釋出於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。