【乾貨】從0到1的標準化設計,從此不再敷述,saas標準化設計全解析

編輯導語:對於大部分SaaS公司來說,產品標準化程度決定了企業的生死。今天,本文作者站在產品經理的角度,分享了SaaS從0到1的標準化設計應該怎麼做。為便於讀者理解,作者以一個案例為線索,為我們一步一步演示如何從0到1設計一款SaaS產品。

【乾貨】從0到1的標準化設計,從此不再敷述,saas標準化設計全解析

限於篇幅,本文對如何畫流程圖、如何製作原型等基礎技能就不再敷述,側重闡述實現SaaS標準化設計的要點。

一、SaaS與自用系統的差異

雖然同為B端產品,SaaS與自研系統的差異卻非常明顯。從根本上來說,SaaS產品需要服務於眾多企業:少則幾十家,多則幾萬家。因此,對業務的包容性需要很強。代價則是產品迭代速度相對緩慢。

自研系統由於只服務於一家企業,強調的是貼身服務,因此對產品包容性要求較低,但是很強調迭代的速度。雖然SaaS和自研產品的邏輯是類似的,但是對產品經理能力的要求卻有一定差異。

具體可以參考下圖:

【乾貨】從0到1的標準化設計,從此不再敷述,saas標準化設計全解析

內部B端產品經理更多是輔助角色。因此比較強調深入參與和支援業務,透過協調甚至推動業務部門,達成公司目標。

SaaS產品經理就不一樣了,因為負責商業化產品,是公司實現營收和盈利的核心環節,所以比較強調產品本身的架構能力和設計能力。

我個人認為,衡量SaaS產品經理的優劣,其中一個重要的標準就是:當用戶數不斷增加,產品功能會不會被推翻或大幅修改,即能不能多做加法,少做減法和改法。

二、標準化的意義

產品標準化對SaaS公司至關重要,曾經聽某知名SaaS公司大區總監說,某個百萬級專案談得非常好,約定4個月交付上線。

結果到了第3個月,客戶要求推倒重來,按客戶實際業務重新開發。這位銷售總監抱怨道:“前面談得好好的,就用標準化產品。但到專案後期,客戶卻說產品滿足不了業務需求,真是搞不懂。”

這就是典型的產品能力支撐不了銷售能力。如果這樣的專案很多,SaaS公司就很難盈利。具體來說,SaaS標準化有以下三個重要意義:

1. 降低邊際成本

SaaS公司最大的成本投入是研發成本, 如果每一個專案都是透過配置完成交付,這意味著隨著使用者數的增加,研發成本會被逐步攤薄,最終形成規模效應,因此標準化是SaaS公司盈利的關鍵之一。

2. 沉澱最佳實踐

B端客戶真正希望購買的是“行業最佳實踐”,即便SaaS公司具備豐富的行業經驗,也瞭解行業標杆的業務策略和執行方案,如果SaaS產品不能體現和支撐這些“最佳實踐”,那麼推廣和執行的成本都會很高。

所謂標準化,其實就是把領先企業的解決方案進行提煉,再固化到系統中。這些固化的解決方案,是SaaS系統的靈魂。

3. 積累產品能力

如果SaaS公司依賴運營而不是依賴產品來保障“客戶成功”,那產品和產品經理的價值都會大打折扣。標準化會不斷增強產品的配置能力,使得產品越來越厚重,價值越來越高。也只有厚重的B端產品,才能磨鍊和體現產品經理的產品能力。

三、標準化策略

標準化策略是SaaS產品策略的重要組成部分。完整的SaaS產品策略這裡不再敷述,感興趣的讀者可以閱讀《SaaS從0到1,產品策略決定成敗》。

SaaS標準化策略可以分為三個部分,分別是:

1. 產品版本標準化策略

標準化最重要的策略,是確定“不滿足哪些客戶的需求”。

“一套產品吃遍天下”的傳統軟體時代,已經過去了。即便我們要佔領多個細分市場,也要謹慎判斷,是否透過“一個行業版本”滿足全部客戶的需求。

比如,在快消品行業,經銷商和生產商的管理模式差異是比較大的。對於經銷商來說,組織和許可權的管理是相對簡單的,也不涉及嚴格的外部賬號管理;而品牌商則有複雜的多組織管理的需求,包括外部組織和賬號的管理。

