產品規劃:為什么有些feature看到了卻不做?

0 評論 477 瀏覽 0 收藏 5 分鐘

一個功能是否要做,并不是說在規劃或者feature里就可以的。還要看場景、進度。這篇文章,作者就分享了自己的經驗和觀點,供大家參考。

測試同學偶爾會來問:為什么這個**功能現在不做呢?

對啊,為什么大家明明都想到了確實沒有主動做上去呢?

產品規劃里面存在一些feature,一定會等需求方提出了才會去做。對于不同的使用用戶,是b、還是c、是可接觸的、還是屏幕背后的,我們當然要用不同的策略來管理,你說呢。

產品路徑中我們曾遇到過敏感的數據地帶,涉及到多個上下游的業務相關方,如果產品對于某個環節的數據提供出現偏駁,或者說具備了不客觀的色彩(比如:是不是系統有了自己的想法,也就是產品策略和業務策略產生了的點點分歧),那么產品運營方自然也要被介入到業務的糾扯中不能自拔。這時候產品策略就依賴業務策略的建設,而業務策略的沉淀又依賴到其他一些產品功能的應用落地。

上面其實是之前經手有款產品其中一個feature,是個小算法,核心是給用戶提供系統匹配計算的數據推薦,減少業務人員的數據篩選動作。這個數據我們大張旗鼓,吶喊叫做“相似數據”,就是匹配找到的高相似度的數據。哪怕是一模一樣,我們也說這是個“高相似度”的數據。而最終的確認行為,是由用戶自己主動核對過后進行點擊操作完成。

究其為何,就是前文所說的敏感數據,涉及業務相關方多個,容錯率低、業務風險高。雖然在產品規劃中,早早識別了對業務的效率價值較大,但仍然按住了節奏,待前置的一些關聯功能業務都落地后,才研發上線了該功能。并對其中相關的數據指標進行了審慎的命名,都是在引導用戶能夠對自己的行為有清晰的認知和定位。

類似的敏感的功能設計不少,比如:商品價格的管理、更新等機制,在實戰里面則會以策略、技術儲備先行,業務訴求迸發后才會迅速動手開干,而非主攻形態。而有些功能性效率改革價值大的,則會主動推進研發、引領業務方去落地應用。

以上當然有背景,是面對的復雜的b端內部用戶。如果是c端用戶,我們可能很難拿到如此真實的臨場的感受,更多的是通過數據、用戶行為分析得到的結果,而對于注意力管理,保持的形態更多應該是戰斗形態。

產品的規劃過程中,某些點看到了不做,其實不代表這些點不需要、沒有價值,價值對于用戶是一個動態的效用組合,需要結合場景、約束等外部因素,以及用戶自身的感受、情感,以上綜合決定了某個產品點的“效用”大小,也隱含了合適的時間窗口(產品時機)。

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

題圖來自 Unsplash,基于CC0協議

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!