接手新項目,落地產品前要先能「想清楚」,才能「做明白」
編輯導語:產品經理接手一個新項目之后,做好業務梳理和方案規劃非常重要,這有利于更快地推進工作;并且在產品落地前,需要通過不斷的檢測,實施線下巡檢標準化等等;本文作者分享了關于復盤項目的經歷以及實踐經驗,我們一起來看一下。
從入行產品到現在的 2 年時間里,自己做過了不少項目,比如現在的:線下巡檢標準化、員工行為管理系統等等。
但一直沒有體系化的復盤這些經歷,為了能讓這些實踐成為自己的經驗,接下來決定對它們做個總結。
下面,先從線下巡檢標準化這個項目開始,希望我的思考能帶給你一些啟發。
一、什么是線下巡檢標準化
公司服務的客戶,業務上會通過線下巡檢的方式,管理旗下門店的日常運營情況;而我們是將這種業務模式產品化,幫助對方更有效率的開展工作。
這類服務模式的 SaaS 產品,屬于支持客戶業務開展的一種手段,幫助這一類存在相同痛點問題的客戶,為公司創造商業價值。
二、為什么要做線下巡檢標準化?
這是我入行產品做的第 1 個大項目,從參與到主導,雖然當時做得懵懵懂懂,但通過事后復盤,發現很多信息都藏在了日常溝通中。
后來我發現,無論是做產品規劃,還是落地項目,遵循自上而下的思考模式,能幫助我們「更有效地厘清做事的思路,避免事后返工浪費公司資源」,以我這次做的項目為例去分析:
1. 公司定位
公司提供的是視頻監控運營服務,通過接入客戶門店內的攝像頭,對監控畫面進行切片、過濾等處理方式,關注客戶指定的員工行為,定期告知客戶。
PS:不同行業的客戶,接入攝像頭的線下單位的叫法會有不同,比如餐飲、零售行業等叫做門店;消防、工地等叫做站點;學校叫做校區或幼兒園;考慮公司服務的客戶,大部分是餐飲行業,所以下面統一叫做「門店」。
1)客戶有哪些?
連鎖品牌這類 B 端客戶,以及政府、企業級的客戶。
2)要解決客戶的什么問題?
第 1 類客戶:連鎖品牌這類 B 端客戶(餐飲為主)
隨著客戶門店數量的增多,為了提高管理效率和透明度,客戶會制定員工行為巡視標準,規范管理門店,比如:員工著裝是否規范、后廚是否有人吸煙、倉庫是否有老鼠等。
客戶購買我們的服務,希望能在營業日抓拍員工行為,獲取門店日常工作開展規范情況,并輔助他們獎懲、整改門店。
第 2 類客戶:政府、企業級的客戶(餐飲和工地項目為主)
根據政府監管要求,為了避免安全事故的發生和隱患,客戶會通過場地的攝像頭進行監管。
以工地的業務場景為例,客戶購買我們的硬件盒子和算法服務,比如:未戴安全帽、渣土車密閉等,攝像頭會基于算法實時抓取特定行為;再配置專門負責監管違規的員工,處理告警反饋的違規情況。
3)解決思路
為了解決客戶的這些問題,基于客戶的特性,我們提供了兩類服務:
- 自運營:將產品(全部權限的后臺 + App)交付給客戶,由對方自行安排運營人員管理門店,以及自行推送員工行為的報告。
- 代運營:將產品(部分權限的后臺 + App)提供給客戶,由我們提供運營服務,客戶只需接收員工行為的報告推送,再確定后續的業務處理流程,看是否需要獎懲或整改。
這兩者最大的區別,在于員工行為是由我們的運營人員抓取推送給客戶(代運營),還是由客戶自己的員工抓取推送(自運營)。
至于這么做的原因,是因為大部分客戶的門店數量少,配置人員管理的成本高。
因此,對于連鎖品牌的 B 端客戶,大多是以代運營為主,少數門店多、信息化程度高的客戶,會選擇自運營。
而對于政府、企業級客戶來說,都是以自運營的硬件設備 + 軟件產品的方式提供服務。
2. 產品定位
基于公司定位,推導產品定位。
1)用戶群體有哪些?
- 外部客戶:自運營和代運營模式下的客戶,以及服務代理商。
- 內部客戶:代運營模式下的公司運營人員。
2)提供了哪些產品,產品的定位分別是什么?
- 線下巡檢產品:為客戶提供門店的線下巡檢管理工具,提供不同業務下的規范管理、任務制定等相關的運營支撐能力。
- 線上巡視產品:為客戶提供門店的線上巡視管理工具,通過人工運營服務,提供靈活的員工行為抓取,以及報告審核與推送等相關的運營支撐能力。
- 算法盒子產品:逐步支撐工地和后廚環境下的監測管理流程,為政府、項目承包方等大型客戶提供場景化告警的能力,提升處理違規的響應速度,降低事故發生的風險。
3)用產品做什么?
整理上面的信息,得到下圖:
以我的項目為來說,通過客戶類型、服務模式、用戶群體可以發現,線下巡檢產品其實屬于線上巡視產品在業務上的延伸。
要知道,公司的核心產品之一是線上巡視產品,基于銷售回訪發現客戶的續費率很低,通過調研發現客戶覺得違規行為推送服務,「只能發現問題,缺少解決問題」的手段。
PS:員工行為分正面,比如按時上下班、閑暇時間練習剪發(美容美發行業),和負面,比如后廚吸煙、收餐不及時(餐飲行業);大多數客戶實行多罰少獎的業務模式,因此員工行為推送大多為違規行為推送。
于是,產品團隊通過調研發現,客戶會定期派人線下巡檢門店,發現違規問題會要求門店負責人改掉,但目前的業務模式會存在以下問題:
- 管理層:拿到領導制定的巡檢標準和規范,由于門店數量多、分布廣,無法合理分配巡檢資源,比如規多的門店多抽查幾次、扣分頻率高的項多關注等。
- 執行層:由于要求多、人員變動不了解業務、檢查位置不同等問題,因此容易執行錯、漏,不僅巡檢效率低,還會因巡檢問題導致門店負責人被罰錢。
因此,因為公司為了補足「解決問題」這個能力,再加上目標客戶業務上存在的問題,我們決定通過產品提供一套標準化的解決方案。
三、線下巡檢標準化的設計思路?
在理完「為什么做」之后,接下來才是思考「產品該怎么做」,同樣是按照自上而下的思維模式。
1. 產品的預期和目標
基于產品定位,推導在理想狀態下,我們需要提供什么能力,解決客戶在哪些具體場景下的哪些問題?
1)具體場景有哪些?
調研標桿客戶的線下巡檢后,梳理業務流程提煉后:巡檢跟蹤 → 違規整改 → 數據犯規 → 門店獎懲。
- 巡檢跟蹤:制定巡檢標準和規范,指派給對應角色完成線下巡檢。
- 巡檢反饋:門店負責人收到巡檢結果,對巡檢結果做整改或申訴,再由巡檢員審核結果。
- 數據反饋:展示統計結果,為客戶提供門店巡檢的決策依據。
- 門店獎懲:基于巡檢結果,客戶可對員工進行獎懲。
2)基于這些場景,我們應該提供什么樣的產品能力?
① 巡檢跟蹤:支持多業務場景下的派發任務
錄入模板:根據多個標桿客戶提供的巡檢模板,梳理歸納之后如下圖:
任務下派:根據客戶實際派發任務的場景,比如:
- 普通任務:正常派發單個任務;
- 重復性下派的任務,提供「周期性任務」自動下派的解決方式;
- 抽查巡檢的模式,提供「抽檢任務」的檢查方式;
- 任務執行:支持在 App 上完成巡檢;
- 巡檢結果查看:針對客戶領導層、管理層、執行層 3 種細分的用戶群體,支持在 PC 和 App 上查看巡檢結果。
- 巡檢結果導出:為了客戶留檔、二次數據分析等場景,需要支持客戶定期導出巡檢結果數據。
- 巡檢結果通知:為了便于及時的整改和申訴,需要在門店巡檢任務提交后,通知門店相關人。
② 巡檢反饋
巡檢項的整改 / 申訴與審核:屬于在巡檢業務上的延伸,具體來說:
- 巡檢結果無誤:門店負責人需要承認結果,并整改違規;
- 巡檢結果存疑:門店負責人可以提出申訴,反饋給巡檢員審核;
- 創建事件:支持對巡檢結果存在質疑的人發起整改、整改后提交審核、以及發起申訴的業務場景。
③ 數據反饋
巡檢結果統計:根據業務需要,在后臺系統中展示統計數據,比如:任務完成情況、得分情況、違規情況等。
④ 門店獎懲
員工行為獎懲:根據線上巡視,和線下巡檢的結果,為客戶獎懲員工提供理論支持。
2. 產品的現狀和能力
基于 01 產品的預期和目標,在希望解決的客戶問題的具體場景中,我們已經覆蓋了哪些能力?
接手這個項目時,產品流程并不符合業務流程,同時產品邏輯上也有缺失,因此需要重新規劃和設計整套系統。
3. 產品欠缺的能力
根據產品的預期和目標和產品的現狀和能力,推導產品目前還需要的能力,如下圖所示:
4. 產品的規劃和優先級
基于產品欠缺的能力,明確接下來該怎么做。
當時線下巡檢產品屬于業務探索期,從產品規劃上分為 3 個階段:
- 優先調整產品邏輯,使產品邏輯能夠符合真實的業務流程;
- 補充業務流程下的基礎功能,支持多業務場景上的使用;
- 跟線上巡視產品結合,深入到目標客戶的關鍵業務流程中;
根據產品發展方向,推導認為要做的事情,以及事情間的優先級,如下圖所示:
以上,就是我復盤這次項目帶來的經驗總結,其實都是在圍繞:要做什么?為什么要做?這兩個點去論證。
在想清楚這些之后,后面再落地產品邏輯時就是順理成章的事情。
四、線下巡檢標準化的產品邏輯?
在明確設計思路之后,剩下的就是將邏輯產品化,這里以階段1:優先調整產品邏輯為例,可以分為以下 3 個階段:
1. 巡檢前:錄入信息,下派任務
1)品牌列表
當客戶購買線下巡檢產品后,由我們負責在系統中新增對應的品牌。
2)架構設置
由客戶自己錄入自己品牌的層級架構,即品牌 → 區域(N個) → 門店的樹狀層級關系。
3)用戶列表
客戶按已建好的架構,在不同的層級下關聯人員,比如:區域關聯的人,通常為區域負責人或督導;門店關聯的人,通常為門店負責人、店員。
4)模板列表
客戶客按設計思路中模板類型,錄入巡檢的模板,同時支持兩個層級的分類。
5)任務列表
客戶針對不同的業務場景,可選擇是否使用模板,以要執行的門店為單位派發任務。
2. 巡檢中:員工執行,上傳結果
1)App接收和執行任務
到了任務開始時間,客戶的員工會在App上看到任務,按照模板執行后提交。
3. 巡檢后:展示和通知結果
1)App查看和通知結果
單條門店結果提交后,與門店關聯的人就能收到反饋通知。
五、寫在最后
現在回想起來,這個項目本身的邏輯并不難,但因為自己第 1 次逐步接觸完整的項目,再加上自己的經驗有限,所以還是做了很多“錯誤”的決策。
從這次實踐中,我總結出了幾條經驗:
1)自上而下的思考產品為什么做?要做什么?(思路參照文章的二和三)
否則直接上手,會讓我們陷入做事,但看不清效益的無用功之中。
2)B 端產品服務于業務,想不明白、做不完整是因為缺失了某些業務信息。
因此,找最懂業務的人去確認自己的理解是否準確、是否缺失,接下來再去落地產品。
#專欄作家#
空,公眾號:小木盒產品記,人人都是產品經理專欄作家。一名在迷茫道路上,成長前進的B端SaaS產品人。希望能通過不斷思考、不斷復盤,讓自己成為一個思考有深度,表達有條理的產品人。
本文原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自?Unsplash,基于 CC0 協議
- 目前還沒評論,等你發揮!