SaaS產品是云計算中的一種服務類型，近年來已經成為一種流行趨勢。作為設計師，如何設計SaaS產品的交互？

 

首先，我們要對SaaS產品有一個全面的了解，形成一個標準化的流程。

 

1.梳理產品目標

 

目標是第一位的，只有方向正確，才能沿著正確的道路不斷前進。

我們可以先了解行業背景，比如我們的產品屬于哪個行業，或者多個行業的通用產品。

 

此外，我們可以了解我們服務業的上下游環節，以及我們是處于末端環節、中間環節還是頭部環節。

 

有了這些準備，我們開始專注于了解目標。

 

其實目標很多。企業在不同的發展階段有不同的目標，比如某一年的目標，分季度、分月的目標，三到五年的戰略發展目標。

 

這個目標也可以理解為商業目標。我們的用戶也有用戶目標，也就是用戶使用這個產品想要達到的目的。

 

目標這么多，不應該全部遵守。這時產品經理需要平衡業務目標和用戶目標，最終得到產品需要遵循的目標，即產品目標，作為后續工作的指導思想。

 

作為交互設計師，我們主要參與這部分的工作，用我們專業的交互知識幫助產品經理整理出最終的產品目標。

 

2.梳理業務流程圖

 

這里有兩種情況。如果是0對1的產品，我們需要分析實際的線下業務流程，先梳理一下，然后再考慮轉到線上解決方案的時候如何設計業務流程。

 

如果是1到N的產品，應該已經有業務流程圖了。我們要做的是熟悉和了解產品的業務流程；如果不是，我們要做的就是根據實際系統整理業務流程圖。

 

做這項工作的主要目的是幫助我們先有一個全球化的產品感覺。

 

3.梳理功能架構圖

 

同上，這里有兩種情況。對于0到1的產品，可以先分析需求文檔，提取里面的功能點，畫出功能架構圖。

 

如果需求文檔的準備還沒有開始，可以參與需求的處理，細化成功點，然后繪制功能架構圖。

 

至于需求收集，我們通常將分散的需求放入需求池中進行管理。關于需求處理，可以用需求的四象限法來處理。

 

這種方法被需求分析師和產品經理廣泛使用，主要是對需求池中的需求進行優先級排序。

 

橫軸縱向表示緊急程度，橫向表示重要程度。重要和緊急性質為主。過去，許多經驗問題被置于不重要或不緊急的尷尬境地。隨著體驗時代的到來，體驗有望提升到戰略高度。

 

對于1到N的產品，功能架構比較簡單，只是整理需求文檔或者實際系統。目的是讓自己大致了解產品的整體功能點。

 

4.組織權限描述和字段表

 

個人認為需求文檔的這一部分屬于底部。它可以分析產品的書面需求文檔，提取權限描述和字段表。

 

如果產品編寫的需求文檔中沒有這樣的內容，就需要和產品經理進行面對面的溝通，了解產品的底層邏輯。

 

5.協助完成珠江三角洲文件

 

如果產品經理完成了PRD，我們會用自己專業的交互方式幫助產品經理優化PRD文檔。

 

如果產品經理沒有開始寫PRD，可以用以上步驟協助產品經理寫PRD文檔。

 

主要是業務規則的編寫，輸入輸出等。

 

B端SaaS產品設計：從0到1

所謂萬事開頭難，產品設計通常最難的是從0到1、從無到有，而后續的產品升級迭代則相對沒有那么難。所以，筆者在這里重點討論的是如何從0開始設計B端SaaS產品。筆者將B端SaaS產品從0到1的設計分為四個步驟：規劃、梳理、設計與開發。

 

1、規劃

首先要做的是確定產品的方向與目標，回答“要去到哪里”、“往哪個方向走”的問題。要回答這兩個問題就需要開展縝密的分析。從宏觀角度出發，先做行業研究，理解甲方企業所在的行業結構，了解甲方上下游價值鏈是怎樣構成的，分析他們的商業模式和核心業務流程。在此基礎上，分析甲方客戶的普遍需求是什么，目前我們作為乙方是通過什么方式來滿足甲方的這些需求的，還有哪些競爭對手是怎樣提供服務的。然后，基于SWOT分析厘清自身的優勢和劣勢，認清外部的機遇和威脅，結合自身的服務能力與資源稟賦現狀，找到適合的產品定位與目標。

