狹義的用戶思維只聚焦在產(chǎn)品使用者這一個用戶視角，而PM應該擁有廣義的用戶思維，善于發(fā)現(xiàn)隱藏的所有用戶。本文從決策分析、需求分析、產(chǎn)品方案、產(chǎn)品開發(fā)、交付使用5個方面講述產(chǎn)品經(jīng)理的“廣義用戶思維”。

用戶思維的概念，其實就是從用戶出發(fā)，關心用戶要什么；然后企業(yè)/個人提供對應產(chǎn)品滿足用戶需求。

之所以倡導用戶思維，目的就是讓產(chǎn)品開發(fā)人員換位思考；用同理心感受用戶場景，最終能讓產(chǎn)品/服務更加貼近需求本質(zhì)。

但是一個產(chǎn)品的面世過程，會有多人協(xié)作，且經(jīng)歷非常多的環(huán)節(jié)才能完成，而每次溝通都有不同程度的信息衰減。

一些人理解的用戶思維，更多是狹義的，只聚焦在產(chǎn)品使用者這一個用戶視角。而我卻認為PM更應該擁有廣義的用戶思維，善于發(fā)現(xiàn)隱藏的所有用戶。

開始正文之前，我先定義2個概念：

1. 用戶：產(chǎn)品經(jīng)理溝通/反饋/交付的對象；
2. 用戶問題：用戶的原始需求/利益訴求/關注點。

接下來，我會以業(yè)務中臺產(chǎn)品經(jīng)理的視角，聊聊我所認為的“廣義用戶思維”。

為了便于大家理解，我們搭個框架，一次按照產(chǎn)品設計的關鍵環(huán)節(jié)逐一切入來看。

不同場景中，我會不斷代入以上2個概念，去問用戶是誰？用戶遇到的問題是什么？

一、決策分析（判斷信息）

首先，第一環(huán)節(jié)是決策分析，也是最重要的一個環(huán)節(jié)。

對一些純用戶產(chǎn)品或B端商業(yè)化產(chǎn)品，市場/商業(yè)分析就屬于這個范疇。宏觀上會根據(jù)市場、公司戰(zhàn)略、資源、競爭等綜合信息來判斷一個產(chǎn)品是否要做，如要做還要明確大框架上的一些體量、收益、資源投入等關鍵指標。

而對業(yè)務中臺（支撐類）產(chǎn)品經(jīng)理，這個環(huán)節(jié)更多決策是某個業(yè)務需求要不要做，什么時候做，投入資源如何。

這里我們虛構(gòu)一個案例，便于下文講解：

案例：業(yè)務A、業(yè)務B分別給我（業(yè)務中臺產(chǎn)品經(jīng)理）提了【積分】功能和【優(yōu)惠券】功能。

我接收到這個需求，第一步應該怎么做，是直接跟他聊我們已經(jīng)有這個功能？聊怎么實現(xiàn)成本最??？聊我們資源排不上？

答案：都不是。

在這里，我們首先明確下這個場景下的用戶和用戶遇到的問題：

看到以上表格，大家就發(fā)現(xiàn)了，其實我們面對的不僅僅是業(yè)務A和業(yè)務B這兩個用戶，其實還有公司和中臺部門這2個用戶，并且不同用戶之間是有優(yōu)先級的。

所以，最終我們想要很好解決掉這4個用戶的問題，必須先從整體上進行決策分析，而非直接去聊【積分】【優(yōu)惠券】功能。

經(jīng)過綜合分析，作為中臺產(chǎn)品經(jīng)理，你應該首先依次確定以下問題：