再比如,經銷商的價格體系是相對簡單的,不同等級的客戶可能會有對應的價目表,部分客戶會簽訂特定的價格協議;但是品牌商的價格體系則複雜很多,不同分公司、不同區域、不同商圈等級都會影響具體的價格。這是因為“價盤”是品牌商的生命線,所以精細的控制是有必要的。

快消品經銷商和品牌商需求差異

當然,並不是說,我們一定不能在一個版本滿足多個行業的需求。過去SAP、Oracle的成功已經證明這一點是可以實現的。但是,SaaS引以為傲的正是足夠“高可用”的系統。過於臃腫的產品,會大大增加客戶的使用成本。

反過來說,“一個版本滿足所有需求”當然是不正確的。但是如果盲目的橫向擴充版本,也會給SaaS公司帶來沉重的研發負擔。

比如,當我們面對“非處方藥”行業的客戶,是否需要劃分出一個版本呢?雖然並不是快消品行業,但是“非處方藥”卻在學習快消品行業的分銷模式。在這種情況下,如果我們提供的是分銷SaaS產品,就暫時沒有必要單獨為“非處方藥”劃分一個行業版本出來。

2. 功能層標準化策略

標準化第二重要的策略,是決定“哪些功能不標準化”。對於大部分SaaS,90%以上的功能是能夠在產品層面進行標準化的,但是可能有10%的功能是很難標準化的。分清楚哪些功能可以“在產品層面進行標準化”,也非常重要。

比如,中小企業對報表的需求相對簡單,因此報表功能是相對容易標準化的;但是對於百億級企業來說,報表是一個高度複雜且不能妥協的需求,因此對於還沒有BI或者PaaS產品的SaaS企業來說,暫時進行定製也是一個可行的選擇。

3. 開發層標準化策略

對於無法“在功能層進行標準化”的功能,我們要想辦法在開發層進行標準化,即通常我們所說的PaaS,現在流行的叫法是“低程式碼”。

低程式碼是一個很“古老”的事物。我還在Oracle公司的時候,就很頻繁的使用Oracle的低程式碼能力了——我們又叫personalization。透過它,我們可以改變欄位的屬性,也可以嵌入SQL甚至package。

也就是說,即便是能夠靈活二次開發的傳統軟體,也非常依賴低程式碼。更不用說二次開發相對困難的SaaS公司了。因此,如果一家SaaS決意要做大,PaaS能力就不是可選題,而是必選題。

但是,自研PaaS平臺確實是一個費錢的工作,並不是所有SaaS創業公司,都能夠輕易負擔得起的。好訊息是,中國SaaS正在進入平臺時代,釘釘、企業微信逐步增強的低程式碼能力,有望幫助SaaS公司低成本的擁有“PaaS自由”。

四、標準化設計難點

和自研系統相比,SaaS產品的設計更依賴長遠規劃。這是SaaS設計的核心,也是SaaS設計的難點。重視長遠規劃,主要是由於兩個原因:

1. 控制開發成本

由於標準化強調配置能力,因此同樣一個功能,所需要的開發量可能是自研系統的數倍。一旦開發了拙劣的功能,就可能對開發資源造成驚人的浪費。

2. 便於持續迭代

更重要的是,作為“公用產品”,SaaS必須保持簡潔性:如果系統充斥著一堆雞肋的功能,且有少數企業堅持在使用,那麼會對系統迭代造成阻礙。讀者可以思考一下,當規劃的新功能與這些雞肋功能產生衝突,產品經理應該如何處理?

因此,好的SaaS設計就是儘量做“加法”,避免做“減法”和“改法”。

當然,標準化設計對產品經理本身也是有要求的。我常常比喻,所謂的標準化設計,就像在棋盤上放棋子:棋盤就是產品經理所擁有的架構能力,棋子就是具體的需求。沒有棋盤,就不可能正確落子。

五、標準化設計步驟

從設計過程來說,標準化設計可以遵循以下四個步驟:

1. 策略層梳理

所謂策略層梳理,是站在相對宏觀的層面梳理業務,具體又包括以下步驟:

1)明確業務範圍

企業的業務可以分為前中後臺業務,前臺業務包括商城APP等,中臺業務包括CRM、訂單管理、物流管理等,後臺業務則包括HR、財務等。

