To B 產品如何寫解決方案?
筆者以實際經驗為例,總結To B產品解決方案的一些心得,enjoy~
對于To B產品來說,寫解決方案是一個經常性的工作,主要原因是To B產品面對的客戶種類太多,不同種類的客戶又有不同的定制化需求,很難通過一份標準產品介紹做到一勞永逸。
以做區塊鏈產品的公司為例,如果客戶是政府部門,需要區塊鏈在智慧城市的融合方案,那么就需要制作一份智慧城市的解決方案;如果面對的客戶是不動產行業,那么就需要先調研不動產行業現狀,寫一份區塊鏈在不動產行業中的應用方案;如果客戶是企業,就要根據與客戶的交流需求定制化企業解決方案,如利用區塊鏈去優化供應鏈金融,或利用區塊鏈優化企業間的對賬效率等。
總之To B產品很難通過一份產品介紹就完成銷售的工作,通常都需要根據客戶的需求,通過解決方案來告知客戶自己的產品如何與對方結合,結合后的效果是什么。
筆者以實際經驗為例,總結To B產品解決方案的一些心得。
一、心態
看淡:
以筆者的實際經歷為例,所寫的多數解決方案其實是不會落地的,大多數方案可能是寫完就沒有后文,客戶收到解決方案后輕描淡寫的看一下,面對這種經常發生的事情,有一個良好的心態是十分重要的。
看淡并不是說可以不用心去寫解決方案,而是解決方案寫完之后即使沒有被落地,不要太過于失望。在實際的商業運轉之中,購買者采購產品都會貨比三家,所以按照“三家”的數量來看,至少有兩家會落選,成功概率也僅僅是三分之一而已,再加上一些根本就沒有需求來“騙方案”的客戶或心不誠的客戶,把成功率的分母基數拉的越來越大,一份解決方案可以被成功落地的概率僅有十分之一左右也不足為奇。
二、原則
1. 目標決定方案的粒度
方案沒有最細化,只有更細化,具體細化到什么程度就要根據細化展開后是否有助于目標的達成來決定。例如寫區塊鏈在政府數據交易領域的解決方案,初稿方案的目標是讓政府領導了解區塊鏈,了解以區塊鏈的模式進行數據交易可以合法合規,并且具有安全、保護隱私、權責明確等特點,圍繞著這個目標,去展開寫區塊鏈的系統如何部署,數據如何建模等業務細節就沒有必要,反而寫了會讓文檔更加臃腫,不易閱讀。
2. 讀者的地位、時間決定方案的內容
如果是一份商業計劃書,讀者是資方的領導,計劃書寫了近50頁,交給領導后你認為會發生什么?
領導隨意翻一下,發現內容、數據太多,交給下屬的專業人士去研究。如果方案的第一印象勾不起讀者興趣,那么方案大概率就會失敗。
因此上述的商業計劃書情景,就需要先面向資方領導寫一份一頁紙的詳情介紹,在配以一份有數據有計劃的詳情介紹,總結下來就是要圍繞讀者來寫,方案也需要具備用戶思維。
2. 讀者的認知、態度決定方案的詳略
對于甲方客戶來說,如果解決方案中,充斥著大量專業詞匯,或方案中具有高度復雜的邏輯關系,甲方客戶大概率會“跳看”,反而達不到效果。因為人是懶惰的,花費太長的時間去了解一份方案,客戶很有可能沒有那么強的動力,方案要優先考慮客戶是否有讀下去的動力。
舉個例子,用一本書叫做《思考快與慢》,公認的好書,但是讀起來會很耗費時間。如果是自己買回來這本書,可能會一頁一頁的去看仔細的看,保障自己能吸收書中的每一個知識點,但是如果乙方客戶寫一份類似于《思考快與慢》如此復雜的解決方案發給了甲方,甲方客戶若對方案是非剛需,就沒有特別強的動力去仔細閱讀,一定是挑著閱讀,反而影響了方案的效果。
三 、如何寫解決方案
1. 開始前
多數方案的需求來自于領導、客戶或銷售,對方在描述方案背景、方案目的時候思維和表述是發散的,所傳達的信息不充分,如果這時就直接去寫方案,寫好之后對方會意識到還有信息點沒體現出來,往往會因此而返工。因此在方案開始前,需要了解清楚幾件內容:讀者、需求、現狀、目的、信息點。
(1)讀者
讀者就是方案的閱讀對象,希望發給誰。有時候方案的讀者不是一個人或一類人,是幾類人,例如經由系統集成商遞送給政府的方案,首先的讀者是系統集成商的人員,其次是政府,再復雜一些可能還會涉及到方案的最終應用方或監管方。
類似于此類方案,需要在方案中考慮到這幾類潛在讀者的需求,權衡各方的利益,滿足各方的訴求。針對系統集成商要體現出做這個事情有收益,有好處,對他們來說還不復雜;針對政府需要體現出方案對其有政績,有社會效益,最好花費還比較低……
對于讀者,最好可以對各類讀者進行讀者畫像。用戶畫像對于產品經理來說再熟悉不過了,筆者在寫解決前方案,一般對讀者的畫像會從幾個方面展開,認知程度,了解什么,不了解什么。認知程度就是對方的文化背景,知識水平,如對方是個體工商戶,未完成學業就開始創業,這一類方案不能寫的太高大深,高度太大反而不接地氣,讀者無法讀懂其中的價值。
關于了解什么,不了解什么就要看對方的工作內容,判斷對方是不是對一些概念,一些詞匯可以輕松讀懂,如若不能,就需要將概念進行展開。例如區塊鏈與智慧城市的結合方案,如果提交給政府,區塊鏈的概念就需要解釋,如果只提交給系統開發商或集成商,就不需要詳述區塊鏈是干什么的了。
(2)需求
需求即讀者想知道什么,為什么要知道,需要感受到什么。挖掘需求是產品經理的基礎工作,并不只是產品設計需要挖掘需求,寫文檔、寫方案也同樣需要挖掘需求。
挖掘需求的方法可以采用豐田公司的5why分析法,就是對一個問題連續問5個“為什么”,以找到需求背后的根本訴求。讀者想知道什么屬于what,讀者為什么要知道屬于why,讀者需要感受到什么屬于再深一層次的why,利用這種方法,找到讀者真正需要了解的內容,找到讀者真正的需求,好進行下一步的方案撰寫。
(3)現狀
現狀即做了什么,計劃做什么,什么不做。我們還是以區塊鏈和智慧城市的解決方案為例,智慧城市是一個泛泛的概念,包括智慧交通,智慧物流,智慧醫療等等,針對讀者,需要了解對方已經做好了哪些內容,這些內容是不是還需要新技術來融合,如若不需要,就沒必要在去寫這方面的解決方案了。
計劃做什么就是對方的計劃,近期計劃是你的重點,遠期計劃可以暢想。什么不做就是對方的邊界,對于政府、系統開發商都有自己負責的范圍(如智慧交通已經承包給其他開發商或由其他政府部門來負責),如果跨出了范圍,對方不會對這部分內容感興趣,就沒必要費筆墨費腦筋去寫了。
(4)目的
關于目的,要理清楚自己方案的主要目標和次要目標,多數情況目標就是為了滿足讀者的需求,也存在一些情況下方案就是為了拋磚,或者就是為了給對方搞暈(這種情況不多),目標不同寫方案的粒度和角度都會不同。其次要搞清楚方案的形式目標,是用于演講還是用于發送閱讀,演講在什么場地上進行,閱讀是電子還是打印。
(5)信息點
信息點就是要看交代方案的人有啥想法沒有,多數情況下給你交代方案的領導或者銷售,都會有一些自己的思路,他們是方案的第一讀者,需要先聽一聽他們的思路,思路不對需要給他們掰過來,否則方案都到不了目標讀者就會被否掉重新。
在信息點里面需要了解兩方面內容,一是期望表達的內容,二是切入點。
還是上面的例子,領導希望把區塊鏈的智能合約用到智慧城市里面,就是重要的一個信息點,雖然用其他的方式也可以滿足讀者的需求,但是方案畢竟要過領導一關,所以領導的需求也需要滿足。
切入點就是方案要從哪個點里面切入,例如區塊鏈在打通政務數據方面的解決方案,可以從多個角度、多個領域切入,可以通過民政領域的應用,打通各個部門的數據通道,也可以通過大數據領域的應用,來打通各部門數據,具體選定哪個領域,哪個切入點,是需要在寫方案之前明確的。
以上五點,筆者寫方案之前都會寫下來,寫到紙上,以防自己寫著寫著就偏離了目標,忘記了讀者,鉆到細節里面。
2. 方案標題
如果是非演講的文檔,標題和副標題至少有一個需要點明主旨。標題不是展示你是文藝青年的時候,讀者也不是去意會你的詩意,起一個含義極深的標題,和不用標題沒什么區別,白白浪費了標題的價值。
3. 方案內容
內容要根據上面所述的需求,目的和信息點來決定,內容沒有通用規則,需要根據實際情況來,例如解決方案的目標是介紹產品在特定行業的結合點,目標讀者已經和你之前進行過初步的交流,方案內容直接寫一兩頁內容甚至畫個流程圖都可以。下面幾個常見的內容方向供參考,根據實際情況自行選擇。
- 背景(可以參考金字塔原理的SQCA,情景、沖突、疑問、回答來描述方案的背景)
- 政法規(即政策、法規、法規,TO G方案常見,公務人員做事參考的標準)
- 產品功能(有時候一個方案會涉及多方用戶,一定要在描述產品功能時候告訴讀者這個功能的用戶是誰,例如智慧城市解決方案里面,涉及到的后臺系統,用戶是政府部門的管理者,涉及到的APP,用戶是城市居民還是執法人員,都需要重點突出,否則讀者容易混亂產品給誰來用。產品的用戶可以嘗試使用UML的用例圖來描述)
- 已有案例(有相關案例的話,一定要列上,大部分企業都不想做嘗鮮者,有成熟案例落地概率高很多)
- 方案效果(對于領導來說,都是“樂見其效”的,突出效果,突出意義方得讀者歡心)
- 方案優勢
- 核心流程
- 功能模塊
- 資源投入
- 實現周期
4. 方案內容查找來源
從0到1的編文字很痛苦,如果有現成的文字拿來使用自然輕松不少,反正方案又不查重。查找內容大家最先想到的就是利用搜索引擎,搜索引擎確實是個好途徑,但內容比較碎片化,以下兩個渠道可以參考。
渠道1:解決方案對應領域書籍、白皮書、研究院報告(例如:查找智慧城市主題的書籍、研究院報告,里面一定會提到區塊鏈的應用方式,結合點等信息);
渠道2:產品領域書籍、白皮書、研究院報告(例如:查找區塊鏈的書籍、研究院報告,里面會提到區塊鏈如何應用在智慧城市領域)。
5. 修改方案
方案寫好后需要通篇修改方案,修改方案需要先思考方案框架是不是正確,而后逐字逐句的刪詞改句;最后切記朗讀一遍,把內容改順耳,很多時候默讀、快讀確實沒問題,一旦朗讀就會發現文章的不順,切記朗讀一遍。
本文由 @產品工具箱 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
非常好的總結,謝謝樓主的分享
請問博主:公司從來沒做過某個產品,現在需要寫解決方案,可以從哪些角度入手?
白皮書、研究院報告等這些資料,可以推薦下查找方法嗎?
1、背景
2、政策法規
3、需求分析(業務需求、用戶需求、安全需求、響應需求等)
4、業務架構、平臺架構、功能架構……
5、系統詳述(業務流程+功能描述)
6、項目周期、計劃
7、項目預算
8、項目效益、成效
非常贊,細節處見經驗~
有沒有類似的案例模板能借鑒一下嗎
寫的不錯,如果各個模塊能再延伸講講就好了!