這個功能很常見,要不要上?

5 評論 2919 瀏覽 16 收藏 8 分鐘

編輯導讀:很多時候,面對領導的一些“無理”需求,產品經理不僅不能反駁,還要自動背鍋。想要拒絕老板,就必須對需求到底能不能滿足進行分析,具體怎么做?本文作者從自身工作實踐出發,結合搜索功能的案例,分享了自己功能分析的具體方法,供大家一同參考和學習。

領導:其他產品都有這個功能,我們怎么沒有?

運營:有客戶反饋需要某某功能,產品安排下

作為產品經理的我們,身邊是不是經常充斥著這樣的聲音?

此時,你會如何選擇:

  • A:好的,立即安排!
  • B:各位容我三思……

很多時候,我們明知道不合理,但還是會選擇A,很大原因是我們找不到合適的理由去反駁對方的觀點。但即使選擇妥協,苦逼的產品最后還是背鍋的那個。

為了讓咱們跟老板同事客戶……PK的時候更有底氣,我把自己的思路整理成文章,結尾附上大家喜聞樂見的模板,相信看了這篇文章后,你的思路會更清晰。

前段時間做過一款資訊類產品,對于資訊類產品而言,搜索是個常見的功能。很多產品會在1.0版本的時候就標配上,但是搜索并非是一個簡單的功能,開發起來必定要占用一定的時間。因此,借著思考:“資訊產品初期是否需要有搜索功能?”這個問題,我們來看下怎么分析功能的取舍問題。

一、缺失功能的影響

如果要問搜索的定義是什么,很多人都能不假思索的回答出來,搜索就是從多個內容中找到想要的答案。用戶可以通過這個功能快速找到目標,從而節約時間成本。

這個定義并沒有什么問題,但是如果我們僅從這個定義去看待這個問題的話,很容易得出一個結論:用戶需求+功能有效性=功能必要性,所以開發就對了。

真的是這樣嗎?

場景一,沒有搜索功能:

由于最近國外疫情比較嚴重,我想要看國際疫情的最新情況如果沒有搜索功能我需要怎么去尋找目標?只能通過列表逐條查找,由于產品是1.0版本,資訊總計100條不到,刷完全部資訊可能需要花費兩三分鐘左右的時間,并不會太久,但是如果有1000條,10000條,甚至更多,再要通過一個個找,就不太現實。

通過場景,我們明白了以下幾點

  1. 搜索真正的價值:當內容越多時,開發搜索的必要性越高,當內容越少,搜索的必要性越低。
  2. 搜索缺失影響的用戶范圍很小:搜索缺失真正影響的是有特定查找需求的用戶,那么就需要調查影響的用戶比例是多少?這些用戶搜索的頻率是多大?在產品初級很顯然這樣比例和頻率肯定是很少的。
  3. 缺少搜索有其他替代方案達到目標:用戶通過列表中的資訊逐條查找要看的內容,由于當前資訊的數量少,可以解決這個問題。

二、獲得該功能的結果

場景二,有搜索功能:

當產品有搜索功能時,用戶通過搜索來查找目標信息,由于產品的資訊少,用戶在實際使用中,很大幾率獲得的結果是:跳轉至缺省頁,頁面中顯示“未找到相關資訊”

“未找到”相當于明目張膽的告訴用戶:抱歉,您的需求無法滿足。

此時用戶的感覺肯定是糟糕的。因為用戶要的是搜到,而非功能本身。因此,我們需要規避掉產品的弱點,避免搜索為空和搜索錯誤時給用戶帶來不好的影響。此時開發搜索功能顯然是吃力不討好之舉。

以上場景,我們可以得到:搜索的關鍵在于搜到,而當前開發這個功能反而有一定的風險

三、該功能在當下的優先級怎么樣?

為了完整的思考這個問題,除了以上幾點外,還需要考慮功能的優先級,在產品的不同生命周期產品的目標也有所不同。

  1. 結合自身產品的情況,當下產品目標是提升閱讀上的體驗,增加搜索功能并沒有什么幫助;
  2. 核心功能是閱讀和品牌發布與搜索功能無關;
  3. 在跟開發評估開發難度后,得到此功能的開發并沒有這么簡單。

以上分析可得到:

  1. 搜索不符合當下產品目標
  2. 非核心功能或者急需解決的問題
  3. 功能的開發難度中等

因而,在優先級評定上,該功能并非緊急重要,同樣的開發時間在其他更需要解決的問題上性價比更高。

四、總結

通過以上幾點,我們能得出結論:資訊產品初期并不適合開發搜索功能。如果貿然開發,可能好不容易積攢的種子用戶,就跑到競品那兒去了。

搜索這個案例可以給我們提供思考的幾個方向:

  1. 缺失該功能的影響范圍大不大,有沒有替代方案?
  2. 該功能是否符合當下的場景,即開發能不能滿足用戶真正的需求,有沒有什么風險?
  3. 功能的優先級怎么樣,是不是核心問題,是否符合產品目標,開發難度怎么樣?

文末附上整理好的表格以及文章的思維導圖,可以根據表格上的參考自身情況。

模板:

思維導圖:

 

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

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 個人認為作者的方法是對的,先不說搜索。本身在需求功能很多的時候,當前的版本、業務、上線時間等條件綜合來考慮需求的重要性、可替代性。本身我們一直都在說的迭代。就是在取舍或是簡化。
    搜索的模糊查詢不難,但是做好搜索不是只有一個模糊查詢,搜索還是難的,很簡單的說百度不就是靠搜索么。只是我們平時做的比較簡單,還有就是新用戶搜索用戶較小,因為目標性,你想一個新的app面世,有多少人在有目標的查詢。當然作為資訊類的標配,簡單的搜索是可行的。就是比如電商總得有個購物車,雖然可以直接下單。
    以上純屬個人見解,各位大佬請指教。

    來自陜西 回復
  2. 拿檢索來說,我搜了之后,沒搜到,和我刷了半天內容,發現沒有我想要的內容,這其中的失望感,我覺得是后者更大一些,浪費了時間還沒找到想要的東西

    來自河南 回復
    1. 用戶對不同功能的期望值不一樣,搜索功能本身傳達給用戶的是精準定位,列表是模糊的泛找找。就好像你用音樂軟件,里面有個專門的猜你喜歡模塊,如果每次進去都不是你喜歡的,那以后還會點這個模塊嗎,你甚至會覺得這個產品太不懂你的音樂喜好了。

      來自浙江 回復
    2. 我覺你這舉例一點說服力沒有,我估計作者不懂技術,模糊查詢很容易實現,內容不多,效率、準確率肯定也會可以的,做肯定比不做好。本來你產品讓用戶沒有選擇就是一個錯誤,你的內容真有那么大的吸引力嗎?讓用戶慢慢一個一個去找。你說搜索沒有內容,這不是很正常嘛?

      來自上海 回復
  3. 我覺得應該做,哪怕做一個模糊搜索,開發量也不會很大,特別是新產品,誰會無聊的在你這個新產品上花那么多時間去滑內容。

    來自湖南 回復