2、梳理

第二步是在認準方向的基礎上做深入細致的需求分析與梳理。在第一步我們已經鎖定了產品方向，第二步首先要做的就是仔細研究這個產品方向所針對的甲方業務流程，分析業務流程涉及了哪些主要節點、每個節點的輸入和輸出是什么，整個流程的瓶頸和問題是什么等。然后帶著這些問題深入到甲方客戶中，開展內部訪談與調研。

訪談的對象涉及高層主管領導、中層管理者和基層執行人員，從高層領導處了解他們對業務運營的期望與目標，從中層管理者了解他們對業務運營的需求，從基層執行人員那里收集對產品使用層面的需求。然后綜合競品分析、內外部訪談和資料研究等方面的結果，梳理出一份產品功能的需求列表。對需求進行標注，哪些是顯性的需求，哪些是隱性的需求，哪些是需要進一步挖掘的需求等。再根據ICE（Impact、Confidence、Ease）等評估方法對需求進行打分排序，輸出新產品的路線圖。

3、設計

接下來就進入了產品設計階段。這里的套路就是一些比較常規的產品設計路線，是做產品設計的常用流程。從MVP定義開始，再是產品的整體架構設計、前后臺產品框架設計、技術架構設計等，然后輸出產品的PRD文檔，設計原型界面和UI方案。PRD文檔、原型和UI方案按序評審后就可以進入下一道工序了。

4、開發

最后一步是開發，意味著進入到產品從紙面上的圖形模擬進入實際的代碼開發階段了。首先，B端產品經理要與技術開發相關負責人敲定產品開發的排期，明確時間節點和輸出物、責任人等。產品開發的工作至此就轉入到了技術支持團隊手中，技術開發相關負責人需要組織技術人員進行產品實現的技術方案設計與評審，再將開發任務分配到前端、后端、數據庫等技術人員手中，規定具體任務和期限，然后就是各方面的技術人員分頭去開發落實了。當技術開發到可測試的程度時，B端產品經理就要協調各方面進行聯調測試和灰度測試，這些測試通過后才可以進入到最后的上線發布。當然，如果產品測試沒有達到要求時，還需要技術開發人員反查問題、及時優化，直至滿足要求才可部署上線。

以上是對B端SaaS產品從0到1的流程與步驟的大致介紹。實現從0到1只是萬里長征的第一步，當然，也是至關重要的一步。

 

動詞 （verb的縮寫）交互式設計

 

1.設計目標

 

基于之前的產品目標，我們需要細化交互設計師應該遵循的設計目標。

 

我們經常使用KANO模型來整理設計目標，這可以幫助我們確定可以增強用戶體驗的需求點。

 

下面我將詳細談談如何使用KANO模型:

 

橫軸表示用戶滿意度，橫軸表示功能滿意度。

 

這個需求點滿足后，用戶滿意度有明顯提升，但是不滿足，用戶滿意度也不會很低，我們把這種需求叫做興奮型需求，也可以理解為人打了興奮劑一般，但是不打，人也能正常生活。

 

這個需求點滿足后，用戶滿意度有明顯提升，但是不滿足，用戶滿意度也會明顯下降，我們把這種需求叫做期望型需求，也可以理解為一種正比關系。

 

這個需求點滿足后，用戶滿意度提升不明顯，但是不滿足，用戶滿意度卻會明顯下降，我們把這種需求叫做基本型需求。

 

這個里面基本型需求和期望型需求，都是客戶的剛需，必須要滿足的，不然客戶就會很不爽，而興奮型需求則是交互設計師需要努力挖掘的點，提升轉化的發力點。

 

這個需求點滿足后，用戶滿意度沒有任何變化，可有可無的感覺，我們把這種需求叫做無差異型需求，這種需求就是可以直接拋棄掉做減法了。

 

這個需求點滿足后，用戶滿意度反而明顯下降，我們把這種需求叫做反向需求，這種就可以理解為禁區了，同樣也是要直接拋棄掉做減法了。

 

通過KANO模型整理出產品的交互設計目標后，可以根據產品迭代的進度將目標拆分成不同的版本。

 

2.需求分析

 

仔細閱讀產品經理輸出的需求文檔，用交互設計師的思路分析需求。

 