• 公司戰(zhàn)略層面，業(yè)務A和業(yè)務B本身處于何種位置？
• 業(yè)務A想要的【積分】功能，背后要解決的業(yè)務問題究竟是什么？這個功能對業(yè)務本身助力如何？功能如果不能實現(xiàn)是否有其他替代方案？這個需求在業(yè)務層面的時間預期是？
• 業(yè)務B想要的【優(yōu)惠券】功能，背后要解決的業(yè)務問題究竟是什么？這個功能對業(yè)務本身助力如何？功能如果不能實現(xiàn)是否有其他替代方案？這個需求在業(yè)務層面的時間預期是？
• 假如最終確定想要解決業(yè)務A、B的問題，需要支持，那么【積分】【優(yōu)惠券】功能在中臺大概開發(fā)周期如何？在現(xiàn)有項目安排基礎上，如果排上，預計是什么節(jié)點開始和結(jié)束？功能是否必須中臺開發(fā)，業(yè)務是否可有自主開發(fā)的可能性？功能在中臺角度，預判后續(xù)會有其他更多業(yè)務會用到嗎？

針對以上問題的發(fā)問，我們稍微加工，可以得到以下信息：

• 公司層面：中臺需要優(yōu)先保證業(yè)務A的需求實現(xiàn)；
• 業(yè)務層面：業(yè)務A的【積分】功能，根本需求是需要一種抓手，將一定的預算，轉(zhuǎn)化為可以提升用戶的平臺粘性（登陸、瀏覽、關注店鋪等）；業(yè)務B的【優(yōu)惠券】功能，根本需求是想要一種抓手，將一定的預算，轉(zhuǎn)化為可提升平臺用戶的轉(zhuǎn)化率（下單支付）；業(yè)務A和業(yè)務B對功能的實現(xiàn)預期都是在未來一個月內(nèi)，時間上存在沖突；
• 中臺資源：在未來的一個月內(nèi)，資源有限，只能支持一個項目；
• 中臺對需求實現(xiàn)的分析：【積分】功能和【優(yōu)惠券】功能都具備最重要的共同特征：私有化憑據(jù)和流通閉環(huán)；而最大的差異性是：積分類型不能針對購買對象進行使用限制但可零散化核銷（例如一次消耗5個積分或100個積分），而優(yōu)惠券類型可以針對購買對象進行使用限制但必須整券核銷（一張要么核銷要么不核銷，不存在半張券核銷）；
• 中臺已有功能：具備【秒殺促銷】功能，已實現(xiàn)促銷資金預算化、訂單特定減額的邏輯功能，整體實現(xiàn)【積分】【優(yōu)惠券】等減額類運算有一定的框架基礎。

接下來，根據(jù)和業(yè)務的溝通協(xié)調(diào)，得到以下決策信息：

• 中臺未來一個月內(nèi)開發(fā)交付【積分】功能，且會按saas化搭建框架（不同業(yè)務可以配置平行多套積分體系，互不干預）；——后續(xù)可擴展，中臺既支持了需求，也沉淀了中臺能力，可以被后續(xù)類似業(yè)務場景拓展使用；
• 業(yè)務A直接使用中臺【積分】功能，無需多余開發(fā)；——需求解決了；
• 業(yè)務B自己在應用層做【優(yōu)惠券】化包裝，但底層復用中臺【積分】功能；——業(yè)務只需要少量開發(fā)，80%可以復用積分功能，需求也一定程度被解決了。

提醒：資源有限和業(yè)務B優(yōu)先級低于A，這些客觀因素都可以讓中臺拒掉業(yè)務B的需求，但這只是60分的做法。而中臺去幫業(yè)務B想變通方案盡量滿足業(yè)務需求才是更高級的做法。

大家發(fā)現(xiàn)了么？

中臺在這個角度，所做的事情就是收集全“用戶”問題并盡最大程度都解決掉，而決策分析其實就是獲取更多信息得到最優(yōu)解的過程。

二、需求分析（收集&分析信息）

以上決策分析環(huán)節(jié)，更多是從宏觀層面判斷一個需求做不做。在這個環(huán)節(jié)雖然也會有部分需求的溝通，但是顆粒度會粗很多。

