作為一名合格的產品經理，理清產品邏輯是必然的，那要如何做呢？本文從基礎產品邏輯、業務邏輯、系統邏輯和思維邏輯四個方面進行說明。
以下這幾種情況你有躺槍麼？
- 產品邏輯總是梳理不清楚，很有邊界情況沒有考慮到，比如聯網狀態、登錄態、弱網情況等；
- 只考慮到正向流程，返回操作和異常操作沒有考慮到，比如退出是否二次確認，未保存返回時是否保存當前內容等；
- 自己覺得產品邏輯已經梳理清楚了，但是業務邏輯是有出入的；
- 多個產品中沒有公共模塊，導致相同業務的相同功能在不同的產品中邏輯不一樣；
- ……
這篇文章中，可能80%的產品經理都中槍了。
John之前說過邏輯三段論：聚類、遞歸和因果。
感覺是非常難以理解的，需要經過大量的項目才能做這樣的梳理。那麼在項目的過程中，項目組不同的角色他們也會有自己的邏輯方式：
- 業務邏輯：需要業務夥伴解釋清楚：這個業務想為哪些用戶提供什麼樣的解決方案，目的是什麼？——業務評審會
- 產品邏輯：需要產品經理在這個場景中能滿足業務的哪些需求，通過原型交互方式、不同頁面的跳轉規則、角色判斷等來對項目組其他同事梳理清楚。——產品評審會
- 視覺邏輯：需要依託於產品經理做這樣的原型背景下，UI應該用怎樣的視覺來讓對應用戶沉浸在該場景中。——設計評審會
- 交互邏輯：UE協同產品經理表達怎樣的交互讓用戶感覺更加的友好，增強用戶的操作感 ——交互評審會（和產品評審會一起）
- 開發邏輯：有些邏輯可能用技術語言描述更清楚一點，以及對技術有特殊的要求。前後端接口、數據對接等。——接口評審會
作為產品經理（萬金油角色）也需要去梳理瞭解角色邏輯，方便更好的溝通交流，今天就重點聊聊產品邏輯。其實產品邏輯可以分為四大類：基礎產品邏輯、業務邏輯、系統邏輯和思維邏輯。那麼本文通過四個方面來聊下：
- 業務邏輯篇
- 基礎產品邏輯篇
- 系統邏輯篇
- 思維邏輯篇
一、業務邏輯篇
業務是產品的根本，當產品經理和業務去溝通需求時，業務方只能知道自己想要什麼，那麼產品經理需要和需求去明確幾個點：
- 需要做什麼業務？
- 做這個業務的目的是什麼？
- 這個業務的用戶群是什麼？
- 是需要解決這個用戶群的什麼問題？
其實總結起來需要溝通的就是一句話：這個業務是在什麼場景下解決哪些用戶的什麼問題，目的是什麼？這兒John舉一個案例來說明下：
業務方想要做優惠券，主要目的是為了幫助商家促銷和增加用戶復購率。那麼產品經理需要從這幾個方向去思考下：
- 優惠券主要是為商家促銷和用戶復購——那麼類型就可以按照商家商品的屬性（全部商品、指定商品和指定商品分類）以及會員的分類（基於本身平臺的會員體系分類）
- 是否把優惠券作為了一個單獨的入口？主要是為了彰顯優惠券的重要性，同時也方便合理的召回用戶（利於消息的PUSH）
- 優惠券是否需要分類——針對於平臺券和商家券，利於按照用戶的屬性（會員等級、消費額）等給用戶不用的券
- 購買後是否也會派發對應的優惠券——方便更好的召回用戶復購
- 是否是長期行為——長期行為需要梳理整個優惠券體系
以上5個業務方面的內容梳理清楚後，那麼業務需求池以及對應的功能需求字段可以整理出來了。以下是John針對這五個需求場景和優惠券顯示常用字段整理：
業務邏輯的梳理一定是需要和業務方保持溝通，不要高估業務方梳理的能力，也不要指望業務方能把自己的業務場景描述清楚，並且幫你明確要開展的新玩法對你的系統有哪些影響。
要試著從產品的角度去理解這些新業務發生的場景、與現有業務的區別，從他們近似大白話的描述中捕捉到自己關注的信息，從而確定對自己負責內容的影響範圍。
二、基礎產品邏輯篇
也就是需要掌握產品的基礎邏輯，這又是產品經理的基本要求，比如前後端的數據交互方式，不同頁面之間的跳轉規則以及多個角色的判斷條件，可以用產品自查表去梳理清楚。
三、系統邏輯篇
產品經理對系統邏輯的梳理一定不是製作一個精美的PPT來說明自己想要去做什麼。而是要去根據自己的產品從主體到細節的思考產品過程。所以可以從下面三個方向去考慮：
1. 產品架構邏輯
你的產品處所行業的位置是什麼階段？競爭對手現在有多大的成績？你的產品的商業模式是什麼？應該怎麼走？John在公眾號寫過產品架構的文，但是鍛鍊這種思維絕不是隻是去了解下自己的產品。而是首先去通過行業去分析你的產品目前所處的位置，根據產品生命週期制定可行性的產品路線圖。通過業務去整合模塊去梳理。比如在電商產品中：
商業模式的思考：商業模式對於電商來說，有簡單的搭建平臺和自營方式。這樣的方式，就是對於前端產品的架構設計提出了要求。我們使用不同的方式進行產品架構。在商業模式思考上，要把核心業務贏利點的流程設計清晰。
為運營者去思考：在運營模式思考上，要對公司後臺管理人員進行有效瞭解和知曉未來產品推廣的方向。在通過大運營的模式下，去提高產品設計結構完美性。
為使用者去思考：對於後臺使用者來說，會有不同管理權限和對應的不同職責。在設計後臺時，尤其要考慮使用人員的所在公司等級關係情況。針對性的進行設計。
為用戶去思考：除了用戶初次登錄使用之外，幾乎絕大部分的情況都是登錄情況下進行操作。我們要儘量監控和維護用戶所產生的數據。對於數據來說，我們在產品結構中是稱為很底層的東西。在這個底層的數據中，我們需要通過數據挖掘去發現業務和進行業務營收的重任。
所以建議操作的步驟為：競品分析→產品業務框架→商業模式→用戶體系→產品規劃→運營規劃。只有這樣才能清楚每一步需要做什麼以及如何去執行。
2. 產品細節邏輯
聊這個我就想懟人了哈——有些產品經理恨不得每天去討論產品每個像素、每個顏色、每個按鈕的設計。恨不得在原型裡面埋上上百個交互細節，以體現自己產品設計細節的精妙之處。
不過遺憾的是，產品的成敗似乎與這些無關。而產品細節更多的體現在【需求本身的細節】和【功能邏輯的細節】這兩個方面：
需求本身的細節：
在人人都是產品經理的理念下，誰都會提需求——老闆會提，開發會提，甚至用戶都會提，在福特汽車時代，用戶也會提出需要一匹跑得快的馬。
但是隻有成熟的產品經理才能真正能準確判斷需求價值，具備篩選需求能力。
產品經理永遠是決定做對的事情的人，而所謂對的事情，其實就是選擇最合理最符合當前產品背景的需求。
面對讓人心動的創意，產品經理如何判斷出需求是否有價值？需求的場景是否靠譜？在多個重要需求中，如何權衡、取捨、妥協？光是這些決定，就需要產品經理全身心投入進去。
功能邏輯的細節：
舉個簡單的例子——某電商平臺需要開發一個退款的功能。在需求上，退款絕對是常規需求。那麼問題來了，如果要實現退款這個需求？一定要關注的細節有：
- 用戶支付過程中用了優惠券是否要退？
- 一個訂單多個商品如何只退一個？
- 由誰來確定用戶的退款申請？
- 退款是原路返回還是到用戶的平臺賬號中？
- 退款時限多長？
- 是否所有產品都支持退款？
在面對一個正常需求時，產品經理需要把所有會涉及到的問題想透，想全，這個是非常考驗產品經理經驗和能力的地方。產品經理應該是全公司最瞭解自己產品每個功能細節的人，他要幫助技術瞭解每個需求的場景，幫助運營把需求轉化為技術方案。
3.系統對接邏輯
其次還要了解自己負責的模塊與上游哪些主要系統有交互、交互的核心字段是什麼、交互方式有哪些。既然選擇了產品經理這個行業，就要不斷擴展自己的知識邊界，技多不壓身並非一句空話。
一個產品既對自己的系統實現輕車熟路，又對自己的上下游系統的核心業務瞭如指掌，出現了問題他能通過功能細節和以往經驗定位問題的大概原因，試問，誰不願與這樣的產品共事呢？
產品架構邏輯、產品細節邏輯和系統對接邏輯是系統邏輯的三大基礎。產品經理針對這三個方面需要去思考其中的場景。在針對於系統層面分析選擇就你那個得心應手了。
四、思維邏輯篇
思維邏輯本身就是一個很虛的東西，因為干擾的因素眾多，包含：日常工作的方式思考、產品經理個人的習慣等。那麼主要通過三個方面：產品嚴謹性、產品完整性和產品敏銳性。
1. 產品嚴謹性
產品需求需要能夠兼顧到各類用戶、各類場景。
電商中結算體系，當出現新業務需要向商家進行計費和結算時，除了正向訂單貨款，還要考慮退貨退款的逆向場景。要新增一個數據字段，除了增量數據可由程序自動賦值，還要兼顧歷史數據如何清洗。
2. 產品完整性
需要去思考各系統之間的串聯，保持高效連接。
比如O2O電商產品中， 既有負責商家、商品、訂單、售後各個條線的垂直產品經理；還有一個負責綜合類項目，梳理整體流程的綜合產品經理。
相對於前者，後者則需要更專業的知識儲備和邏輯思維，才能把一個綜合類項目串起來，不至於遺漏其中的某一個環節。產品經理也不要一葉蔽目，只關注自己所做的內容，而是要去思考全局性。
3. 產品敏銳性
John保持產品敏銳性的方式就是去拆解產品，拆解App Store前50位產品能有效的幫助我們瞭解產品最新的微創新和行業動態信息。
思維邏輯本身是很虛的，作為產品經理一定要落地去融入這種思維。包括在面試的時候不要很抽象的解釋什麼是嚴謹性？而是通過案例去詮釋你的想法。
以上四種邏輯是John在做產品之後一直秉承的，並不是說這四種邏輯就是產品經理思考的全部，但是在日常工作中產品經理工作流就是去思考產品從開始到結束的最好保障。
作者：John，產品狗一枚，微信公眾號：產品狗聚集地。歡迎一起溝通交流。
題圖來自Pixabay, 基於CC0協議。
"閱讀更多 人人都是產品經理 的文章
