復盤:如何從0到1落地一個網際網路產品(下)

對於具有一定技術門檻,且業內暫無成功先例的工具型產品,市場具有一定可行性,且不說挑戰性,本文覆盤並分享,筆者是如何落地一個帶有互聯網屬性的工具型產品的,作為對《覆盤:如何從 0 到 1 落地一個互聯網產品》的補充和完善。

复盘:如何从0到1落地一个互联网产品(下)

01

工具,是產品在用戶使用時會反映出一種屬性,這種屬性與用戶的目的性和對結果的預期明確度直接掛鉤。當用戶的目的越強,對過程和結果的預期越明確時,產品反映出的工具屬性就越強。

這裡,筆者想分享 5 個概念,定位、互聯網思維、產品思維、全局思維 和 結構化思維,在產品的落地過程中,貫穿始終。

1. 定位

定位,是一個營銷概念。簡而言之,即鎖定細分市場,描繪受眾畫像,攻佔受眾心智,在其大腦中牢牢地打下一塊革命根據地。

打法,可以借鑑里斯特勞特前輩的定位策略,“不是植入全新的、不一樣的東西,而是操控已有的認知,將已有的關聯認知重新進行組合。”比如:每當拜訪長輩,“今年中秋不送禮,送禮,就送腦白金”。

對於工具型產品的產品定位,5W2H同樣適用,即要做一個什麼樣的產品,給誰用,達到什麼樣的效果。

2. 互聯網思維

互聯網思維,即用戶至上的思維,以用戶需求為驅動,並更好地滿足用戶需求。工業思維更多是從設計者出發,提現更多的是技術和功能,而互聯網思維則是從用戶角度出發,無論產品技術如何厲害,只追求用戶使用的方便和愉悅,(引自郝志中)。

比如:小米系列的產品,從產品的設計到推向市場,每一環節都有用戶參與,參與並提供有價值的leads,還可獲贈 F 碼,享受優先購買的專屬權利。

水能載舟,亦能覆舟,得用戶者得天下,是有一定道理的。所以,在工具型產品的需求收集及分析環節,要與產品的最終使用者,做到充分的溝通,真正瞭解用戶的需求,並全力滿足用戶的需求。

再如:CRM,核心的使用對象是銷售,是“吸引並保持有經濟價值的客戶,驅逐並消除缺乏經濟價值的客戶”,在 ISO 9000族標準 2000 版對1994 版標準的重大改良是提出“以客戶為關注焦點”。

3. 產品思維

產品思維,也可以叫做玩具思維,即在滿足基本的功能需求外,賦予用戶感官刺激、情感享受,滿足其玩樂訴求的產品戰略觀,這裡,筆者不再贅述。

4. 全局思維和結構化思維

全局思維和結構化思維,需要自己把控,這裡筆者不做過多陳述,推薦讀芭芭拉明託的金字塔原理。這裡,筆者摘述一些基本概念。

基本結構:結論先行,以上統下,歸類分組,邏輯遞進。先重要後次要,先總結後具體,先框架後細節,先結論後原因,先結果後過程,先論點後論據。

具體做法:自上而下表達,自下而上思考,縱向總結概括,橫向歸類分組,講故事,提煉思想精華。

02

Step 1:研究業內已有的業務流程

以DMS系統為例,其業務流程為:

  • 對於紙質類,檔案歸檔——檔案管理——檔案入庫(對於紙質類)——檔案使用;
  • 對於電子類,電子文件產生——分散或集中存放——拷貝共享。

仍以地產行業的 CRM 為例:

先導期(紙媒/傳媒/互聯網,廣而告之)——拓客期(小蜜蜂、全民經紀人、置業顧問等獲取客戶資源,並邀請至案場)——跟進期 (定時跟進客戶,關注客戶的購買意向,洗客)——銷售期——業主管理。

再如保險行業:主顧開拓——約訪——銷售面談——成交面談 ——服務與轉介紹——定期維護。

Step 2:業務調研,收集問題

根據已確定的業務流程,針對每一關節,準備問題,進行調研。

通常,這是一個相對比較辛苦的過程,需要浸泡在一線實際業務場景中,親身體驗,如果藉助有工具,要研究並掌握工具的基本使用方法,如此有助於發現痛點。具體不再詳述。

Step 3:問題整理,分析痛點

以DMS 系統為例,通過調研,可以總結出 5 類問題,如下:

  1. 安全問題:
    丟失、洩密、越權、損壞等;
  2. 效率問題:找檔案的時間比看檔案的還多,想必大部分童鞋應該都有過此番經歷,這裡筆者不再舉例實際的場景;
  3. 兼顧問題:電子和紙質檔案的管理,比如:投標文書,通常是兼具電子和紙質版,參加招標——中標——籤合同,相關的電子和紙質版資料,均會存檔,為使電子版與紙質資料一一對應起來,這樣在項目交付時,便可有跡可循;
  4. 協作問題:歸檔、借閱的過程存在障礙;
  5. 分散問題:電子或紙質檔案越來越多,而且分散;比如:對於一家 Base 在城市 A,而在城市 B 城市 C 均設有 branch 的公司,就會存在文檔分散的問題。

