產(chǎn)品和技術(shù)的思維不同，所關(guān)注的內容也有所不同。其中有一個(gè)典型的例子就是SaaS 平臺的通知公告要不要做未讀的小紅點(diǎn)提醒？本文針對該案例展開(kāi)分析，談?wù)劗a(chǎn)品經(jīng)理如何培養技術(shù)思維，一起來(lái)看看吧。

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

正是思考問(wèn)題的角度不同，導致產(chǎn)品經(jīng)理和技術(shù)開(kāi)發(fā)會(huì )有很多不同的看法，最典型的就是“這個(gè)技術(shù)上實(shí)現不了”或是“這個(gè)開(kāi)發(fā)成本太高了”。

(資料圖片)

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

一、視角分析

回到這個(gè)案例，我們先從產(chǎn)品經(jīng)理視角來(lái)看看這個(gè)未讀通知的需求：

用戶(hù)價(jià)值：通過(guò)未讀小紅點(diǎn)能夠讓平臺的用戶(hù)不錯過(guò)最新通知，了解最新的通知內容。業(yè)務(wù)場(chǎng)景：用戶(hù)登錄到后臺或 打開(kāi)App后，在通知入口看到小紅點(diǎn)，然后點(diǎn)擊查看未讀通知。商業(yè)價(jià)值：完成平臺的通知公告傳達義務(wù)，讓用戶(hù)避免錯過(guò)一些重要通知，實(shí)際上這個(gè)功能商業(yè)價(jià)值不大。業(yè)務(wù)閉環(huán)：用戶(hù)存在未讀通知時(shí)，小紅點(diǎn)一直存在，直到用戶(hù)閱讀完（或標記已讀）全部未讀通知。

從產(chǎn)品經(jīng)理的視角來(lái)說(shuō)這個(gè)需求似乎很合理。我們來(lái)看看技術(shù)視角。

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

可以看到，技術(shù)視角和產(chǎn)品視角差別非常大。技術(shù)開(kāi)發(fā)接到一個(gè)需求，第一反應是做這個(gè)需求實(shí)現起來(lái)復不復雜、開(kāi)發(fā)成本高不高。如果他們覺(jué)得需求實(shí)現起來(lái)復雜，開(kāi)發(fā)成本高的話(huà)，往往就會(huì )回復產(chǎn)品經(jīng)理“這個(gè)開(kāi)發(fā)成本太高了”或者“這個(gè)技術(shù)上實(shí)現不了”。

二、技術(shù)角度分析

對于不懂技術(shù)的產(chǎn)品經(jīng)理來(lái)說(shuō)，其實(shí)很難理解一個(gè)小紅點(diǎn)為什么會(huì )說(shuō)開(kāi)發(fā)成本很高。我們來(lái)簡(jiǎn)單地分析一下，這里面的關(guān)鍵點(diǎn)其實(shí)是數據量很大。在數據庫的數據表中，我們如果要記錄每一個(gè)用戶(hù)通知公告的已讀未讀狀態(tài)的話(huà)，其實(shí)就會(huì )得到類(lèi)似于下面的一個(gè)表格。

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

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

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

所以，有時(shí)候技術(shù)說(shuō)“實(shí)現不了”或“成本太高”不是真的和產(chǎn)品經(jīng)理抬杠，而是在他們看來(lái)確實(shí)是很復雜，不值得為這樣的需求投入這樣的代價(jià)。

三、怎么解決？

產(chǎn)品經(jīng)理的需求看起來(lái)也很合理，技術(shù)開(kāi)發(fā)分析看起來(lái)也很合理，那怎么解決呢？我們還是要回歸到這個(gè)需求的核心目的上來(lái)。通知公告的小紅點(diǎn)目的就是提醒用戶(hù)查看平臺的通知公告。

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

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

這種方案既滿(mǎn)足了核心的產(chǎn)品功能訴求，在技術(shù)上也不需要創(chuàng )建針對單個(gè)用戶(hù)的已讀未讀標識，實(shí)現起來(lái)也更簡(jiǎn)單。

四、怎么提升技術(shù)思維？

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

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

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

專(zhuān)欄作家

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

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

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

該文觀(guān)點(diǎn)僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。

標簽：