產品和技術的思維不同，所關注的內容也有所不同。其中有一個典型的例子就是SaaS 平臺的通知公告要不要做未讀的小紅點提醒？本文針對該案例展開分析，談談產品經理如何培養(yǎng)技術思維，一起來看看吧。

【資料圖】

前段時間看了一個視頻分享，講到了產品和技術的思維的不同，產品更關注用戶價值、使用場景、商業(yè)價值和業(yè)務閉環(huán)，而技術更關注具體實現(xiàn)、技術架構、技術價值和開發(fā)成本。

正是思考問題的角度不同，導致產品經理和技術開發(fā)會有很多不同的看法，最典型的就是“這個技術上實現(xiàn)不了”或是“這個開發(fā)成本太高了”。

視頻里講到了一個非常經典的例子，就是SaaS 平臺的通知公告要不要做未讀的小紅點提醒。本篇我們就結合這個案例來說一下產品經理如何培養(yǎng)技術思維。

一、視角分析

回到這個案例，我們先從產品經理視角來看看這個未讀通知的需求：

用戶價值：通過未讀小紅點能夠讓平臺的用戶不錯過最新通知，了解最新的通知內容。業(yè)務場景：用戶登錄到后臺或 打開App后，在通知入口看到小紅點，然后點擊查看未讀通知。商業(yè)價值：完成平臺的通知公告?zhèn)鬟_義務，讓用戶避免錯過一些重要通知，實際上這個功能商業(yè)價值不大。業(yè)務閉環(huán)：用戶存在未讀通知時，小紅點一直存在，直到用戶閱讀完（或標記已讀）全部未讀通知。

從產品經理的視角來說這個需求似乎很合理。我們來看看技術視角。

具體實現(xiàn)：這個小功能實現(xiàn)起來要做不少事情。需要建立一張通知公告和用戶的中間數據表，來標記用戶的已讀未讀狀態(tài)。當平臺發(fā)布一條新通知后，要給平臺所有的用戶插入該通知未讀的記錄。需要寫一個接口告訴前端，當前用戶有沒有未讀通知。當用戶打開一條通知詳情后，需要將未讀狀態(tài)更改為已讀。還需要寫一個標記全部已讀的接口，來標記全部的通知公告為已讀狀態(tài)。技術架構：插入的通知未讀的數據量會非常大，為了避免影響發(fā)布通知，可能需要使用異步的方式創(chuàng)建通知未讀記錄。技術價值：這東西沒什么技術價值。開發(fā)成本：開發(fā)成本比較高，而且通知越多數據量越大，到后期維護成本非常高。

可以看到，技術視角和產品視角差別非常大。技術開發(fā)接到一個需求，第一反應是做這個需求實現(xiàn)起來復不復雜、開發(fā)成本高不高。如果他們覺得需求實現(xiàn)起來復雜，開發(fā)成本高的話，往往就會回復產品經理“這個開發(fā)成本太高了”或者“這個技術上實現(xiàn)不了”。

二、技術角度分析

對于不懂技術的產品經理來說，其實很難理解一個小紅點為什么會說開發(fā)成本很高。我們來簡單地分析一下，這里面的關鍵點其實是數據量很大。在數據庫的數據表中，我們如果要記錄每一個用戶通知公告的已讀未讀狀態(tài)的話，其實就會得到類似于下面的一個表格。

可以看到，每發(fā)布一條通知，就需要為每一個租戶的每一個用戶創(chuàng)建一條閱讀狀態(tài)的數據記錄。設想一下，我們平臺有1000個客戶（即租戶），每個客戶有100個員工（用戶），這就意味著每發(fā)布一條通知，我們會產生10萬條（1000×100）數據記錄。

這也是為什么在技術架構上會想到要做異步創(chuàng)建閱讀通知的未讀記錄的原因（單次插入10萬條數據對數據庫壓力還是非常大的，可能造成系統(tǒng)卡頓）。