Step 4:針對痛點,確定定位,再借助產品思維,輸出產品架構圖

根據 Setp 3 的產出,將確定需要解決的痛點,轉化為產品,即,轉化為一種可以通過可視、可操作的功能的集合,解決痛點。接下來,對功能進行歸類,形成功能模塊,確定模塊的定位,並劃分層級。

這裡,即是對全局思維和結構化思維的運用。在確定產品架構圖的時候,也要對研發的實現方式有一定的認知,並且,要明白該產品需要與哪些已有且在使用的工具型產品進行數據層面的交互,這樣有助於產出具有前瞻性的產品架構圖,可參考下方DMS系統的產品架構圖。

以 CRM 為例,不再贅述。

美國的Burghard 和 Galimi 教授認為:

“CRM是一個圍繞客戶需要和需求、重新設計企業及其業務流程的信息技術(IT)驅動的概念,它將一系列方法、軟件及互聯網接入能力同企業的以客戶為核心的商業戰略相結合,致力於利潤、收益和客戶滿意度的提高。”

這裡,分享下 CRM 的產品架構圖,對於客戶滿意度的考量方式。

复盘:如何从0到1落地一个互联网产品(下)

圖一

以 DMS 系統為例:針對調研已發現的問題,可以通過 DMS 從檔案的採集、歸檔、整理、展現、使用到借用等方面進行一站式管理,進而實現檔案資料的一體化、標準化、規範化和共享化管理。

這裡,可以再加上統計相關的功能,方便查看某一時期,採集到的文檔的數量,從哪裡採集,採集到的文檔的類型(.doc、.cad、.wmv 或者其他)等。

复盘:如何从0到1落地一个互联网产品(下)

圖二

Step 5:輸出腦圖

上一篇文章中,筆者分享,通過對接競品售前、試用競品的方式來輸出腦圖,但是,對於業內暫無成熟產品案例的工具型產品,就不能那麼做了。

此時,在 Step 4 中,需要根據產品架構圖,進行角色梳理,並加上信息流走向,再運用結構化思維,以上統下,邏輯遞進,對功能模塊進行細化,即要使該功能模塊實現定位,需要哪些子功能模塊或功能來進行支撐,逐一列舉,如此,便形成了腦圖。

如果不同角色對應各自獨立的產品體系,則有幾個角色,就需要出幾張腦圖。

以CRM中的置業顧問和銷售經理為例:

复盘:如何从0到1落地一个互联网产品(下)

CRM_地產行業_置業顧問(請關注腦圖的顆粒度及形式,做到清晰即可)

复盘:如何从0到1落地一个互联网产品(下)

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 的信息進行流轉,最終流轉至 公海。

相關的功能流程圖如下:

复盘:如何从0到1落地一个互联网产品(下)
复盘:如何从0到1落地一个互联网产品(下)复盘:如何从0到1落地一个互联网产品(下)
复盘:如何从0到1落地一个互联网产品(下)

Step 8:組織評審,頭腦風暴

在大型的外包項目中,通常組織評審的是項目經理,組織評審是一項基本技能,提前告知各干係人時間、地點、時長和評審主題,將大家組織到一起即可,因情況而異,靈活把控,注意溝通技巧就好。

對於一款業內暫無成熟案例的工具型產品,頭腦風暴是一個很重要的團隊協作過程,尤其是需要核心調研對象參與,讓其對解決方案進行審查,流程設計是否貼合其實際操作業務的模式,各關節的信息是否有遺漏。

根據實戰情況,頭腦風暴的過程一般很長,而且需要輪番作戰,即一輪評審結束後,根據會議紀要,對原型和相關的 flow 圖進行修改和完善,然後二輪評審,三輪評審… 直至大家達成共識,對解決方案均一致認可。

筆者推薦芭芭拉明託的金字塔原理,對於溝通效率的提升有幫助。

Step 9:輸出需求規格說明書/PRD,確定里程碑,交付研發

Step 8 結束後,即可開始寫需求規格說明書,直觀高效,並補充相關的功能流程圖、數據流圖(筆者認為,以表格的形式,寫清楚也可)和狀態機圖等。確定里程碑,交付研發,日常跟進即可。

Step 10:測試,驗收,部署上線

知己不足而後進,望山遠歧而前行。當接觸到不同類型的產品到一定量後,即使是面對不曾涉足的領域的產品,也會觸類旁通。

僅覆盤分享,如有不到之處,請輕噴。

題圖來自Unsplash,基於CC0協議


分享到:


相關文章: