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

(資料圖片)

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

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

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

一、視角分析

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

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

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

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

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

二、技術角度分析

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

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

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

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

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

三、怎么解決？

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

通常來說通知公告是有時效性的，發布比較久的通知公告讀不讀其實對業務影響不大。基于這種情況，我們可以有更低代價的技術實現方案。以我們做過的產品為例，我們的實現方式是這樣的：

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

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

四、怎么提升技術思維？

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

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

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

專欄作家

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

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

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

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

關鍵詞：