我們首先需要明確,第一版SaaS產品版本主要是滿足哪一塊業務需求。劃定好了邊界,才能匹配公司的戰略和資源。

案例:一家知名快消品廠家找到某SaaS公司(簡稱A公司),希望開發一款管理銷售人員的移動APP。經過溝通,SaaS產品經理小李意識到,客戶的需求實際上是分銷管理,包括銷售訂單管理、銷售人員管理和門店管理等。

雖然A公司有服務於快消品‘經銷商’的分銷管理系統,但是一直苦於無法切入利潤更豐厚、收入更穩定的快消品‘品牌商’市場,這正是一個非常好的機會。

2)梳理經營策略所謂經營策略,其實就是企業的打法

比如:線上下分銷業務中,使用者企業是採用深度分銷?還是兼有直銷?搞清楚客戶的經營策略,才能理清產品研發的思路。

此外,我們必須明白,SaaS是給一個行業的眾多客戶使用的。因此,我們還需要對企業所在行業的經營策略進行梳理。這樣,一方面可以將客戶的經營策略匹配到行業的經營策略,便於我們抓住本質,確保產品的通用性;另一方面,也可以通盤考慮未來的拓展方向,提前打好架構基礎。

比如,快消品線下分銷常見的策略包括大批發制、多級分銷、深度分銷、直銷、車銷等,而深度分銷又分為廠家覆蓋模式和經銷商覆蓋模式。作為產品經理,有必要全面梳理這些模式,才能在產品設計時胸有成竹。

案例:小李和客戶溝通後,發現該快消品廠家主要採用了大批發制、直銷和深度分銷三種經營策略,屬於行業比較經典的打法,可以先開發這三種分銷模式,同時兼顧到未來向多級分銷和車銷的拓展。

【乾貨】從0到1的標準化設計,從此不再敷述,saas標準化設計全解析

大批發是廠家把貨賣給批發商,由批發商再進行二次分銷。大批發模式雖然是比較粗放的分銷方式,但是當廠家管理能力不足時,採用大批發模式可以實現快速鋪貨,因此仍然是常見的一種分銷模式。

【乾貨】從0到1的標準化設計,從此不再敷述,saas標準化設計全解析

快消品行業有40%左右的銷量,都是透過以大超市為代表的現代通路完成的。這些大超市往往是區域連鎖甚至全國連鎖,可以樹立品牌形象,但是進入門檻高、談判過程複雜,因此,往往是由快消品廠家直接進行合作。

【乾貨】從0到1的標準化設計,從此不再敷述,saas標準化設計全解析

深度分銷是快消品分銷的重要方向。實行深度分銷的企業,往往已經具備一定的規模和管理能力。他們將區域進行劃分,指定經銷商專營,強調終端門店的鋪貨率、陳列、新品普及率等。

對於企業來說,深度分銷可以最大化挖掘終端門店的潛力,提高新品和高毛利商品的銷售量,並有效的阻擊競爭對手。因此,這種模式一直是伊利、康師傅、可口可樂等大型快消品企業的重點分銷模式。

3)梳理業務難點相對於傳統軟體,SaaS是後來者

根據產品替換公式:新產品價值>舊產品價值+替換成本,只有SaaS提供了更大的價值,客戶才會考慮購買。退一步說,即便沒有競爭的傳統軟體,SaaS也必須解決“以前無法解決的問題”,才能在激烈的競爭中站穩腳跟。

因此,梳理清楚業務難點,明白“客戶為什麼選擇我們”,是非常重要的工作,可以讓我們把資源集中在最關鍵的功能上。而不是分散資源,做那些客戶雖然願意使用,但是不構成“差異化競爭力”的功能。

案例:經過和客戶溝通,小李瞭解到,其實客戶之前已經耗費上百萬實施了某國際知名品牌的CRM系統,但是移動端的使用者體驗非常糟糕。除了使用上不夠高可用,需要反覆培訓才能上手;低下的操作效率和緩慢的響應速度,更是使得系統的推廣困難重重。

客戶為什麼選擇由A公司來開發分銷系統,就是在體驗了A公司的移動端產品後,認為產品的使用者體驗非常優秀,可以解決當前系統推廣的最大難題。瞭解到客戶的訴求後,小李意識到:這個針對快消品廠家的SaaS系統,設計的重心要放在移動端。

