打造b端產品的過程中，如何破除偽需求

公司是初創公司，產品目前處於起步階段，上線至今不過3月有餘，正處於積累用戶的階段。

以下是產品的網站鏈接：

輕流 · 高效的流程化團隊協作工具

有興趣的朋友可以體驗一下（PS.吹一下我們的設計小哥，產品的設計風格廣受好評），也歡迎對我提出產品各方面的意見和建議~

一款新的B端產品，往往會遇到戰略方向的階段性迷茫，客戶積累慢，需求獲取渠道少，導致產品設計陷入瓶頸，又或是陷入產品經理自身對於需求的猜想導致的偽需求。

對於這些問題，我覺得B端產品經理需要堅守一個原則，那就是以「目標客戶」的痛點作為功能設計的出發點。

簡述一下輕流的目標客戶定位

輕流是基於「流程」的，到底應該針對大企業還是小企業提供服務？

後來發現「企業規模」並不是我們的標的，而是「團隊規模」是我們需要關注的重點。無論是大企業的小團隊，還是小團隊本身就是一個公司，我們主要針對那些不足50人的Group。

可是光定了規模還不夠，我們到底為誰而做？誰來買單？

流程的運轉離不開流程的搭建，而流程的搭建者一般就是流程的「所有者」，也就是責任人。所以這類人群，在企業中一般有一定的話語權，但又仍然屬於「執行者」。所以，我們將這類人群定位在團隊的「中高層」。

最終，我們的目標客戶鎖定在「中小團隊」的「中高層」管理人員身上。

產品設計如何針對「目標客戶」的痛點？

我以輕流目前正在進行的」流程設計「功能迭代中的一個小功能點舉例。

先來看一下輕流的「流程設計」

流程主要由流程節點，流程分支，流轉條件組成。可以實現數據的自定義流轉，目前這個流轉僅限於流程的正向流轉，但是在實際使用的過程中，很可能會產生需要退回補充更改等情況。

於是為了實現更高自由度的流程協作，考慮在流程的協作運轉中增加一個與」自定義退回「相關的功能。於是初步方案確定了，在節點操作中加入「退回指定節點」功能。

仔細思考該功能的時候，我首先考慮的是流程的退回可能會帶來哪些風險？已有的數據遭到篡改？由於數據的更改導致流程的走向不一致了？

這個時候，數據的流轉記錄和修改記錄就起到了關鍵性的作用，可以協助找出最終的責任人。

單單找到責任人就夠了嗎？雖然數據的流轉記錄和修改記錄能夠追溯責任，但是如果流程任務出了問題，即使可以找到實際操作的員工，依然會產生損失。

而流程的實際」所有者「是公司的中高層（目標用戶），他們在權責體系中處於中層位置，既有權利追責下層，又要對上層負責。

最終導致目標客戶產生損失。

根據我們的調查，中小型企業的中高層在選擇一款管理工具時，一般會比較在意以下幾點：

工具能否使工作更高效

工具給個人/團隊帶來的提升

工具在權責分配方面是否完善合理

工具是否能進行數據積累，統計

工具有無成效，使用情況是否符合價值

工具是否能夠規避風險，使用起來高度安全

考慮到「目標客戶」會出於「規避風險」這一問題評估一款管理工具，我們應該盡量規避功能中與「流程所有者」這個身份相關風險。

於是在設計「退回指定節點」功能時，我們把是否需要退回，退回給誰這個問題，交給「流程所有者」本身，而不是一味的滿足流程用戶的自由度。

來分析一下這個功能中的「偽需求」與「真需求」

「偽需求」是流程應用可以高度的自由流轉，其中需要包括自由的回退機制。

「真需求」是管理這個流程應用的「所有者」是否允許流程的回退，允許回退的範圍。

即使缺少用戶需求反饋，產品經理也要堅守B端產品主要是為「目標客戶」服務的原則，在產品設計的過程中，盡量破除偽需求，尋找真需求。

以上是我的一些想法，歡迎與我深入探討~