獨立負責CRM線索的感悟:初級PM如何獨立負責陌生需求

2 評論 3388 瀏覽 20 收藏 10 分鐘

作為一名初級產品經理,自己要做需求的提出者,對市場競爭格局做出判斷,監控競品,持續做產品迭代策略,滿足用戶不斷升級的需求。然而在更多的時候,需求主要來源老板/業務部門甚至是兄弟部門。面對錯綜復雜的業務背景以及陌生的領域,要如何進行調研,設計出業務滿意的需求呢?下面這篇文章是筆者以初級產品的角度并結合脫敏實例(CRM系統線索模塊),來闡述接到一個陌生需求是怎么樣進行梳理的。希望對同為初級的產品你有所啟發。

一、調研前務必敲定需求范圍

如果業務有明確的需求清單很好辦,如果沒有,需要和業務確定本次迭代的背景是什么,做成這一功能的目的是什么?確定這點,相當于有了一個指導的方針,既避免了需求范圍過小,影響業務的正常使用;也避免了需求范圍過大,造成了功能的過度堆砌,產研的壓力過大。

舉例:在本人接到線索這一模塊時,有幾個思考問題需要問下業務。

  • 要確認下,為什么要做這一模塊,原來的系統不滿足銷售部門的需求了嗎,是當前系統使用過程? ? ? 中遇到了什么困難嗎?
  • 對于新系統,你最希望能滿足什么需求?
  • 針對上面的回答進一步深挖場景….

調研得出結論:原CRM系統線索有效信息無效信息沒有做區分,不易挖掘有效客戶,且客戶質量不一,沒有對潛客做分層,不利線索分配。因而需要改造線索,上去承接流量,下去承接商機,支持線索可以按照分類、等級推給不同的銷售人員。

畢竟有了好線索,才有后續的訂單和客戶。因而我們1.0最核心的需求是解決線索質量的問題,產品側最重要的是做線索分發/流轉/回收策略,以及支持該功能對應的線索分配/線索回流相關流程…..

知道了需求要做什么僅是第一步,接下來要解決的是如何做的問題。

二、了解業務流程與系統流程

對一個不了解的業務場景,你起初很難厘清業務都有哪些要素,以及這些要素是如何組合實現產品價值的,即使是看了大量競品,知道了以上問題的答案,知道了線索可能包含某幾個列表,都有什么什么字段,看似是能夠設計出產品來了,但最終的結果不一定適合本公司的業務實際訴求。所以在方案的設計中,不要過分沉迷于大而全的“標品”,而是去針對公司的實際情況去設計。

對此,可以請教相關業務,詢問一線人員的期望。甚至初期可以提一些開放性的問題。例如:你們目前作業的業務流程是什么?當然,若是原有流程就在線上,只是做一個迭代,完全可以測試環境先看下這塊功能,采用封閉式提問的方式獲取業務需求。

  • 比如線索主要都來源哪幾個渠道?
  • 當前我們市場得到一條線索,這個線索的生命周期是什么?
  • 線索我們是線索扭轉流程是什么?是xxxx→xxxx→xxxx→xxxx嗎?
  • 線索是因為什么原因才觸發回收?
  • 銷售假如沒及時跟進,會扣績效嗎?
  • ……以下省略N多提問的問題……

以上問題是為了我們更清晰業務流,避免需求設計不落地。除了關注業務流外,也要清晰系統流,針對業務場景,了解相關上下游系統的作用,避免僅改造單一系統,導致產品邏輯出現問題。

在這個過程中,流程圖是一個很好的助手,可以幫助我們將系統以及業務流程做結合,即什么角色(who)在什么場景下,在哪個系統中(where)能做什么/不能做什么(what),流程圖和業務方進行確認,確保我們與業務的理解沒有過大的偏差。

同時需求調研階段,需求不僅僅是問出來的,如果僅靠詢問,那么效率太低了。也可以進行競品分析,如自己主動去了解市場主流CRM的線索都是如何收集、分發、流轉、回收等。

三、競品分析與用戶調研

調研業務流和系統流其實和競品分析用戶調研階段不一定是一個前后的階段,兩者有可能并行。

在設計階段,你可以多體驗下競品。它山之石可以攻玉,首先對市場的頭部玩家進行調研,分析該功能,頭部是怎么做的?1)目的是什么?這個功能適合我們的系統嗎?2)詳細拆解功能點,都涉及哪些字段?字段的作用?目的?流程/角色?(可以不做競品分析報告,但要了然于胸這些問題的答案)

沒有太大問題后,需求調研環節告一段落。

這時要注意!一定要把你設計的藍圖給業務,看你的設計是否滿足了TA的需求。比如說可以給他拿功能字段清單、原型等。

如果他確認沒有問題了,正式進行需求的撰寫工作。以上是為了讓你清晰的知道如何做,現在是正在開始動筆,產出可以供研發測試團隊、設計團隊進行開工的產物了。

四、產品需求評審四大件

每個團隊的產出物要求都不一致。就我目前團隊而言,需求產出離不開:功能清單、流程圖、原型、需求文檔,這四樣堪稱評審必備四大產出物。由于本文重點放在初級PM如何去針對陌生場景去設計產品,故而較大篇幅都放在了調研的階段,故而以下內容就簡單描述了,如果后續文章點贊量高(*^▽^*),也可以去把這塊完善一下,單獨開一個文(明目張膽的要點贊哈哈哈)。

1. 功能清單

功能清單主要是便于給研發團隊們預估工期。沒有明確的格式與要求,只要清晰即可。再者,是你的一個思考工具,為了不漏需求。

2. 流程圖(復雜流程)

流程圖主要是需求評審時能更加清晰的將產品設計傳達給其他小伙伴,當然隨你心意,只要業務邏輯清晰,足夠開發小哥哥or小姐姐會后也能毫不費力想起來這個流程,不畫也是可以滴。

以下是我畫的CRM線索流程圖,主要還是聚焦在線索流轉的維度,為了使我們團隊更好的了解線索的整個生命周期,即線索怎么來的,過程中因為什么狀態會變更。

3. 原型以及PRD

原型繪制可以多用原型庫,大多數情況使用標準組件可以滿足90%的場景,最好不要自己硬造組件,這樣開發成本比較高,而且用戶也不一定習慣這個“新組件”。Prd每個公司要求都不一樣,主要是公司內要求,在此不再贅述了。

行文至此,完結撒花,希望本篇可以給和我一樣的初級萌新一些啟發,也希望以文會友,認識更多做CRM、ERP企業信息化、數字化轉型領域的伙伴們。

本文由 @ 錦鯉ssssr 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 很不戳

    來自浙江 回復
    1. 謝謝嘻嘻嘻

      來自北京 回復