快消品行業普遍存在銷售人員學歷低、管理難的問題,如果透過移動端大大提高員工效率、降低員工使用難度,那麼該SaaS產品將對快消品品牌商產生巨大吸引力。

2. 業務層梳理

業務層梳理,最有效的做法就是畫業務流程圖。流程圖的重點在於,產品經理要幫助客戶梳理清楚業務和需求,避免錯亂和遺漏。而做到這一點的關鍵,是產品經理要有一定的架構能力,即知道典範的流程應該如何流轉。

如果是針對大客戶的SaaS,那麼建議到客戶現場呆一段時間。大客戶的要求比較細緻,現場溝通可以提高溝通的效率;如果是針對小客戶的SaaS,那麼建議你先找到幾個種子使用者,透過流程圖,確保1。0版本是他們能夠接受的MVP(最小可行產品)。

流程圖繪製細節是基本功,這裡就不再敷述。下面放一張我曾經繪製的流程圖供大家參考:

【乾貨】從0到1的標準化設計,從此不再敷述,saas標準化設計全解析

案例:一開始,該快消品企業認為自己的需求很簡單,主要是業務人員在手機端錄入銷售訂單,再透過介面實時傳送到已有的ERP系統即可,如下圖:

小李並沒有急於下結論,而是在黑板上畫出了典範的分銷管理流程,然後按照流程環節逐個進行梳理,如下圖:

【乾貨】從0到1的標準化設計,從此不再敷述,saas標準化設計全解析

經過梳理,小李很快發現,該廠家對於區域連鎖賣場等大客戶,採取的是廠家業務員拜訪、工廠直接發貨的直營銷售策略;對於非連鎖便利店等小客戶,採取的是廠家業務員拜訪、經銷商發貨的深度分銷策略。因此,客戶實際上有兩種不同的銷售管理流程,如下圖:

【乾貨】從0到1的標準化設計,從此不再敷述,saas標準化設計全解析

流程梳理清楚,設計思路也就清晰了。同時,小李專業的需求梳理方法也得到了客戶認可,客戶領導當場表達了合作的意向。

3. 多組織架構設計

企業業務的開展,是基於多個部門的相互協同和相互監督的。當用戶在使用SaaS系統時,流程流轉、資料安全性都必須符合企業協同與管控的要求。這就需要我們設計好組織、角色和許可權功能。而這裡面最有難度的,就是多組織架構設計。

比如,某飲料公司為擴大銷售規模,分別在A市和B市建立了分公司,各負責一個大區的生產和銷售。為便於管理和激勵分公司團隊,公司決定兩個分公司獨立核算利潤,並根據實現的利潤進行分紅。

為支援兩個分公司的獨立核算,並防止資料洩露,該飲料公司IT團隊決定分別給兩個分公司建立一個“利潤中心組織”。

在“利潤中心組織”下面建立了相應的“角色”,並分配了相應的“功能”比如銷售訂單、發貨功能等等。最後,將相應的“角色”分別分配給了兩個分公司的員工。

【乾貨】從0到1的標準化設計,從此不再敷述,saas標準化設計全解析

這樣,A公司員工建立的銷售訂單,所產生的收入和利潤資料,均會統計到A公司。且銷售訂單、收入和利潤等資料,只能由A公司的員工檢視。B公司亦如此。

多組織架構實際上體現了企業責權利的劃分,決定了組織間協同與風險管控策略。由於企業越大,組織架構就越複雜,管控要求也越高。因此,越是針對大型企業的SaaS,越需要重視多組織架構的設計。

當然,如果是針對小企業的SaaS,多組織架構就相對簡單了,大家把角色和許可權管理設計好即可。

案例:小李梳理發現,客戶下設2個獨立核算的營業部,每個營業部下面都有若干經銷商。

對於直營的KA門店,只能由對應營業部管理資料和處理業務;對於經銷商管理的便利店,只能由對應經銷商管理資料和處理業務。同時,經銷商所屬的營業部,也具有這些便利店相關資料的管理權。

小李設計了“利潤中心”組織型別,並建立了兩個利潤中心組織:江東營業部和江南營業部。

經銷商A、經銷商B、KA門店C都屬於客戶(具有不同的客戶型別),在客戶資訊上加上“所屬組織”欄位,透過該欄位,將這3個“客戶資料”都分配江東營業部。這樣,就只有江東營業部的人員可以看到他們的資料以及業務資料。

