SaaS 平臺的通知公告要做未讀提醒嗎?
產(chǎn)品和技術(shù)的思維不同,所關(guān)注的內(nèi)容也有所不同。其中有一個典型的例子就是SaaS 平臺的通知公告要不要做未讀的小紅點(diǎn)提醒?本文針對該案例展開分析,談?wù)劗a(chǎn)品經(jīng)理如何培養(yǎng)技術(shù)思維,一起來看看吧。
前段時間看了一個視頻分享,講到了產(chǎn)品和技術(shù)的思維的不同,產(chǎn)品更關(guān)注用戶價值、使用場景、商業(yè)價值和業(yè)務(wù)閉環(huán),而技術(shù)更關(guān)注具體實現(xiàn)、技術(shù)架構(gòu)、技術(shù)價值和開發(fā)成本。
正是思考問題的角度不同,導(dǎo)致產(chǎn)品經(jīng)理和技術(shù)開發(fā)會有很多不同的看法,最典型的就是“這個技術(shù)上實現(xiàn)不了”或是“這個開發(fā)成本太高了”。
視頻里講到了一個非常經(jīng)典的例子,就是SaaS 平臺的通知公告要不要做未讀的小紅點(diǎn)提醒。本篇我們就結(jié)合這個案例來說一下產(chǎn)品經(jīng)理如何培養(yǎng)技術(shù)思維。
一、視角分析
回到這個案例,我們先從產(chǎn)品經(jīng)理視角來看看這個未讀通知的需求:
- 用戶價值:通過未讀小紅點(diǎn)能夠讓平臺的用戶不錯過最新通知,了解最新的通知內(nèi)容。
- 業(yè)務(wù)場景:用戶登錄到后臺或 打開App后,在通知入口看到小紅點(diǎn),然后點(diǎn)擊查看未讀通知。
- 商業(yè)價值:完成平臺的通知公告?zhèn)鬟_(dá)義務(wù),讓用戶避免錯過一些重要通知,實際上這個功能商業(yè)價值不大。
- 業(yè)務(wù)閉環(huán):用戶存在未讀通知時,小紅點(diǎn)一直存在,直到用戶閱讀完(或標(biāo)記已讀)全部未讀通知。
從產(chǎn)品經(jīng)理的視角來說這個需求似乎很合理。我們來看看技術(shù)視角。
- 具體實現(xiàn):這個小功能實現(xiàn)起來要做不少事情。
- 需要建立一張通知公告和用戶的中間數(shù)據(jù)表,來標(biāo)記用戶的已讀未讀狀態(tài)。
- 當(dāng)平臺發(fā)布一條新通知后,要給平臺所有的用戶插入該通知未讀的記錄。
- 需要寫一個接口告訴前端,當(dāng)前用戶有沒有未讀通知。
- 當(dāng)用戶打開一條通知詳情后,需要將未讀狀態(tài)更改為已讀。
- 還需要寫一個標(biāo)記全部已讀的接口,來標(biāo)記全部的通知公告為已讀狀態(tài)。
- 技術(shù)架構(gòu):插入的通知未讀的數(shù)據(jù)量會非常大,為了避免影響發(fā)布通知,可能需要使用異步的方式創(chuàng)建通知未讀記錄。
- 技術(shù)價值:這東西沒什么技術(shù)價值。
- 開發(fā)成本:開發(fā)成本比較高,而且通知越多數(shù)據(jù)量越大,到后期維護(hù)成本非常高。
可以看到,技術(shù)視角和產(chǎn)品視角差別非常大。技術(shù)開發(fā)接到一個需求,第一反應(yīng)是做這個需求實現(xiàn)起來復(fù)不復(fù)雜、開發(fā)成本高不高。如果他們覺得需求實現(xiàn)起來復(fù)雜,開發(fā)成本高的話,往往就會回復(fù)產(chǎn)品經(jīng)理“這個開發(fā)成本太高了”或者“這個技術(shù)上實現(xiàn)不了”。
二、技術(shù)角度分析
對于不懂技術(shù)的產(chǎn)品經(jīng)理來說,其實很難理解一個小紅點(diǎn)為什么會說開發(fā)成本很高。我們來簡單地分析一下,這里面的關(guān)鍵點(diǎn)其實是數(shù)據(jù)量很大。在數(shù)據(jù)庫的數(shù)據(jù)表中,我們?nèi)绻涗浢恳粋€用戶通知公告的已讀未讀狀態(tài)的話,其實就會得到類似于下面的一個表格。
可以看到,每發(fā)布一條通知,就需要為每一個租戶的每一個用戶創(chuàng)建一條閱讀狀態(tài)的數(shù)據(jù)記錄。設(shè)想一下,我們平臺有1000個客戶(即租戶),每個客戶有100個員工(用戶),這就意味著每發(fā)布一條通知,我們會產(chǎn)生10萬條(1000×100)數(shù)據(jù)記錄。
這也是為什么在技術(shù)架構(gòu)上會想到要做異步創(chuàng)建閱讀通知的未讀記錄的原因(單次插入10萬條數(shù)據(jù)對數(shù)據(jù)庫壓力還是非常大的,可能造成系統(tǒng)卡頓)。
如果每年發(fā)布24條通知,意味著一年的數(shù)據(jù)量會達(dá)到240萬條,而且會隨著客戶量和時間不斷累積。數(shù)據(jù)量越大,一方面會導(dǎo)致查詢速度變慢(意味著小紅點(diǎn)可能要隔個2-3秒甚至更久才能出得來)。另一方面是數(shù)據(jù)量到一定量級后,會達(dá)到數(shù)據(jù)庫的性能瓶頸,可能需要通過拆分?jǐn)?shù)據(jù)表來提高性能,這導(dǎo)致運(yùn)維成本會升高。
所以,有時候技術(shù)說“實現(xiàn)不了”或“成本太高”不是真的和產(chǎn)品經(jīng)理抬杠,而是在他們看來確實是很復(fù)雜,不值得為這樣的需求投入這樣的代價。
三、怎么解決?
產(chǎn)品經(jīng)理的需求看起來也很合理,技術(shù)開發(fā)分析看起來也很合理,那怎么解決呢?我們還是要回歸到這個需求的核心目的上來。通知公告的小紅點(diǎn)目的就是提醒用戶查看平臺的通知公告。
通常來說通知公告是有時效性的,發(fā)布比較久的通知公告讀不讀其實對業(yè)務(wù)影響不大?;谶@種情況,我們可以有更低代價的技術(shù)實現(xiàn)方案。以我們做過的產(chǎn)品為例,我們的實現(xiàn)方式是這樣的:
- 獲取平臺最新的發(fā)布通知時間,如果在距離當(dāng)前時間設(shè)定的時間范圍內(nèi)(比如7天),我們就會在通知入口標(biāo)記一個“NEW”的標(biāo)識,提醒用戶有最新的通知公告,而不是未讀狀態(tài)的標(biāo)識。
- 用戶點(diǎn)擊過這個入口后,有前端緩存狀態(tài),清除掉這個“NEW”標(biāo)識,避免點(diǎn)擊過的用戶進(jìn)入查看到已讀的通知公告。
這種方案既滿足了核心的產(chǎn)品功能訴求,在技術(shù)上也不需要創(chuàng)建針對單個用戶的已讀未讀標(biāo)識,實現(xiàn)起來也更簡單。
四、怎么提升技術(shù)思維?
很多優(yōu)秀的產(chǎn)品經(jīng)理都出身于技術(shù),如果不懂技術(shù),產(chǎn)品經(jīng)理的一些不合理的設(shè)計很可能會導(dǎo)致整個產(chǎn)品的架構(gòu)出現(xiàn)問題。這也是為什么有不少SaaS 公司在招聘高級產(chǎn)品經(jīng)理的時候希望產(chǎn)品經(jīng)理能夠懂技術(shù),甚至是技術(shù)出身。
就我個人而言,因為本身就是從技術(shù)開發(fā)出身,所以在設(shè)計產(chǎn)品時會考慮技術(shù)實現(xiàn),同時和技術(shù)開發(fā)交流上不會存在障礙,因此和開發(fā)團(tuán)隊的配合都會比較默契。對于沒有接觸過技術(shù)開發(fā)的同學(xué),個人建議從以下三個方面去提升技術(shù)思維能力:
- 優(yōu)秀產(chǎn)品研究:通過研究優(yōu)秀產(chǎn)品,我們會發(fā)現(xiàn)很多在我們看來很“高級”的功能,他們都已經(jīng)實現(xiàn)了,因此會了解到這些高級功能的技術(shù)可實現(xiàn)性。我自己在公眾號拆解 SaaS 產(chǎn)品也是基于研究優(yōu)秀產(chǎn)品這個目的。
- 多與開發(fā)同學(xué)交流:在產(chǎn)品評審階段,多聽聽技術(shù)開發(fā)同學(xué)對技術(shù)方案的評估,并且遇到不理解的可以請教他們,交流多了,就能夠培養(yǎng)自己站在技術(shù)的角度思考問題。
- 學(xué)習(xí)基礎(chǔ)的技術(shù)知識:個人的建議是基礎(chǔ)的技術(shù)知識可以有意識地學(xué)一下,比如什么是API接口,同步/異步處理、設(shè)計模式、數(shù)據(jù)庫等等。尤其是數(shù)據(jù)庫,關(guān)系到產(chǎn)品和技術(shù)的最底層,可以著重考慮。比如本篇講到的案例,如果是了解數(shù)據(jù)庫知識,就能夠快速理解技術(shù)開發(fā)說的成本太高的原因,進(jìn)而和開發(fā)同學(xué)一起討論一個更優(yōu)的解決方案。
專欄作家
產(chǎn)品海豚灣,公眾號:產(chǎn)品海豚灣(ID:pm-dophin-bay),人人都是產(chǎn)品經(jīng)理專欄作家。技術(shù)出身的產(chǎn)品經(jīng)理,從事過 C 端產(chǎn)品和 B 端產(chǎn)品設(shè)計,擅長 SaaS 產(chǎn)品設(shè)計、產(chǎn)品架構(gòu)設(shè)計和需求分析。負(fù)責(zé)的B 端產(chǎn)品完成了完整的從0到1,從1到 N 的過程,成功簽約行業(yè)百強(qiáng)客戶。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議。
該文觀點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。
學(xué)到了。但還是想問下,一些大廠SaaS(比如Jira)就有針對具體用戶的已讀未讀提醒,他們在技術(shù)上也是每條消息記錄到每個人么?