起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識SaaS 產品經理：如何用“講故事”的方式結合業務場景聊需求？
本篇文章通過SaaS產品經理在工作中的思考與感悟，讓人們了解如何以講故事的方式與人溝通，從而更好地描述需求與接收需求，認識到回歸業務場景的重要性。
不知道作為 SaaS 產品經理，你有沒有遇到過這些問題？
比如客戶在使用系統的過程中，會提出各種需求，但實際上只是在向你傳輸解決方案。
再比如內部溝通時，如何向對方解釋，你的思路雖然邏輯上成立，但實際業務場景下，客戶并不是這樣去做的。
前者是因為提煉對方表達后的關鍵信息，整合還原成真實的業務場景。而后者是因為在表達過程中，沒有結合業務場景去描述需求。
而為了解決這類問題，SaaS 產品經理需要用場景描述的方式，給予對方強烈的代入感，便于雙方基于業務去溝通。
接下來，我會結合工作中的一些思考與感悟，分享一個“講故事”的方式，希望彼此能得心應手地聊需求。
一、回歸業務場景，是做 SaaS 產品的起點
在講故事之前，我們先來聊聊回歸業務場景的重要性。
1. 首先是對外的溝通協調
產品經理如果想推進一個需求，需要和多個部門、多種角色頻繁的交流，因此需要用一個雙方易理解、貼近實際的溝通方式。
而基于業務場景的故事，就是通行于不同角色之間，解決產品問題的通行證。
這就好比梁寧老師說的，在騰訊內部如果想辦成一件事，得不停地像念咒一樣念用戶體驗。
本質是希望我們不要被個人的理解和視角所遮蔽，能站在對方的角度上提出解決方案。
2. 其次是對內的思考與分析
產品設計的過程是先發散后收斂，尤其是 SaaS 產品的設計，是基于整個業務鏈條進行設計。
因此在動手畫原型、寫文檔之前，我們需要大量的調研、思考、分析，找出對方業務場景中的真實問題。
要知道，如果收集的信息不全，之前梳理的業務流程和原型，都會重新返工，費時費力。
3. 最后是整體產品的定義
業務脫離場景，即使邏輯上能成立，但終究不能稱作產品，因為他不能解決問題。
SaaS 產品不同于C端產品，他們自己就是用戶，甚至說可以通過想象力創造場景，達到引領用戶需求目的。
比如通過搖一搖讓彼此間陌生的人認識，進一步發生互動。雖然用戶是有這種需求，但這種方式是被創造出來的，本身并不存在。
但 SaaS 產品的本質是解決企業的業務問題，而業務本身就已經存在，所以 SaaS 產品不能創造，只能還原。
到這里，你是否理解了業務場景的重要性，尤其是對 SaaS 產品來說。
接下來進入文章的主題，如何像講故事一樣描述場景。
二、產品經理如何講故事
這里介紹一種通用的場景描述方式，一是為了不遺漏關鍵信息，二是為了描述地更加豐滿、立體，像故事一樣。
如果用一句話來描述，那么就是：
接下來讓我們逐步分析一下。
1. 場景描述七要素
（1）“誰”，某一個用戶
指一個人或者說一種類型的群體。
對于 SaaS 產品來說，可以理解為業務流程的發起者。
（2）“環境”，在某一個特定的環境
這里的環境不僅是空間、材料等物理環境，也包括物質、時間等約束條件。
比如我們到點去食堂吃飯、放假去網吧開黑，不同的環境下會產生不同的動作，也會受到不同的限制。
（3）“時機”，出現某一個特定的時機
時機包括觸發用戶產生目標的事件和影響用戶行為的環境變化。
比如在情人節跟女朋友逛街，突然看到有個小女孩在賣玫瑰，這時你會不會想買一束送給你女朋友呢？這主要受環境變化的影響。
接下來你跟你女朋友說了這個想法，她說“別浪費錢了，還不如去吃海底撈呢?！?/p>
此時，你會受到這句話的影響，思考晚上一起去吃點什么，這主要受到產生目標的影響。
（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協議
學習了，如果能多舉幾個例子就更好啦
很有用，謝謝分享
謝謝支持~
謝謝分享！！！
謝謝分享?。。?/p>
希望對你有用~ ??