對於便利店a、b、c、d,則透過類似的方式,關聯到對應的經銷商,確保經銷商之間業務資訊的隔離。

【乾貨】從0到1的標準化設計,從此不再敷述,saas標準化設計全解析

4. 產品功能設計

作為SaaS設計的主體,產品功能設計又可以分為應用架構設計和詳細功能設計。

1)應用架構設計

所謂應用架構設計,即各系統應用的整體結構圖。

相對於自研產品,SaaS的應用架構設計更為關鍵。合理的應用架構可以減少功能重複、避免資料混亂和降低系統拓展的難度。而一旦在不合理的應用架構上搭建起功能模組,並且擁有一定數量的企業客戶後,修改的成本就非常高了。

相對來說,自研產品的糾錯成本就低得多。畢竟只有一家企業在用,只要和業務部門協商好,推翻重建也不是不可以。

對於產品經理來說,應用架構設計的重點要做到低耦合、高複用。所謂低耦合,是將功能按照業務相關性,分為多個系統應用。系統應用之間透過API進行互動。

這樣,單個應用的升級,對其他應用的影響就小很多,從而提高了系統的敏捷性。比如,銷售訂單管理、倉庫管理和CRM就可以獨立為多個應用,並且在必要的時候分配給不同的團隊負責。

所謂高複用,即將各個模組所共用的功能抽離出來,單獨形成一個系統應用。

這樣,一方面確保了資訊來源的一致性,另一方面簡化了系統,避免了重複開發。比如,客戶資訊在銷售訂單管理、CRM、TMS(運輸管理)等系統應用中都會用到,是有必要獨立成一個應用的。

應用架構設計雖然沒有標準答案,但實際上不管是傳統的Oracle ERP系統,還是新興的各大電商、SaaS系統,都有非常成熟的應用架構設計。多研究競品,再結合實際情況進行適當的調整是應用架構設計的好方法。

案例

:考慮到A公司已經有獨立的客戶資訊系統,也有成熟的商品管理系統,小李決定直接複用這些系統。為了滿足品牌商的需求,小李增加了一些新的功能,比如商圈管理、價格策略管理等。

其實,複用客戶資訊管理和商品管理模組,小李還有長期的考慮,即未來品牌商版本和經銷商版本可能會打通,形成交易型的SaaS產品。如果兩個版本共用一套基礎資料功能,會有利於將來的資料整合和流程整合。

2)詳細功能設計

SaaS詳細功能設計很考驗產品經理的系統經驗,從設計流程上來說,SaaS功能設計也遵循通用B端產品設計流程,如下圖:

但是,SaaS系統面對的是多個企業的具體需求,而這些具體需求看起來總是千差萬別的;更困難的在於,產品經理並不能確定未來會面對什麼樣的企業,也就無法預知所有的需求。

在這種情況下,產品經理可能就會面臨各種尷尬局面,比如:

功能升級需要大幅修改原有功能,開發抱怨;

功能升級改變原有體驗,客戶抱怨;

功能上線後,沒有人使用,團隊抱怨;

功能上線後,客戶說需求變更了,各種人抱怨。

所以SaaS詳細功能設計很考驗產品經理的規劃和深度思考能力,具體來說,SaaS產品經理需要做好以下幾點:

從0到1的SaaS,往往是從一小群客戶的需求起步。當客戶數量較少,功能也不多的時候,產品的設計缺乏約束,很容易野蠻的生長。

比如,買贈是消費品行業常用的促銷手段。在某些情況下,贈品需要關聯到主品,比如買5瓶大可樂送1瓶小可樂。產品經理為了設計和操作方便,可能選擇直接在訂單行上新增欄位,體現贈品名稱和數量。

這樣的設計在面對簡單需求的時候,可能不會出現問題。但是一旦遇到比較複雜的情況,比如:

需要管理贈品發貨;

買5增2,買5瓶大可樂送2種贈品;

需要和ERP系統整合等情況時,就會出現問題。

正確的做法是,主品和贈品都放在獨立的訂單行,擁有相同的欄位,並且透過“贈品”欄位來標識該訂單行是否贈品(打勾即為贈品)。因此,作為SaaS產品經理,不能夠只盯著眼前的需求,而應該放眼長遠,儘可能考慮全面。