比如分析需求范圍、功能點、權限描述、字段表。如果交互設計師在協助階段充分參與以上步驟，這里的工作會更簡單，進一步把握產品業務，逐漸讓自己成為一名業務顧問，在項目推進的時候更好的回答下游成員的問題。

 

如果交互設計師不參與協助產品，只需要對照需求文檔分析需求范圍、功能點、權限描述、字段表即可。

 

如果需求文檔不清楚，也可以親自和產品經理溝通這些細節。

 

3.競爭性產品分析

 

競爭性產品分析首先需要分析我們產品的直接競爭對手，比如和我們做類似產品的老競爭對手和新競爭對手。

 

其次，我們需要分析一下我們產品的間接競爭對手，他們可能和我們同行業，但是產品不一樣，不能保證以后不會做我們這個領域。

 

最后是行業巨頭的競爭。這里的主要目的是看看我們的市場規模是否足以吸引巨頭加入。

 

因此，我們應該努力把重點放在SaaS產品的細分上，這樣市場天花板就在那里，巨頭們就不能小看這么小的利潤。

 

推而廣之，我想詳細說說如何為SaaS產品打造護城河。b端產品不同于C端產品。

 

隨著行業的深度積累，新的競爭對手門檻很高，俗稱護城河。我從以下幾個方面來談談如何為SaaS產品打造護城河:

 

1)重置成本

 

客戶一直在使用我們的產品。如果有一天他們被競爭對手的銷售成功逆轉，轉而使用他們的產品，客戶會發現更換成本非常高。

 

首先是數據遷移的成本，需要將我們系統中的所有數據遷移到新的服務提供商；此外，業務理解的差異會導致數據結構的不同，這可能會導致許多數據丟失或無法遷移。

 

其次，客戶培訓的成本。舊系統可能花了很多精力，用的很巧妙。現在要切換系統，系統用戶要花很多精力去學習新系統。

 

2)品牌效應

 

在某個領域或行業獲得了一定的聲譽，解決了客戶的一些痛點，受到客戶的歡迎，從而形成了自己的品牌感。

 

3)網絡效應

 

客戶的上游和下游已經習慣了使用公司的系統。雖然客戶不使用這種產品，但為了方便與上下游合作，他必須使用它。

 

這就是所謂的網絡效應。比如C端，你的朋友用微信。如果不用的話，是不是不方便聯系他們，就要用。

 

具有網絡效應的產品正處于瘋狂增長期，大量新客戶不得不用你的產品。

 

4)關注子行業

 

能量有限，很難做到大而全，尤其是很多大廠虎視眈眈的時候。如果我們能專注于一個非常細分的行業，我們的利潤上限就那樣，大廠也不會因為看不上這個市場而和你競爭。

 

另外，其他新的競爭對手也因為你的專注而不敢挑戰你，所以你可以在這個領域繼續發展。

 

5)總結

 

說了這么多，其實moat最根本的還是服務好客戶，給客戶帶來價值，讓客戶不斷更新收費。

 

無論開發團隊多么強大，如果沒有客戶愿意為生產出來的產品買單，那就毫無意義。

 

重點是公司的戰略要控制大方向，產品經理要控制詳細方向，包括業務價值、客戶價值、客戶體驗。

 

4.交互模型

 

如果前三步都是準備工作，那么交互模型階段就是交互設計的正式開始。

 

我總結的交互模型方法挺好用的，就是用戶，場景，目標。

 

用戶，指使用這個項目或產品的都是些什么人。B端行業，我們面對的是客戶，但是客戶作為一個企業，里面也有形形色色的個人，這些具體的人也就是用戶。

 

用戶可能有很多，需要找到我們的目標用戶，對應的我們可能會有用戶畫像或者客戶畫像。

 

我們常說的以用戶為中心，或者以客戶為中心，基本就是以此為基礎。中國經濟的下半場也越來越注重B端行業的客戶體驗了。

 

繼續深挖下，我們可以有用戶體驗地圖以及用戶旅行地圖，而這兩者的區別主要在于體驗。

 

體驗地圖主要是針對所思、所做、所感；旅行地圖則針對所做。場景，大公司有很多基于場景化的B端設計方法，我們需要去挖掘可能存在的用戶場景，常用的方法有故事板，用講故事的方式把場景描述清楚。很多用戶體驗設計以及情感化設計也是基于對場景的挖掘為基礎。

 

