作為一名合格的産品經理，理清産品邏輯是必然的，那要如何做呢？本文從基礎産品邏輯、業務邏輯、系統邏輯和思維邏輯四個方面進行說明。

以下這幾種情況你有躺槍麼？

• 産品邏輯總是梳理不清楚，很有邊界情況沒有考慮到，比如聯網狀态、登錄态、弱網情況等；
• 隻考慮到正向流程，返回操作和異常操作沒有考慮到，比如退出是否二次确認，未保存返回時是否保存當前内容等；
• 自己覺得産品邏輯已經梳理清楚了，但是業務邏輯是有出入的；
• 多個産品中沒有公共模塊，導緻相同業務的相同功能在不同的産品中邏輯不一樣；
• ……

這篇文章中，可能80%的産品經理都中槍了。

John之前說過邏輯三段論：聚類、遞歸和因果。

感覺是非常難以理解的，需要經過大量的項目才能做這樣的梳理。那麼在項目的過程中，項目組不同的角色他們也會有自己的邏輯方式：

• 業務邏輯：需要業務夥伴解釋清楚：這個業務想為哪些用戶提供什麼樣的解決方案，目的是什麼？——業務評審會
• 産品邏輯：需要産品經理在這個場景中能滿足業務的哪些需求，通過原型交互方式、不同頁面的跳轉規則、角色判斷等來對項目組其他同事梳理清楚。——産品評審會
• 視覺邏輯：需要依托于産品經理做這樣的原型背景下，UI應該用怎樣的視覺來讓對應用戶沉浸在該場景中。——設計評審會
• 交互邏輯：UE協同産品經理表達怎樣的交互讓用戶感覺更加的友好，增強用戶的操作感——交互評審會（和産品評審會一起）
• 開發邏輯：有些邏輯可能用技術語言描述更清楚一點，以及對技術有特殊的要求。前後端接口、數據對接等。——接口評審會

作為産品經理（萬金油角色）也需要去梳理了解角色邏輯，方便更好的溝通交流，今天就重點聊聊産品邏輯。其實産品邏輯可以分為四大類：基礎産品邏輯、業務邏輯、系統邏輯和思維邏輯。那麼本文通過四個方面來聊下：

1. 業務邏輯篇
2. 基礎産品邏輯篇
3. 系統邏輯篇
4. 思維邏輯篇

一、業務邏輯篇

業務是産品的根本，當産品經理和業務去溝通需求時，業務方隻能知道自己想要什麼，那麼産品經理需要和需求去明确幾個點：

• 需要做什麼業務？
• 做這個業務的目的是什麼？
• 這個業務的用戶群是什麼？
• 是需要解決這個用戶群的什麼問題？

其實總結起來需要溝通的就是一句話：這個業務是在什麼場景下解決哪些用戶的什麼問題，目的是什麼？這兒John舉一個案例來說明下：

業務方想要做優惠券，主要目的是為了幫助商家促銷和增加用戶複購率。那麼産品經理需要從這幾個方向去思考下：

1. 優惠券主要是為商家促銷和用戶複購——那麼類型就可以按照商家商品的屬性（全部商品、指定商品和指定商品分類）以及會員的分類（基于本身平台的會員體系分類）
2. 是否把優惠券作為了一個單獨的入口？主要是為了彰顯優惠券的重要性，同時也方便合理的召回用戶（利于消息的PUSH）
3. 優惠券是否需要分類——針對于平台券和商家券，利于按照用戶的屬性（會員等級、消費額）等給用戶不用的券
4. 購買後是否也會派發對應的優惠券——方便更好的召回用戶複購
5. 是否是長期行為——長期行為需要梳理整個優惠券體系

以上5個業務方面的内容梳理清楚後，那麼業務需求池以及對應的功能需求字段可以整理出來了。以下是John針對這五個需求場景和優惠券顯示常用字段整理：

業務邏輯的梳理一定是需要和業務方保持溝通，不要高估業務方梳理的能力，也不要指望業務方能把自己的業務場景描述清楚，并且幫你明确要開展的新玩法對你的系統有哪些影響。

要試着從産品的角度去理解這些新業務發生的場景、與現有業務的區别，從他們近似大白話的描述中捕捉到自己關注的信息，從而确定對自己負責内容的影響範圍。

二、基礎産品邏輯篇

也就是需要掌握産品的基礎邏輯，這又是産品經理的基本要求，比如前後端的數據交互方式，不同頁面之間的跳轉規則以及多個角色的判斷條件，可以用産品自查表去梳理清楚。

三、系統邏輯篇

産品經理對系統邏輯的梳理一定不是制作一個精美的PPT來說明自己想要去做什麼。而是要去根據自己的産品從主體到細節的思考産品過程。所以可以從下面三個方向去考慮：

1. 産品架構邏輯

你的産品處所行業的位置是什麼階段？競争對手現在有多大的成績？你的産品的商業模式是什麼？應該怎麼走？John在公衆号寫過産品架構的文，但是鍛煉這種思維絕不是隻是去了解下自己的産品。而是首先去通過行業去分析你的産品目前所處的位置，根據産品生命周期制定可行性的産品路線圖。通過業務去整合模塊去梳理。比如在電商産品中：

商業模式的思考：商業模式對于電商來說，有簡單的搭建平台和自營方式。這樣的方式，就是對于前端産品的架構設計提出了要求。我們使用不同的方式進行産品架構。在商業模式思考上，要把核心業務赢利點的流程設計清晰。

