產(chǎn)品和技術有著不同的方法論，但有些東西是相通的。那么，產(chǎn)品設計的邏輯，能否代替代碼構建的邏輯呢？這篇文章，我們看看作者的分析。

一、產(chǎn)品始終以業(yè)務為基

互聯(lián)網(wǎng)行業(yè)軟件研發(fā)領域中，核心的協(xié)作角色通常包括：

• 產(chǎn)品經(jīng)理
• 開發(fā)人員，含前后端程序員
• 技術人員
• 往前延伸，還會有流程建設人員，往后延伸還會有測試人員、運維、安全等

每個節(jié)點的職責有層帶般的區(qū)分，分別會衍生出來以下架構：業(yè)務架構、產(chǎn)品結構、技術架構、IT結構。

沒有一開始就有的產(chǎn)品結構，產(chǎn)品一定是在業(yè)務發(fā)展中催生出來的。

這就是為什么字節(jié)跳動催生了飛書，OKR這一套在字節(jié)內(nèi)部如此好用的東西，當飛書要推向其他企業(yè)的時候卻屢屢受挫。這也是為什么，當年騰訊張小龍帶隊的微信剛面世時候，四面楚歌，小米的米聊一開始勢頭很猛，卻在后續(xù)的大數(shù)據(jù)大用戶處理上、在社交產(chǎn)品的認知上節(jié)節(jié)敗退，不得不退出社交領域的競爭。一眾對手眼睜睜目送微信一步步高奏凱歌。

產(chǎn)品隨著業(yè)務需求不斷拓展，催生出來更合理的分層架構

產(chǎn)品邏輯的背后需要程序代碼的支撐，再底層有需要技術架構的支撐。每個支撐層帶都希望能夠盡可能準確的掌握業(yè)務演進的方向，這里面包括：業(yè)務板塊、用戶規(guī)模、業(yè)務模式等等。

二、產(chǎn)品連接著商業(yè)與技術

首先產(chǎn)品團隊成員需要對商業(yè)、具體業(yè)務的深刻理解、對用戶場景的感知，才能設計出/找到產(chǎn)品實現(xiàn)路徑當下的最優(yōu)解。

產(chǎn)品經(jīng)理應該能夠根據(jù)業(yè)務的發(fā)展 、產(chǎn)品路徑的演進，判斷出來一些核心邏輯的設計、區(qū)分和預留。形成所謂的產(chǎn)品規(guī)劃、產(chǎn)品實現(xiàn)路徑，也可以簡單叫做“產(chǎn)品節(jié)奏”。

這個節(jié)奏的基調(diào)引導了代碼的架構，這也就是產(chǎn)品邏輯、功能邏輯、到代碼邏輯、數(shù)據(jù)邏輯的層層銜接了。

簡單到一個功能點，代碼邏輯需要在產(chǎn)品功能迭代路徑的支撐下才能更好的實現(xiàn)，產(chǎn)品經(jīng)理不去和程序員探討功能與實現(xiàn)、業(yè)務與產(chǎn)品，難道指望程序員自己就能理解業(yè)務嗎？

可能有，太少了！優(yōu)秀的程序員會有更好的業(yè)務和用戶共情能力，但是多少思維上還是更偏向于“實現(xiàn)思維”的，它們是實現(xiàn)的可行性、復用性、簡潔性、高效性。

三、做起心動念的人，也做攀爬的人

作為一名產(chǎn)品經(jīng)理，絕對不是簡單的我想要什么，剩下的交給開發(fā)者。想要什么很重要、路徑演進的可能性同樣也很重要，表達清楚絕對是為自己的產(chǎn)品路線鋪路。

相信任何產(chǎn)研團隊都不愿意看到產(chǎn)品極速發(fā)展的過程中，代碼逐漸臃腫不堪、跟不上發(fā)展的步伐，最終不得不面臨重構，要不就是產(chǎn)品的妥協(xié)、用戶價值/商業(yè)價值的大打折扣。

當你愿意和開發(fā)者、技術人員共同分享產(chǎn)品設計的邏輯、產(chǎn)品節(jié)奏的時候，你得到的將會是一群愿意支持你、為你的產(chǎn)品方案主動思考的開發(fā)者、技術人員、測試工程師們。

看看下面的故事吧，開發(fā)者也會和產(chǎn)品經(jīng)理主動分享代碼的設計邏輯咯！這不就是最好的局面嗎？

四、跟著攻城獅看feature背后數(shù)據(jù)構建的心路歷程

開發(fā)者的思維對于產(chǎn)品經(jīng)理來說是非常值得進行一些了解的，作為產(chǎn)品的設計者，誰不想做到由表及里的透徹呢？了解實現(xiàn)模型，才能更好的結合產(chǎn)品模型、用戶心理模型。

產(chǎn)品可維護，用戶使用可維護，觸發(fā)功能設計背后的數(shù)據(jù)構建邏輯，值得探索。

特別是涉及到算法邏輯的部分，需要有對應的數(shù)據(jù)過程記錄和沉淀，滿足可追溯、可查證。產(chǎn)品設計中，我們會自然地認為，一切應該怎么發(fā)生，向何處發(fā)生。沿著正確的路徑用正確的方式向前，記錄下來我們認為重要的東西。

就像我們的大腦夠復雜吧，那些不起眼的決定、意念、下意識，都簡單的我們甚至察覺不到它的存在。其實細微之處可以將一次常規(guī)的對話展開，接收者解碼、接收者自己的知識匹配、判斷、識別、結果輸出，還有環(huán)境、地域的各種影響加持。這指引我們向世界交付價值時候需要考慮到，比較顯性的價值流完善健全，也有比較隱性的支撐性的存在不可或缺。

2023年操盤一個小項目中，當產(chǎn)品方將產(chǎn)品邏輯、業(yè)務邏輯透徹的和開發(fā)者達成共識之后，開發(fā)者竟也反過來極其耐心和我探討對程序邏輯實現(xiàn)、數(shù)據(jù)表設計的細節(jié)和思路，想要記錄的數(shù)據(jù)等等，以此來確保他的理解和產(chǎn)品設計的一致性。特別是策略算法過程中，會用到幾個數(shù)據(jù)計算指標來確定最終的匹配推薦結果，這幾個數(shù)據(jù)計算的過程數(shù)據(jù)的存儲，程序員主動提出來要做存儲支持數(shù)據(jù)回溯，也可以支撐業(yè)務一些驗證需求。

一個程序員能夠思考到如此細節(jié)，還是讓我眼前一亮，為他豎起大拇指！這不正是產(chǎn)品設計邏輯和代碼構建邏輯兩者的珠聯(lián)璧合嗎？這里并不是要產(chǎn)品經(jīng)理鉆入到實現(xiàn)思維里面，而是從產(chǎn)品視角之外，也可以去看看一個程序猿面對需求時，他實現(xiàn)的設計和背后的思考，從中獲得到開發(fā)者提供給自己思維的反哺。