目標，也可以理解為任務，用戶或者客戶使用這個系統要做的事情，或者我們也可以理解為用戶的痛點以及期望，我們設計這款系統就是為了要解決客戶的這些問題。

 

關于目標，深挖下，我們有用戶目標和商業目標，兩者平衡下，得出產品目標或者業務目標，設計師可以根據業務目標提煉出設計目標，當然這個目標一定是可量化，可驗證的，我們只有準確知道了目標完成的如何，才好安排迭代的方向。

 

交互模式主要是讓我們先對產品的整體框架有一個了解，最后我想深入挖掘用戶。事實上，在SaaS產品的設計過程中，我們需要非常了解客戶。

 

這里，我想分兩種情況。如果是0比1的產品，肯定需要把線下的業務搬到線上來解決。

 

因此，我們需要對客戶的線下痛點有一個清晰的認識，比如客戶目前存在哪些無法解決的痛點，在無法解決之前用了哪些替代方法來解決。

 

另外，要把客戶線下的業務流程梳理清楚，以便區分不同的用戶和場景。

 

如果是已經上線的產品，無論迭代到哪個版本，這一次我們都處于產品優化階段。

 

如果還處于發展階段，此時的戰略目標是進一步擴大新客戶數量，保證老客戶更新換代，產品設計需要圍繞這個目標進行。

 

如果處于成熟階段，此時客戶可能會覺得我們的產品沒有創新，新客戶較少，部分老客戶開始不續費，或者產品不符合目前的客戶市場。

 

這時候的戰略目標是優化產品，可能是提升用戶體驗，也可能是調整產品的功能方向。

 

要了解優化中的客戶，主要是要找出客戶目前在線的痛點，精細梳理用戶流程，找到優化的方向。

 

5.信息架構

 

在我看來，信息架構設計其實就是從用戶的角度來設計之前的功能架構圖，主要是設計產品的導航系統。

 

還有一點就是為正式繪制頁面原型打下基礎。有的交互設計師得到需求后直接開始畫原型。

 

其實這是非常錯誤的，不僅效率低，而且返工率高。正確的做法是詳細分析后畫出原型。這種思維方式不僅清晰，而且節省時間。

 

6.任務流程

 

根據上面分析的交互模型，我們需要針對不同場景下不同用戶的不同任務進行精細設計，盡量覆蓋所有用戶任務流程。

 

任務流程可以理解為多個節點，每個節點都是一個或多個頁面，這樣主體的頁面原型框架就出來了，也可以為后面繪制原型打下基礎，但只是為了不漏掉一些細節頁面和邊界頁面，提高原型繪制的準確性。

 

7.頁面原型

 

隨著信息架構和任務流程的準備，頁面原型階段自然會省去很多麻煩。這里我主要想說一下畫原型需要遵循的一些原則。

 

除了格式塔原理和菲茨定律，還有四種交互設計策略，即組織、刪除、隱藏和轉移。

 

組織——可以理解為分組，相近和相似原則，對產品的信息架構進行設計。

 

刪除——少即是多原則，精簡用戶看到的界面，提高用戶解決問題的專注力。隱藏——不是很重要的信息，都隱藏起來，當用戶需要時，可以通過操作找到。

 

轉移——給用戶簡單的體驗，把復雜的東西轉移到后臺；另外一些設置參數的，也是盡量轉移給后臺，給用戶一種簡單的操作。

 

交互設計的方式有很多，關鍵看你怎么用。

 

我們的最終目標是希望用戶看到頁面就知道如何操作。經過系統反饋，用戶知道如何進行下一步，從而形成流暢的操作體驗，進一步使產品自動化、智能化、人性化。

 

8.互動評論

 

我覺得互動復習之前有一些準備工作需要提前完成。原型繪制完成后，需要與產品、技術boss、boss溝通達成共識，然后補充交互描述，輸出交互文檔，再用交互文檔與關鍵人物再次溝通。因為我覺得如果交互評審只是把交互文檔傳達給下游UI、開發、測試等人員，阻力會小很多。

 

另外，如果在設計過程中有一些疑惑，也可以找相關人員確認，這樣可以提高整體設計效率。

 

正式互動審核流程如下:

 

1)介紹產品背景

 

在解釋的開始，有必要簡單描述一下這個產品建立的大致環境，比如為什么制作，怎么制作，產品背景。

 