為運營者去思考：在運營模式思考上，要對公司後台管理人員進行有效了解和知曉未來産品推廣的方向。在通過大運營的模式下，去提高産品設計結構完美性。

為使用者去思考：對于後台使用者來說，會有不同管理權限和對應的不同職責。在設計後台時，尤其要考慮使用人員的所在公司等級關系情況。針對性的進行設計。

為用戶去思考：除了用戶初次登錄使用之外，幾乎絕大部分的情況都是登錄情況下進行操作。我們要盡量監控和維護用戶所産生的數據。對于數據來說，我們在産品結構中是稱為很底層的東西。在這個底層的數據中，我們需要通過數據挖掘去發現業務和進行業務營收的重任。

所以建議操作的步驟為：競品分析→産品業務框架→商業模式→用戶體系→産品規劃→運營規劃。隻有這樣才能清楚每一步需要做什麼以及如何去執行。

2. 産品細節邏輯

聊這個我就想怼人了哈——有些産品經理恨不得每天去讨論産品每個像素、每個顔色、每個按鈕的設計。恨不得在原型裡面埋上上百個交互細節，以體現自己産品設計細節的精妙之處。

不過遺憾的是，産品的成敗似乎與這些無關。而産品細節更多的體現在【需求本身的細節】和【功能邏輯的細節】這兩個方面：

需求本身的細節：

在人人都是産品經理的理念下，誰都會提需求——老闆會提，開發會提，甚至用戶都會提，在福特汽車時代，用戶也會提出需要一匹跑得快的馬。

但是隻有成熟的産品經理才能真正能準确判斷需求價值，具備篩選需求能力。

産品經理永遠是決定做對的事情的人，而所謂對的事情，其實就是選擇最合理最符合當前産品背景的需求。

面對讓人心動的創意，産品經理如何判斷出需求是否有價值？需求的場景是否靠譜？在多個重要需求中，如何權衡、取舍、妥協？光是這些決定，就需要産品經理全身心投入進去。

功能邏輯的細節：

舉個簡單的例子——某電商平台需要開發一個退款的功能。在需求上，退款絕對是常規需求。那麼問題來了，如果要實現退款這個需求？一定要關注的細節有：

• 用戶支付過程中用了優惠券是否要退？
• 一個訂單多個商品如何隻退一個？
• 由誰來确定用戶的退款申請？
• 退款是原路返回還是到用戶的平台賬号中？
• 退款時限多長？
• 是否所有産品都支持退款？

在面對一個正常需求時，産品經理需要把所有會涉及到的問題想透，想全，這個是非常考驗産品經理經驗和能力的地方。産品經理應該是全公司最了解自己産品每個功能細節的人，他要幫助技術了解每個需求的場景，幫助運營把需求轉化為技術方案。

3.系統對接邏輯

其次還要了解自己負責的模塊與上遊哪些主要系統有交互、交互的核心字段是什麼、交互方式有哪些。既然選擇了産品經理這個行業，就要不斷擴展自己的知識邊界，技多不壓身并非一句空話。

一個産品既對自己的系統實現輕車熟路，又對自己的上下遊系統的核心業務了如指掌，出現了問題他能通過功能細節和以往經驗定位問題的大概原因，試問，誰不願與這樣的産品共事呢？

産品架構邏輯、産品細節邏輯和系統對接邏輯是系統邏輯的三大基礎。産品經理針對這三個方面需要去思考其中的場景。在針對于系統層面分析選擇就你那個得心應手了。

四、思維邏輯篇

思維邏輯本身就是一個很虛的東西，因為幹擾的因素衆多，包含：日常工作的方式思考、産品經理個人的習慣等。那麼主要通過三個方面：産品嚴謹性、産品完整性和産品敏銳性。

1. 産品嚴謹性

産品需求需要能夠兼顧到各類用戶、各類場景。

電商中結算體系，當出現新業務需要向商家進行計費和結算時，除了正向訂單貨款，還要考慮退貨退款的逆向場景。要新增一個數據字段，除了增量數據可由程序自動賦值，還要兼顧曆史數據如何清洗。

2. 産品完整性

需要去思考各系統之間的串聯，保持高效連接。

比如O2O電商産品中， 既有負責商家、商品、訂單、售後各個條線的垂直産品經理；還有一個負責綜合類項目，梳理整體流程的綜合産品經理。

相對于前者，後者則需要更專業的知識儲備和邏輯思維，才能把一個綜合類項目串起來，不至于遺漏其中的某一個環節。産品經理也不要一葉蔽目，隻關注自己所做的内容，而是要去思考全局性。

3. 産品敏銳性

John保持産品敏銳性的方式就是去拆解産品，拆解App Store前50位産品能有效的幫助我們了解産品最新的微創新和行業動态信息。

思維邏輯本身是很虛的，作為産品經理一定要落地去融入這種思維。包括在面試的時候不要很抽象的解釋什麼是嚴謹性？而是通過案例去诠釋你的想法。

以上四種邏輯是John在做産品之後一直秉承的，并不是說這四種邏輯就是産品經理思考的全部，但是在日常工作中産品經理工作流就是去思考産品從開始到結束的最好保障。

作者：John，産品狗一枚，産品狗聚集地。歡迎一起溝通交流。

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

題圖來自Pixabay, 基于CC0協議。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部