如果每年發(fā)布24條通知，意味著一年的數據量會達到240萬條，而且會隨著客戶量和時間不斷累積。數據量越大，一方面會導致查詢速度變慢（意味著小紅點可能要隔個2-3秒甚至更久才能出得來）。另一方面是數據量到一定量級后，會達到數據庫的性能瓶頸，可能需要通過拆分數據表來提高性能，這導致運維成本會升高。

所以，有時候技術說“實現(xiàn)不了”或“成本太高”不是真的和產品經理抬杠，而是在他們看來確實是很復雜，不值得為這樣的需求投入這樣的代價。

三、怎么解決？

產品經理的需求看起來也很合理，技術開發(fā)分析看起來也很合理，那怎么解決呢？我們還是要回歸到這個需求的核心目的上來。通知公告的小紅點目的就是提醒用戶查看平臺的通知公告。

通常來說通知公告是有時效性的，發(fā)布比較久的通知公告讀不讀其實對業(yè)務影響不大?；谶@種情況，我們可以有更低代價的技術實現(xiàn)方案。以我們做過的產品為例，我們的實現(xiàn)方式是這樣的：

獲取平臺最新的發(fā)布通知時間，如果在距離當前時間設定的時間范圍內（比如7天），我們就會在通知入口標記一個“NEW”的標識，提醒用戶有最新的通知公告，而不是未讀狀態(tài)的標識。用戶點擊過這個入口后，有前端緩存狀態(tài)，清除掉這個“NEW”標識，避免點擊過的用戶進入查看到已讀的通知公告。

這種方案既滿足了核心的產品功能訴求，在技術上也不需要創(chuàng)建針對單個用戶的已讀未讀標識，實現(xiàn)起來也更簡單。

四、怎么提升技術思維？

很多優(yōu)秀的產品經理都出身于技術，如果不懂技術，產品經理的一些不合理的設計很可能會導致整個產品的架構出現(xiàn)問題。這也是為什么有不少SaaS 公司在招聘高級產品經理的時候希望產品經理能夠懂技術，甚至是技術出身。

就我個人而言，因為本身就是從技術開發(fā)出身，所以在設計產品時會考慮技術實現(xiàn)，同時和技術開發(fā)交流上不會存在障礙，因此和開發(fā)團隊的配合都會比較默契。對于沒有接觸過技術開發(fā)的同學，個人建議從以下三個方面去提升技術思維能力：

優(yōu)秀產品研究：通過研究優(yōu)秀產品，我們會發(fā)現(xiàn)很多在我們看來很“高級”的功能，他們都已經實現(xiàn)了，因此會了解到這些高級功能的技術可實現(xiàn)性。我自己在公眾號拆解 SaaS 產品也是基于研究優(yōu)秀產品這個目的。多與開發(fā)同學交流：在產品評審階段，多聽聽技術開發(fā)同學對技術方案的評估，并且遇到不理解的可以請教他們，交流多了，就能夠培養(yǎng)自己站在技術的角度思考問題。學習基礎的技術知識：個人的建議是基礎的技術知識可以有意識地學一下，比如什么是API接口，同步/異步處理、設計模式、數據庫等等。尤其是數據庫，關系到產品和技術的最底層，可以著重考慮。比如本篇講到的案例，如果是了解數據庫知識，就能夠快速理解技術開發(fā)說的成本太高的原因，進而和開發(fā)同學一起討論一個更優(yōu)的解決方案。

專欄作家

產品海豚灣，公眾號：產品海豚灣（ID：pm-dophin-bay），人人都是產品經理專欄作家。技術出身的產品經理，從事過 C 端產品和 B 端產品設計，擅長 SaaS 產品設計、產品架構設計和需求分析。負責的B 端產品完成了完整的從0到1，從1到 N 的過程，成功簽約行業(yè)百強客戶。

本文原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載。

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

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