復盤:如何從 0 到 1 落地一個互聯網產品(下)
對于具有一定技術門檻,且業內暫無成功先例的工具型產品,市場具有一定可行性,且不說挑戰性,本文復盤并分享,筆者是如何落地一個帶有互聯網屬性的工具型產品的,作為對《復盤:如何從 0 到 1 落地一個互聯網產品》的補充和完善。
01
工具,是產品在用戶使用時會反映出一種屬性,這種屬性與用戶的目的性和對結果的預期明確度直接掛鉤。當用戶的目的越強,對過程和結果的預期越明確時,產品反映出的工具屬性就越強。
這里,筆者想分享 5 個概念,定位、互聯網思維、產品思維、全局思維 和 結構化思維,在產品的落地過程中,貫穿始終。
1. 定位
定位,是一個營銷概念。簡而言之,即鎖定細分市場,描繪受眾畫像,攻占受眾心智,在其大腦中牢牢地打下一塊革命根據地。
打法,可以借鑒里斯特勞特前輩的定位策略,“不是植入全新的、不一樣的東西,而是操控已有的認知,將已有的關聯認知重新進行組合?!北热纾好慨敯菰L長輩,“今年中秋不送禮,送禮,就送腦白金”。
對于工具型產品的產品定位,5W2H同樣適用,即要做一個什么樣的產品,給誰用,達到什么樣的效果。
2. 互聯網思維
互聯網思維,即用戶至上的思維,以用戶需求為驅動,并更好地滿足用戶需求。工業思維更多是從設計者出發,提現更多的是技術和功能,而互聯網思維則是從用戶角度出發,無論產品技術如何厲害,只追求用戶使用的方便和愉悅,(引自郝志中)。
比如:小米系列的產品,從產品的設計到推向市場,每一環節都有用戶參與,參與并提供有價值的leads,還可獲贈 F 碼,享受優先購買的專屬權利。
水能載舟,亦能覆舟,得用戶者得天下,是有一定道理的。所以,在工具型產品的需求收集及分析環節,要與產品的最終使用者,做到充分的溝通,真正了解用戶的需求,并全力滿足用戶的需求。
再如:CRM,核心的使用對象是銷售,是“吸引并保持有經濟價值的客戶,驅逐并消除缺乏經濟價值的客戶”,在 ISO 9000族標準 2000 版對1994 版標準的重大改良是提出“以客戶為關注焦點”。
3. 產品思維
產品思維,也可以叫做玩具思維,即在滿足基本的功能需求外,賦予用戶感官刺激、情感享受,滿足其玩樂訴求的產品戰略觀,這里,筆者不再贅述。
4. 全局思維和結構化思維
全局思維和結構化思維,需要自己把控,這里筆者不做過多陳述,推薦讀芭芭拉明托的金字塔原理。這里,筆者摘述一些基本概念。
基本結構:結論先行,以上統下,歸類分組,邏輯遞進。先重要后次要,先總結后具體,先框架后細節,先結論后原因,先結果后過程,先論點后論據。
具體做法:自上而下表達,自下而上思考,縱向總結概括,橫向歸類分組,講故事,提煉思想精華。
02
Step 1:研究業內已有的業務流程
以DMS系統為例,其業務流程為:
- 對于紙質類,檔案歸檔——檔案管理——檔案入庫(對于紙質類)——檔案使用;
- 對于電子類,電子文件產生——分散或集中存放——拷貝共享。
仍以地產行業的 CRM 為例:
先導期(紙媒/傳媒/互聯網,廣而告之)——拓客期(小蜜蜂、全民經紀人、置業顧問等獲取客戶資源,并邀請至案場)——跟進期 (定時跟進客戶,關注客戶的購買意向,洗客)——銷售期——業主管理。
再如保險行業:主顧開拓——約訪——銷售面談——成交面談 ——服務與轉介紹——定期維護。
Step 2:業務調研,收集問題
根據已確定的業務流程,針對每一關節,準備問題,進行調研。
通常,這是一個相對比較辛苦的過程,需要浸泡在一線實際業務場景中,親身體驗,如果實際業務的開展中用到的有其他工具產品,那么,需要研究并掌握工具的基本使用方法,如此有助于發現痛點,形成思路閉環。具體不再詳述。
Step 3:問題整理,分析痛點
以DMS 系統為例,通過調研,可以總結出 5 類問題,如下:
- 安全問題:丟失、泄密、越權、損壞等;
- 效率問題:找檔案的時間比看檔案的還多,想必大部分童鞋應該都有過此番經歷,這里筆者不再舉例實際的場景;
- 兼顧問題:電子和紙質檔案的管理,比如:投標文書,通常是兼具電子和紙質版,參加招標——中標——簽合同,相關的電子和紙質版資料,均會存檔,為使電子版與紙質資料一一對應起來,這樣在項目交付時,便可有跡可循;
- 協作問題:歸檔、借閱的過程存在障礙;
- 分散問題:電子或紙質檔案越來越多,而且分散;比如:對于一家 Base 在城市 A,而在城市 B ?城市 C 均設有 branch 的公司,就會存在文檔分散的問題。
Step 4:針對痛點,確定定位,再借助產品思維,輸出產品架構圖
根據 Setp 3 的產出,將確定需要解決的痛點,轉化為產品,即,轉化為一種可以通過可視、可操作的功能的集合,解決痛點。接下來,對功能進行歸類,形成功能模塊,確定模塊的定位,并劃分層級。
這里,即是對全局思維和結構化思維的運用。在確定產品架構圖的時候,也要對研發的實現方式有一定的認知,并且,要明白該產品需要與哪些已有且在使用的工具型產品進行數據層面的交互,這樣有助于產出具有前瞻性的產品架構圖,可參考下方DMS系統的產品架構圖。
以 CRM 為例。
美國的Burghard 和 Galimi 教授認為:
“CRM是一個圍繞客戶需要和需求、重新設計企業及其業務流程的信息技術(IT)驅動的概念,它將一系列方法、軟件及互聯網接入能力同企業的以客戶為核心的商業戰略相結合,致力于利潤、收益和客戶滿意度的提高?!?/p>
這里,分享下 CRM 的產品架構圖,對于客戶滿意度的考量方式,業內有很多成熟的教科書式解決方案,這里筆者不做搬運工,請自行查閱。
圖一
以 DMS 系統為例:針對調研已發現的問題,可以通過 DMS 從檔案的采集、歸檔、整理、展現、使用到借用等方面進行一站式管理,進而實現檔案資料的一體化、標準化、規范化和共享化管理。
這里,可以再加上統計相關的功能,方便查看某一時期,采集到的文檔的數量,從哪里采集,采集到的文檔的類型(.doc、.cad、.wmv 或者其他)等。
圖二
Step 5:輸出腦圖
上一篇文章中,筆者分享,通過對接競品售前、試用競品的方式來輸出腦圖,但是,對于業內暫無成熟產品案例的工具型產品,就不能那么做了。
此時,在 Step 4 中,需要根據產品架構圖,進行角色梳理,并加上信息流走向,再運用結構化思維,以上統下,邏輯遞進,對功能模塊進行細化,即要使該功能模塊實現定位,需要哪些子功能模塊或功能來進行支撐,逐一列舉,如此,便形成了腦圖。
如果不同角色對應各自獨立的產品體系,則有幾個角色,就需要出幾張腦圖。
以CRM中的置業顧問和銷售經理為例:
CRM_地產行業_置業顧問(請關注腦圖的顆粒度及形式,做到清晰即可)
CRM_地產行業_銷售經理(請關注腦圖的顆粒度及形式,做到清晰即可)
Step 6:畫原型
該步,略。Practice?makes?perfect.
Step 7:補流程圖
對于一款業內暫無成熟案例的產品,在完成 Step6 中的原型規劃后,需要補一些核心的狀態機圖和功能流程圖,便于在 Step 8 中,與大家溝通。
工具型產品的規劃,需要一條能夠根據業務流程將各功能模塊串聯起來的線(也即形成閉環),而這條線的業務模式設計,需要從核心受眾的業務痛點出發來做規劃,進而吸引核心受眾,愿意使用產品,并從使用中獲得快樂。
比如:筆者實戰的項目,是通過狀態機圖的設計來完成閉環,出發點是解決一項筆者認為的核心痛點,在后來評審環節的頭腦風暴中,得到了大家的認同,并集思廣益進行了完善(Ps. 這張圖不便分享,掌握狀態機圖的畫法,根據實際業務場景,靈活貫通,即可)。
筆者認為:這里和電影劇情的策劃,異曲同工,比如黃渤的一出好戲,有2條線,一條是故事主線一場災難,一座荒島,一群人,在一個全新的世界,重置生存規則,上演了一出好戲,還有一條線是馬進與女一號的感情線,為影片增添了一絲柔和的色彩。
對于功能流程圖,這里,筆者以 CRM 的一個痛點為例。
業務場景:
假使某案場有一客戶 A ,屬于置業顧問小組 G1 中的甲大錘。如果自添加之日起,15 天內,甲大錘沒有以任何形式聯系A(即沒有維護跟進記錄),則客戶A的信息將流轉給G1的甲大棍。
同樣,如果15天內,甲大棍也沒有以任何形式聯系 A,則客戶A的信息,將流轉給 G1 的甲棒槌,如果甲棒槌也在15天內沒有以任何形式聯系A,則該客戶的信息將流入公海。
解決辦法:
以甲大錘、甲大棍和甲棒槌在 15 天內是否錄入跟進信息為判斷依據,根據一定的規則來對客戶 A 的信息進行流轉,最終流轉至 公海。
相關的功能流程圖如下:
Step 8:組織評審,頭腦風暴
在大型的外包項目中,通常組織評審的是項目經理,組織評審是一項基本技能,提前告知各干系人時間、地點、時長和評審主題,將大家組織到一起即可,因情況而異,靈活把控,注意溝通技巧就好。
對于一款業內暫無成熟案例的工具型產品,頭腦風暴是一個很重要的團隊協作過程,尤其是需要核心調研對象參與,讓其對解決方案進行審查,流程設計是否貼合其實際操作業務的模式,各關節的信息是否有遺漏。
根據實戰情況,頭腦風暴的過程一般很長,而且需要輪番作戰,即一輪評審結束后,根據會議紀要,對原型和相關的 flow 圖進行修改和完善,然后二輪評審,三輪評審… 直至大家達成共識,對解決方案均一致認可。
筆者推薦芭芭拉明托的金字塔原理,對于溝通效率的提升有幫助。
Step 9:輸出需求規格說明書/PRD,確定里程碑,交付研發
Step 8 結束后,即可開始寫需求規格說明書,直觀高效,并補充相關的功能流程圖、數據流圖(筆者認為,以表格的形式,寫清楚也可)和狀態機圖等。確定里程碑,交付研發,日常跟進即可。
Step 10:測試,驗收,部署上線
知己不足而后進,望山遠歧而前行。當接觸到不同類型的產品到一定量后,即使是面對不曾涉足的領域的產品,也會觸類旁通。
僅復盤分享,如有不到之處,請輕噴。
本文由 @白鳥 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
不錯!整個過程描述得很清晰,不過就是沒啥可以落地的干貨,sigh
這是一篇方法論,也有例證,落地的干貨,挺多的呀。
謝。請問,你希望得到哪些落地的干貨呢?:)
ps. 本文所提及的項目,是性能測試領域的一個工具平臺,偏技術層面,不方便講,所以,文章是以之前的實戰經歷作為案例來展開的。