而當決策一個需求確定要做之后，就會轉(zhuǎn)到需求分析環(huán)節(jié)，而這個環(huán)節(jié)就會深入去聊許多需求細節(jié)。

接下來，我們就繼續(xù)沿著上述案例往下拆解。

看看我們需求分析的對象是什么？僅僅是【積分】的功能邏輯開發(fā)么？

答案：不是的。

我們來看看此刻我們的用戶和用戶問題：

對于需求分析，一定不是直接切入到【積分】功能層面的溝通和設計，更多應該是找到所有相關的用戶，以及定位各個用戶的用戶問題。

在這個環(huán)節(jié)，不僅要跟直接業(yè)務去聊，同時還要去跟積分功能實現(xiàn)的所有上下游部門去溝通，聊資源、聊實現(xiàn)、聊協(xié)作。

總之，需求分析是產(chǎn)品主導深挖業(yè)務背后真正需求；進而確定各部分需求范圍、優(yōu)先級、需求時間節(jié)點等信息的過程。

在這個過程中，有2個點兒需要特別說明下：

1） 優(yōu)惠券功能屬于上游業(yè)務自助開發(fā)部分，中臺需要關心么？

當然需要關心，你需要關心他們怎么實現(xiàn)。怎么去底層積分系統(tǒng)進行聯(lián)動，因為目標只有一個——就是讓業(yè)務B實現(xiàn)這個需求，進而實現(xiàn)業(yè)務目標；

2）風控、客服、數(shù)據(jù)跟中臺部門屬于平級關系，中臺需要關心么？

當然也需要關心。因為某一塊的進度或者實現(xiàn)，都是影響業(yè)務需求最終可以被解決的變量，中臺有動力需要去推動這類問題的解決。

這里插一句，在我自己現(xiàn)實的工作中，我也在嘗試推動《中臺間虛擬組織》的建立，力爭共同為業(yè)務提供【一攬子解決方案】，后續(xù)有實踐成果再跟大家分享。

三、產(chǎn)品方案（信息加工）

在需求分析環(huán)節(jié)完畢之后，產(chǎn)品經(jīng)理就會獲取到全量的業(yè)務層信息并轉(zhuǎn)化為了需求list，接下來就會進入到比較詳細的產(chǎn)品方案階段。

在這個環(huán)節(jié)，產(chǎn)品經(jīng)理的注意力會更多放在產(chǎn)品邏輯和頁面設計上，也就是一般產(chǎn)品經(jīng)理“最擅長”的工作上。

在這里，我不會闡述這個需求的產(chǎn)品方案細節(jié)該怎么去寫，更多還是聚焦分析用戶和用戶問題：

在這個環(huán)節(jié)中，普通產(chǎn)品經(jīng)理基本都能夠做到功能設計的完整度。而高水平的產(chǎn)品經(jīng)理，應該要意識到，“產(chǎn)品方案”環(huán)節(jié)不僅是方案本身，更是連接上游業(yè)務需求和下游研發(fā)實現(xiàn)的核心中樞，就像一個漏斗一樣；這一層有衰減，就會使得最終的結(jié)果大打折扣。

所以產(chǎn)品經(jīng)理在這個環(huán)節(jié)，表面是在畫交互和寫PRD，但是動鼠標和鍵盤的每一刻，內(nèi)心都要考慮以下問題：

• 這個功能，業(yè)務預期中的用戶使用是否ok？
• 這個功能，最終的用戶使用是否ok？
• 這個功能，產(chǎn)品本身邏輯是否ok？
• 這個功能，技術實現(xiàn)大概邏輯和可行性是否ok？
• 這個功能的文檔或交互描述，能否更容易讓技術同學理解？

可能有人會疑惑，難道畫每一個按鈕就需要考慮這么多？

是的，產(chǎn)品的每一個交互和每一句文檔描述，上邊羅列的各種用戶都是其受眾；他們的視角會care各自關心的內(nèi)容，所以就需要產(chǎn)品經(jīng)理具備這樣的方案能力。