2)說出問題

 

我們的總體商業愿望是什么？這次我們解決了哪些用戶痛點？我們的產品目標是什么？而交互設計的目標是什么？說明以上問題，告訴大家在開始做交互設計之前做了哪些準備。

 

3)如何解決問題，說說設計過程

 

如果有數據分析，可以說作為前奏，沒有數據分析也沒關系。

 

此時，您可以從頭到尾解釋整個交互式文檔。原型設計的一些關鍵點可以詳細討論。為什么要這樣設計？前面的推導過程是可以描述的，或者是競爭性的演示，多方案的選擇等。

 

另外可以談談設計策略，如何解決問題，解決過程中發生了什么。

不及物動詞設計著陸

 

設計落地主要是指交互評審通過后，交互設計方案如何有效落地。

 

1.設計進步

 

這時，下游合作伙伴開始按計劃工作。在這個過程中，我們需要回答關于UI、開發和測試的業務問題。作為產品的業務顧問，應該有很多工作要做。

 

當被問及時，我們也可以閱讀交互式文檔來整理我們的想法。得到交互文檔后，UI也會開始UI設計，交互設計師需要控制UI的輸出，協助UI設計師進行UI審核。

 

如果UI最終效果不好，會影響產品的體驗，所以交互設計需要控制這些細節。

 

作為產品需求的執行者，在測試階段，除了控制交互測試，還要保證交互文檔中的細節能夠完美實現；同時要控制好需求測試，確保產品實現效果符合需求設計。

 

2.可用性測試

 

在測試工程師穩定了功能之后，交互設計師需要領導可用性測試過程。我個人對可用性測試有一些看法。

 

可用性測試是在產品功能穩定后，在測試環境中尋找一些真實用戶來完成核心用戶任務流，從而驗證投入產出比，解決產品易用的問題。

 

在用戶測試之前，可以設置一些指標，比如完成率、完成時間，也就是有多少用戶可以完成流程，用戶花了多少時間。

 

通過對用戶感受和最終數據結果的現場觀察，可以得出以下結論:

 

產品是否解決了用戶的業務痛點，是否是自己想用的產品，可以理解為是否可用。

 

體驗流程過程中，用戶的操作和系統反饋是否順暢，不進行培訓用戶上手的難度如何以及培訓后用戶操作的流暢性如何等，可以理解為是否易用，同時也可以提前知道后期培訓用戶的成本會有多大。

 

產品的視覺美觀度如何，部分用戶可能會提一些好不好看的問題。

 

產品的品牌傳播效果如何，通過以上的結果，可以自己挖掘到該產品以后去推廣時，品牌傳播效應如何。

 

3.漏斗分析

 

項目上線后，我們需要收集用戶使用反饋和數據分析，根據反饋結果和數據分析結果進行版本迭代設計，不斷優化產品的最終體驗效果。

 

關于數據分析，我們經常使用漏斗指標。根據用戶的任務流程，可以選擇核心流程，查看每一步的用戶流失率。

 

比如第一步用戶數是10000，第二步是8000，最后只有100人完成這個過程。此時轉化率只有1%，虧損99%。

 

過程中損失較大的步驟也可以作為改善用戶體驗的分析點。漏斗分析也可以作為A/B檢驗的數據證明。

 

總結

 

如何利用用戶體驗點來判斷產品最終的體驗效果。簡單來說，用戶體驗好的產品有什么特點？

 

1.從五個層次的經驗來看

 

1)業務水平，符合業務目標

 

即需要滿足產品開發的戰略目標。我們做的所有產品都是商業商品，所有產品首先要滿足自己的商業價值。

 

當然，我們需要平衡業務價值和用戶價值，不能只關注業務價值，而不顧用戶。時間長了，用戶就會拋棄這個產品；同理，不能只關注用戶價值。

 

這樣產品就沒有商業閉環，無法盈利，最終會因為供給端的成本而崩潰。

 

2)函數層，減去函數

 

這個減法的主要意思是突出產品的核心價值，而不是一下子把所有的功能都做了。

 

有句話叫“多即是少”，功能都有。找不到關鍵點就什么都沒有了，也不會體現出對用戶的價值。

 

因此，我們需要遵循“少即是多”的原則，精簡產品功能，突出核心價值，把解決用戶痛點放在首位，以后不斷放大這個核心價值。

 