另外,SaaS產品經理必須承認:即便通曉所有需求,我們仍無法確定全部需求的優先順序。因此,一般情況下,產品經理只能挑選那些最有價值的需求優先進行滿足。而且,每一次的設計都應該是MVP,從而避免暫時不需要的功能被提前開發。

這就是SaaS謹慎設計的原則。

SaaS設計的糾錯成本,遠高於自研產品。但是,SaaS產品經理離客戶往往比較遠,不容易深入參與客戶的日常經營。

相對而言,傳統軟體時代的專案制,需求設計師可以在一個客戶現場駐點數月進行需求調研和系統開發;而自研產品的產品經理,則幾乎天天和業務方在一起溝通。

SaaS公司的研發團隊龐大,不可能都派駐到客戶現場,因此產品經理往往需要兩頭兼顧,既要把客戶的需求搞透徹,也要做好設計,讓研發能夠順利工作。

在這種情況下,SaaS產品經理就必須具備“究竟精神”:對客戶的每一個需求刨根問底,究其本質。我一直堅守一個原則:永遠相信客戶有一個痛點,但是永遠不要相信客戶有一個正確答案,也把這個原則送給大家。

SaaS為什麼能夠搶佔傳統軟體的市場?最重要的原因並不是SaaS更便宜,而是SaaS的出生就帶有移動化、社交化的屬性。但是,移動端設計的難度是PC端設計的好幾倍。原因除了手機螢幕更小,同時也是因為移動端操作是在戶外,場景更復雜,對體驗和效率的要求也更高。

比如:快消品車銷業務員為了完成一天的拜訪任務,拜訪一個客戶的時間平均不能超過5分鐘。為了節約時間,業務員需要一邊卸貨一邊拿著手機下訂單。因此,“錄入銷售訂單”這個頁面必須足夠簡單和高效。

比如:在輸入商品數量時,就可以直接錄入多單位數量(不需要選擇單位),如“1箱/3瓶”。並且允許透過加減號來增減數量。

這樣,當業務員搬下車1箱3瓶酸奶(假設1箱酸奶有9瓶),他就不需要再計算出“1箱3瓶等於12瓶”才能錄入系統,這就可以大大提高業務員的操作效率。

【乾貨】從0到1的標準化設計,從此不再敷述,saas標準化設計全解析

要做好SaaS互動設計,除了和UE同學充分溝通和探討,更重要的是多研究和學習競品。所謂三人行必有我師焉,何況我們是從0到1的設計SaaS呢?

案例

:在進行報表設計時,客戶有幾張已經使用了5年的核心統計報表,客戶領導希望新的報表仍然沿用以前的統計邏輯。但是,小李仔細分析後,發現以前的邏輯並不是最優的。

因為客戶的部門和人員每年都會調整,而原報表是根據“訂單-人員-部門”的對應關係,來計算銷售業績。這就導致進行同期對比時,歷史年份和最新年份的業績基礎並不公平。

比如,去年的A部門,有10個人員,管轄a片區;今年的A部門,有20個人員,管轄b片區。如果簡單的把去年A部門業績和今年A部門業績做對比,實際上是有失公允的。

小李和客戶的專案負責人進行了溝通,由於這個客戶是快消品行業最頂尖的企業之一,專案負責人也屬於比較自信的領導,因此一開始小李的建議並沒有得到重視。

但是小李堅持與客戶進行溝通,指出“在分銷模式下,只有便利店和對應的區域是相對穩定的。因此應該用A部門所負責c區域的今年業績,和c區域去年業績做對比,這樣才是真正公平的”。

最終,客戶領導被小李說服了,他當著眾人的面誇獎了小李。而有了客戶領導的配合,專案的推進也非常順利,最終成功上線。小李也藉助這個專案完成了SaaS的從0到1。不久,他又將這個SaaS產品銷售給了其他的大客戶,幫助公司成功完成在大客戶市場的突破。

六、總結

SaaS產品的設計,很強調產品經理的架構能力。如果用一句話對本文做個總結,那就是:畫好棋盤,放好棋子。

祝大家,設計出一款改變世界的SaaS產品。

#專欄作家#

王戴明,微信公眾號:To B老人家,人人都是產品經理專欄作家。多年網際網路產品與資訊化管理經驗。

本文原創釋出於人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基於 CC0 協議

頂部