同時滿足多個用戶的需求是產(chǎn)品經(jīng)理需要修煉的能力。從小需求做起，保持同理心，日積月累，“用戶思維”就會變?yōu)樽约旱牧晳T。

四、產(chǎn)品開發(fā)

產(chǎn)品方案需求評審之后，就會進入產(chǎn)品開發(fā)階段，在這個環(huán)節(jié)產(chǎn)品的“主導權”就會轉(zhuǎn)由技術GG們接手。

那么在這個環(huán)節(jié)內(nèi)，PM同學就可以撒手不管了么？

答案：不是的。

雖然coding咱不會，但是咱要做的事情還是不少的，來看看這個環(huán)節(jié)的用戶和用戶問題：

中臺產(chǎn)品經(jīng)理跟業(yè)務保持實時雙向溝通。對業(yè)務既要保持項目進度的實時反饋，管理好業(yè)務預期，哪怕遇到項目風險，及時的反饋溝通也能給予業(yè)務不太差的感受；另外還要保持對業(yè)務動態(tài)的了解，盡量降低需求變更的風險。

產(chǎn)品經(jīng)理對研發(fā)團隊要做好答疑支持，不要需求一提交不管不問了，每一個“疑問”的忽視都會影響產(chǎn)品最終的質(zhì)量。另外，產(chǎn)品經(jīng)理要隔離掉上游業(yè)務其他人員對研發(fā)GG的“騷擾”，為其提供一個良好的coding環(huán)境。

還有，再說點老生常談的。項目過程中，要讓研發(fā)GG工作有干勁，加班不抱怨，產(chǎn)品經(jīng)理一定要發(fā)揮程序員鼓勵師的作用。噓寒問暖不能少，破費買吃的喝的“孝敬”一下效果更佳喲，哈哈！

五、交付使用

產(chǎn)品開發(fā)環(huán)節(jié)完成之后，就到交付使用了。

同樣，我們看下這個節(jié)點我們需要關注哪些用戶和哪些用戶問題：

寫操作說明和產(chǎn)品培訓屬于常規(guī)操作了，不再贅述。

這里面著重聊一個容易被產(chǎn)品經(jīng)理忽視的或者做的不太夠的點——發(fā)上線郵件。

在這里，我們也用下用戶思維，看看上線郵件應該怎么寫：

項目上線是項目的重要里程碑，發(fā)上線郵件是儀式感的體現(xiàn)，所有的人都希望自己的付出被認可、被贊美。

對于比較大型項目，團隊比較辛苦，產(chǎn)品經(jīng)理組織個飯局犒勞下技術GG們是非常有必要的。哈哈！

另外，上線一段時間后，例如2周。產(chǎn)品經(jīng)理一定要及時找業(yè)務童鞋要對應的產(chǎn)品效果反饋，進而對項目組成員進行同步。如果業(yè)務同學能有階段化運營成果匯報，讓項目成員參與也會起到很好的效果。

總之，任何的付出都希望有回音，哪怕是項目上線效果不好，至少也是一種反饋。

六、總結(jié)

以上分析，我們是代入進了一個具體的項目，其實回歸到每個人的崗位工作，也同樣適用用戶思維。

白話來說，就是在這個協(xié)作合作的過程中，每個用戶各自的核心訴求是什么：

產(chǎn)品經(jīng)理作為業(yè)務和研發(fā)資源的轉(zhuǎn)化紐帶，本身的水準直接決定了資源變?yōu)闃I(yè)務助力的轉(zhuǎn)化率。

一個好的產(chǎn)品經(jīng)理，給人的直觀感受就是能解決“各類用戶”的“各類問題”，不僅僅是項目本身。

我一直信奉一句話：最高級的利己是利他。

“用戶思維”其實沒那么難，無非就是多為他人真誠地著想。

作者：減形簡遠，微信公眾號：產(chǎn)品雜談（life_pm）

本文由@減形簡遠 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

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