3)流程層，針對不同用戶的不同場景進行精細設計

 

首先，用戶需要分層，這個用戶可能屬于不同的組織。簡單來說，首先要梳理用戶的層次。

 

常見的是老板、經理、員工這三層。其次，基于這些分層的用戶，梳理出可能出現的場景，比如老板在什么情況下會使用這個產品，有哪些痛點。

 

有了以上的梳理，我們就把任務流程細化，盡量把所有可能的流程梳理出來。

 

4)認知層，頁面具有良好的認知屬性

 

這主要是針對頁面的使用成本，可以考慮四種交互策略的原則，即整理、刪除、隱藏、轉移。

 

設計整體頁面架構，降低頁面使用成本，提高產品的反饋能力。

 

5)視覺層，視覺美感好

 

產品外部形象好，吸引用戶，有很好的情感設計。更高的視覺層次是產品有品牌感，作為用戶喜愛的品牌在市場上推廣。

 

2.從用戶流程優化的角度來看

 

前一種方法可以用來設計從0到1的產品，也可以作為從1到n的產品進行優化，這里只針對后期優化的產品，但是需要公司把用戶體驗提升到戰略層面。

 

1)降低用戶的認知成本，使產品自動化、智能化、人性化

 

這個和上面的認知層差不多，但是還需要更進一步。我們需要產品更人性化。人是群居的，人總是喜歡和人打交道。

 

如果產品足夠人性化，用戶使用產品就像與人打交道一樣簡單，似乎可以超出用戶的預期。

 

有句話叫好產品會說話，就是這個道理。

 

2)減少場景切換，分離簡單場景，拆分復雜場景

 

這里主要關注用戶場景的優化。場景很多。在產品開發后期，需要進一步細化體驗，所以需要進一步優化場景。

 

盡量讓用戶在一個頁面上完成一個功能，而不是做一件簡單的事情，你需要來回切換頁面。

 

如果是復雜的功能操作，可以將操作分為多個步驟，然后每一步都是獨立的，類似于將大事化小，大大降低了用戶的運營成本。

 

3)優化用戶行為

 

在產品開發的某個階段，通過數據分析可以獲得用戶的很多行為。如果我們希望用戶做一些事情，我們也可以設計用戶的行為，讓用戶按照我們的期望來操作。

 

B端SaaS產品運營：“三分法”

關于B端SaaS產品的運營，筆者總結為“三分法”，即產品分階段、目標分解化、運營分步驟。

 

1、產品分階段

按照產品的生命周期，將其分為四個階段：產品探索期、產品增長期、產品成熟期和產品衰退期。每個階段有相應的認定標準，各個階段要聚焦的目標各有側重，相應的產品策略和運營思路也會有差異。

2、目標分解化

按照產品的戰略目標與規劃，將產品的目標分解到四個階段中。再將每個階段的目標進行指標化和數量化。產品探索期的主要目標是找到PMF（Product Market Fit，產品與市場的契合點），這個階段的關鍵指標是種子客戶數、留存率等；產品增長期的主要目標是快速擴張客戶規模，此階段對應的關鍵指標是新增客戶數、目標客戶滲透率、MRR等；產品成熟期的主要目標是提升客戶價值，此階段對應的關鍵指標是LTV、復購率、ARPU等；產品衰退期的主要目標是延長客戶生命周期，此階段對應的關鍵指標是客戶流失率、產品使用時長等。

3、運營分步驟

所謂運營分步驟是指SaaS產品的運營分為四個步驟：獲取客戶、服務跟進、付費轉化和客戶維系。這四個步驟映射到產品生命周期的四個階段后，就會形成相應的思路和舉措。比如，在產品探索期的主要獲客舉措是借助高層領導的影響力，推動與甲方領導的高層互訪，按照三步曲來走，即高層拜訪——邀請客戶參觀考察——簽訂戰略合作協議。同時，推進線上渠道獲客，利用百度大搜、官網、EDM、seo等手段收集銷售線索。

 

還需要說明的是，在產品的不同生命周期階段，產品運營的側重點也會有所差異，也即是投入到獲取客戶、服務跟進、付費轉化和客戶維系中的資源會有所不同。比如，在產品增長期應將主要精力聚焦在獲取客戶上，在產品成熟期則應將主要的精力放在付費轉化和客戶維系上。

 

作者：產品找北