想要做出一款完美的產品幾乎是太不可能的，所以產品經理在做一款產品時，需要考慮其優先級的問題——做好決策，懂得取舍。那么，作為一名產品經理，如何做好決策？讓我們看看作者的對此的分析。

(資料圖)

本文主要的感悟來源于B端和平臺業務，大抵是不適用于所有產品的，尤其是To C的產品或業務。

在現實情況下，兼顧業務實現、管理質量、用戶體驗等多方價值的“完美”產品是很難存在的，由于商業行為天然存在的逐利性，投入產品設計和研發的人員資源總是有限。

在B端業務中，由于其目標行業、覆蓋場景的范圍，因資源問題需要做出的取舍尤其常見。

下面展開談談常常會遇到的決策場景類型。

一、以業務為中心or以用戶為中心

C端產品更接近日常生活，知名度更廣、聲量更高，所以市面上大部分產品經理的分享習慣以用戶為中心的框架來設計產品，但實際上在2B的業務中，單純以用戶為中心的設計會有諸多不足。

產品或者說信息系統有整體性、邏輯性、時效性等特點，得以支持復雜度高、需要多角色協作的業務活動，但其本質仍是解決問題的手段之一。如果在特定場景有更高效率、更低成本的手段能解決問題，產品設計就不是第一優先級的解決方案。

所以，產品的第一優先級仍是解決業務問題，而不是用戶體驗。（僅說明優先級，不是用戶體驗完全不重要的意思）

經常會有同學抱怨，內部系統如OA、財務結算平臺、訂單管理等怎么怎么難用，體驗怎么怎么差。其實究其本質，這些系統的出現不是在滿足操作者的使用體驗，而都是為管理質量和管理效率服務的。

這個就是典型的為業務服務而非為用戶（操作者）服務的場景，體現也是B端業務與C端業務主要的區別（B端是客戶（付費角色）與用戶（使用角色）分離的）。

這時候有人會犯嘀咕：“不對啊，我做的業務也是To B的，但是用戶使用體驗我們也很重視啊”。

那基本上就2種可能：

用戶操作體驗已經差到對業務目標流程有阻塞（如成交）或顯著的導致成本增加了（如客戶咨詢量）。 業務紅海，業務本身已經沒東西可以卷了。

二、擴展性與過度設計

前些年阿里中臺帶來的中臺風潮，一直到今年阿里拆中臺的塵埃落定，“中臺”這個詞或多或少的會出現在產技人的視野里。“中臺”本身偏技術概念，產品經理沒有這個能力和背景展開，這里要討論的是伴隨“中臺”而來的擴展性。

擴展性

“指一個軟件和系統能夠讓其他程序員在未來能增加新的功能以及修改現有功能，并且新增功能的同時還必須不損害現有系統或軟件功能”（wiki釋義）。

白話點講， 就是當前的設計是否能兼容或者快速適應未來業務的變化。 看似是技術同學的工作范疇，但在部分To B復雜業務場景中，花大量時間接觸業務方，理解并抽象業務的角色是產品經理。

擴展性設計的過程是在抽象業務，抽象程度越高擴展性越強，配置越靈活，但是否抽象程度越高就是越好的設計呢？

不盡然。一方面，配置靈活帶來的是更高的開發和測試成本，于業務而言，配置的大多數場景可能存在理論里的“偽場景”，所以很大一部分可能是無用的投入。 另一方面，越抽象越通用的設計，在一定程度上是“犧牲”業務細節的，進而“犧牲”一部分的業務效率。

高擴展性的設計，適用于需要快速試錯的業務方向，但對于大多數業務知識相對穩定的場景，需要謹慎權衡，否則可能會因為過度設計，讓本不富裕的開發資源雪上加霜。

提到抽象設計，這里推薦一本書：《“圖解”產品：產品經理業務設計與UML建模》。

筆者認為是目前市面上對產品最友好的領域設計和UML建模的工具書，過去DDD（領域驅動設計）的相關書籍和文章主要面向的是開發人員，序言之后很快就進入技術設計層面的討論，讀起來十分痛苦且收獲有限，于非技術同學十分不友好。

三、長尾需求是否要被滿足

面向C端的長尾場景做的產商品服務，近些年獲得成功的案例屢見不鮮，但面對B端業務的長尾需求，應該是怎樣一套決策邏輯？

這里總結下筆者的分析鏈路：

長尾需求出現的原因是什么：線下業務不規范？沒有引導用戶導致的奇異使用姿勢？ 長尾需求是否能通過非產品手段解決？ 長尾需求是否是階段性的，是否在未來可能成為主流？ 是否有其他不可抗力：如大客戶需求依賴？政治需求等等

面對長尾需求需要謹慎取舍，因為長尾需求很可能一不小心就做成ROI極低的“私人定制”。

四、結語

對于從業3年以上的產品經理，相信基本工作技能已然扎實，什么需求分析、繪制原型、跨職能溝通等在這個階段都不太值得再做展開。

這個階段產品經理的工作實際上是在不斷地做決策，核心競爭力來源于做正確決策的范圍和能力，是對邏輯能力、業務建模、行業理解等的綜合考驗。

本文由 @gxxx 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議。

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。