本篇文章通過SaaS產品經理在工作中的思考與感悟，讓人們瞭解如何以講故事的方式與人溝通，從而更好地描述需求與接收需求，認識到迴歸業務場景的重要性。
不知道作為 SaaS 產品經理，你有沒有遇到過這些問題？
比如客戶在使用系統的過程中，會提出各種需求，但實際上只是在向你傳輸解決方案。
再比如內部溝通時，如何向對方解釋，你的思路雖然邏輯上成立，但實際業務場景下，客戶並不是這樣去做的。
前者是因為提煉對方表達後的關鍵信息，整合還原成真實的業務場景。而後者是因為在表達過程中，沒有結合業務場景去描述需求。
而為了解決這類問題，SaaS 產品經理需要用場景描述的方式，給予對方強烈的代入感，便於雙方基於業務去溝通。
接下來，我會結合工作中的一些思考與感悟，分享一個“講故事”的方式，希望彼此能得心應手地聊需求。
一、迴歸業務場景，是做 SaaS 產品的起點
在講故事之前，我們先來聊聊迴歸業務場景的重要性。
1. 首先是對外的溝通協調
產品經理如果想推進一個需求，需要和多個部門、多種角色頻繁的交流，因此需要用一個雙方易理解、貼近實際的溝通方式。
而基於業務場景的故事，就是通行於不同角色之間，解決產品問題的通行證。
這就好比梁寧老師說的，在騰訊內部如果想辦成一件事，得不停地像唸咒一樣念用戶體驗。
本質是希望我們不要被個人的理解和視角所遮蔽，能站在對方的角度上提出解決方案。
2. 其次是對內的思考與分析
產品設計的過程是先發散後收斂，尤其是 SaaS 產品的設計，是基於整個業務鏈條進行設計。
因此在動手畫原型、寫文檔之前，我們需要大量的調研、思考、分析，找出對方業務場景中的真實問題。
要知道，如果收集的信息不全，之前梳理的業務流程和原型，都會重新返工，費時費力。
3. 最後是整體產品的定義
業務脫離場景，即使邏輯上能成立，但終究不能稱作產品，因為他不能解決問題。
SaaS 產品不同於C端產品，他們自己就是用戶，甚至說可以通過想象力創造場景，達到引領用戶需求目的。
比如通過搖一搖讓彼此間陌生的人認識，進一步發生互動。雖然用戶是有這種需求，但這種方式是被創造出來的，本身並不存在。
但 SaaS 產品的本質是解決企業的業務問題，而業務本身就已經存在，所以 SaaS 產品不能創造，只能還原。
到這裡，你是否理解了業務場景的重要性，尤其是對 SaaS 產品來說。
接下來進入文章的主題，如何像講故事一樣描述場景。
二、產品經理如何講故事
這裡介紹一種通用的場景描述方式，一是為了不遺漏關鍵信息，二是為了描述地更加豐滿、立體，像故事一樣。
如果用一句話來描述，那麼就是：
接下來讓我們逐步分析一下。
1. 場景描述七要素
（1）“誰”，某一個用戶
指一個人或者說一種類型的群體。
對於 SaaS 產品來說，可以理解為業務流程的發起者。
（2）“環境”，在某一個特定的環境
這裡的環境不僅是空間、材料等物理環境，也包括物質、時間等約束條件。
比如我們到點去食堂吃飯、放假去網吧開黑，不同的環境下會產生不同的動作，也會受到不同的限制。
（3）“時機”，出現某一個特定的時機
時機包括觸發用戶產生目標的事件和影響用戶行為的環境變化。
比如在情人節跟女朋友逛街，突然看到有個小女孩在賣玫瑰，這時你會不會想買一束送給你女朋友呢？這主要受環境變化的影響。
接下來你跟你女朋友說了這個想法，她說“別浪費錢了，還不如去吃海底撈呢。”
此時，你會受到這句話的影響，思考晚上一起去吃點什麼，這主要受到產生目標的影響。
（4）“目標”，帶著某一個目標
也就是任務結束的停止條件。
當然，這個在生活中不會那麼明顯，因為我們做的事情會不斷受到「環境」和「時機」的影響。
但在工作中，我們的目標（目的）都會很明確，比如我上午要對 10 個用戶做用戶訪談，那麼這個目標完成後，這個任務也就結束了。
（5）“介質”，與某些介質
可能是另一個用戶，也可能是一個事物。
比如我問你 234 × 298 等於多少？
你可能會拿起手邊的計算器去算，也可能打開手機的計算器來算，告訴我答案是 69,723 。
特別說明在 SaaS 產品中，可以根據這個介質判斷業務鏈中角色的相關方，從中找出受益方和受損方，避免丟失調研角色。
（6）“交互”，採取了一系列動作
簡單、具體、為達成任務採取的方式。
比如點餐這個任務，通過手指點擊（動作）點餐 pad（介質）完成操作。
（7）“任務”，通常是逐步進行的
目標是任務的總和，只有完成了多個任務，才能實現目標。
因此任務都是逐步進行，一個一個組合起來就是對應的流程圖。
舉個例子總結一下，先交代一下背景。
目前系統可下派週期方式為每日/每週/每月的週期性任務，默認從下個週期開始，比如今天是 3 月 18 號（週三），如果選擇每日 16:00至18:00，那隻能從 3 月 19 號的 16:00 至 18:00 開始。而選擇每週週二，只能從 3 月 24 號（下週二）開始。
而現在的問題是，他們經常會緊急下派任務，讓執行人完成並提交。
這裡用上述七要素來描述：
小王是小組組長，每週需要按時下派任務，突然因為疫情，需要下派緊急的每日週期性任務，這時發現系統只能從第二天開始，所以只能再建一個普通任務，操作起來會非常麻煩。
2. 觀察和驗證你講的故事
講故事最容易出現的問題，就是藉助自己的想象力，補全故事的細節。
這點對於 SaaS 產品經理來說，尤其需要警惕。
要知道， SaaS 產品的場景都是真實存在的，是需要在真實業務中去驗證的，也就是在你描述完之後，別人是否有清晰的畫面感。
如果對方覺得他實際工作中不是這麼做的，那這個時候就需要警惕了，接下來需要進一步的跟進，去確定哪部分細節有問題。
舉個例子：
小明是一名督導，上級安排他每週完成 10 家門店的巡檢，當他到了某家門店後，打開 App 開始執行任務，提交後就去下一家門店繼續巡檢。等門店全部巡檢完，再將每家門店存在的問題標註出來，提交併讓店長完成整改。
這是我最初的理解，但後來才發現是我理解的有問題，實際上他們是邊巡檢邊發起整改，提交後店長馬上進行整改。
因為大多數情況，巡檢多家門店不可能一天完成。
這就是我想當然地描述場景，造成業務理解上的偏差。
三、總結
因此在業務調研時如何能迴歸業務、梳理場景，最後以講故事的方式與其他人溝通，這需要不斷刻意的去訓練。
這個過程，會不斷培養提高我們對業務的理解。但這種理解是抽象的，而方法論只是一個柺杖，更重要的是我們在實踐中加深自己的理解。
希望你我能都能借助這個柺杖，讓這些方法論成為我們做事的習慣。
題圖來自 Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
