當我們接觸一個新行業、新客群的時候，對這個領域是非常陌生的，也就很難提供給他們想要的產品和服務。如何精準地洞察目標用戶的需求呢？本文作者從4個步驟進行了分析，一起來看一下吧。

當我們去接觸一個新行業、新客群的時候，你對這個領域是非常陌生的。

因為是陌生的，你不了解他們的痛點是什么？

你不了解他們，那么怎么可能給他們提供他們想要，甚至超過他們預期的產品和服務呢？

所以能夠最高效地洞穿他們的需求至關重要，這件事情甚至要占用你70%以上的精力才算合格，需求的分析是一切的根本。

需求都分析錯了，后面一切都是無用功，仔細想想是不是這個道理？

如何精準地洞穿目標用戶的需求？首先毫無疑問你站在他的視角去考慮各種問題，而不是站在自己的視角。

01 以用戶視角模擬環境

比如你要給一個餐飲老板提供Saas服務，從同理心角度來說，你要把自己當作老板，去構建模擬這個目標用戶的一切周邊元素：

1. 員工（大廚、前臺、配菜、送菜、采購員……）
2. 主要工作流（接單、制作、配送、采購、推廣等）
3. 收益構成（外賣平臺訂單、私域訂單、店內訂單、企業合作訂單）
4. 成本構成（場地水電、人員成本、原材料成本、推廣傭金和優惠成本等）
5. 模式（線上to C銷售為主，線下to C和to企業訂單為輔）
6. 規模（目前的場地規模、業務規模、人群規模等）

當然還有很多其他元素，這些元素是客觀存在的，即你可以通過實地調研直接了解到。

了解這些有什么用呢？那就是在做需求分析的時候要結合環境元素來做決策。

案例：他覺得目前人員成本過大是他的最大痛點！你該如何分析？

02 科學評估其痛點是否真實存在

老板說人員成本大，那到底是不是真的大呢？很多小伙伴可能直接就默認了老板說的人員成本大，殊不知可能第一步就錯了，因為壓根就不大。

科學的評估，是站在行業的角度結合目標用戶的實際情況綜合評估的。怎么評估？

首先你得先確定評估指標。

人員成本=大廚人數*大廚工資+前臺人數*前臺工資+……（即我在開頭列的工種）

我們假設工資是非干預因素，我們只說人數。

對于餐飲來說，按照人均產值相對合理。比如10個人，1個月能做50w業績，那么平均下來就是5w／人的產值，你要看下這個人均產值是不是遠低于餐飲行業的水平。

如果不是，那顯然這個老板只是自己覺得成本高，但實際上他的成本控制已經超過業內平均水平了；如果是，說明當前產值下，人數是偏多的，那么我們就可以默認確實存在這樣的問題了。

驗證用戶的需求真偽，永遠是判斷的第一步。

03 拆解需求的底層邏輯

即為什么人會偏多？

這就涉及到我們最開始說的工作流了。

我們知道：

• 工作流數量越少，所需人越少
• 工作流越簡單，所需人越少
• 工作流協同越容易，所需人越少

所以，假如在勞動效率保持市場平均水平的前提下，問題大概率出在了工作流上。

于是，我們要針對業務中所有工作流去進行分析了。

分析的思路也很簡單：

1. 遵循先主后次的原則

主要的工作流，也就是耗費人員最多的工作流優先梳理，再處理一些邊邊角角的工作流。

在這個案例中，用戶下單到菜品制作出餐，是最核心的流程。所以要優先針對這個流程做細致的分析。

2. 抓住影響效率的根本問題

比如你發現這家店，從美團、餓了么來的訂單，雜糅在一起提交給后廚，于是后廚就按照所有統一一個時間段提交給后廚的紙質訂單的順序來做菜，結果導致要么美團的出的太快、餓了么的出的太慢；要么餓了么出的太快，美團出的太慢，導致客訴不斷。

但是老板當時并沒有詳細分析來不及做，導致投訴的具體原因，只是單純的以為運力不夠，所以就加了2個大廚來應急。

但是實際上，這樣的工作流存在明顯的問題：

第一，非常低效，沒有充分的信息化。

所有的訂單都需要人打印后統一拿到后廚，依次去做。

第二，所有的訂單都是來一單，做一單

但是其實中間有很多重復的菜，比如5個人都都點了魚香肉絲，但是因為每次都是單獨做一個客戶的菜，于是同樣的菜做了5次，浪費了很多時間。

第三，沒有站在用戶體驗角度制定流程

理論上，廚師是按照給到后廚的訂單順序依次出單，但是這樣存在一個很大的問題，沒有站在“下單用戶”的角度滿足需求。

有些人下單是要求一個特定時間送達，有些則要求盡快送達，用戶的預期是不一樣的。

導致最終出單、送達的時間和用戶預期差異很大，從而導致投訴。

當然以上只是舉個例子，我想表達的是，既然我們知道工作流的合理性和復雜性大大影響了人員效率，那么就要針對性的重點分析并解決工作流的問題，才能有效解決人員成本問題。

04 解決方案要智能傻瓜式

最牛逼的方案，就像抖音的算法，不需要你去選擇、去思考，系統幫你做了決策。

To B的產品也一樣，足夠的簡單、足夠的智能化，幫助用戶最大程度減少做決策的時間損耗，做錯誤決策的機會成本，讓他們能傻瓜式操作，是最高效的方式。

比如針對問題1，隨著前端訂單下達，我們能否讓后廚同步出單，保證信息的實效性，同時可以讓后廚知道整體訂單數量規模和后續訂單量預估，讓廚師可以提前預備。

比如針對問題2，我們能不能抽出訂單中菜品的最小單元，有5個人都點了魚香肉絲，完全可以一起做，這樣就用一份單元時間滿足了5個客戶的需求，效率大大提升。

比如針對問題3，系統從“用戶角度”幫助商家作出優先級決策，直接告訴廚師，你先做什么、再做什么，把廚師當做“小白”，告訴他你只要做什么就行，減少人工決策所帶來的低效、混亂的問題。

05 方案以最細顆粒度進行驗證

好的解決方案有很多，但是一定要適合客戶的特定經營場景，最終切實提高了效率，才能叫有效解決方案。

所以產品驗證常用的方式，在互聯網行業叫最小閉環，即出個小demo，讓你的客戶去評估下，使用下。

比如當你重新設計工作流之后，你可以找廚師現場模擬一下你的新工作流。

我敢說其中一定還會有很多小細節是有問題的，因為你沒有親身經歷過里面的各種瑣碎的工作內容，你無法站在當事人的角度看到很多細節問題，所以方案的驗證能幫助你規避到很多考慮不周的點，從而讓整個方案上線后不至于返工。

06 總結

需求從判斷真偽、到洞察核心問題，再到解決方案，最后方案驗證。我始終認為前2步是核心中的核心，很多人在需求調研、分析、判斷的階段就錯了，后面的一系列措施怎么可能還會有效？

而構建脈絡清晰的產品思維，能夠幫助你快速定位到問題的癥結，輕松洞穿需求，是一個高級產品經理必備的核心技能。