完全基于個人理解的海外產品運營-結合運營的設計②

0 評論 971 瀏覽 6 收藏 7 分鐘

從運營的角度來設計產品,會是什么樣的效果?如何根據當前產品解決的用戶需求來進行上下游的延伸呢?這個問題,作者給到了三種解決辦法,大家可以參考一下。

每個產品都具有其自身的生命周期和不同的發展方向,產品運營自然也會涉及到對于產品需求的理解和鋪墊,以產品運營的角度設計產品需求,則是產品設計的另一個重要方面。

在產品運營有兩個問題是至關重要的:

一個是如何提高轉化,轉化可以是指功能使用或者交易行為等,這些產品靠著特定細分市場做到用戶的精準定位,通過不斷提高轉化率的方式自我進化;

而另一個問題就是如何更好地滿足用戶需求,而滿足用戶需求又可以拆分為兩個部分考慮,有些產品則選擇“橫向發展”,不斷地納入更多的功能,增加產品本身覆蓋的用戶面,擴大基本盤;

還有一些產品,由于自身的定位和認知上主動或者被動的限制,會在已有產品的基礎上不斷擴展出其它產品,這些產品集中在一個特定的領域,逐步形成矩陣,完成需求邏輯閉環。

一、核心需求的上下游延伸

如何根據當前產品解決的用戶需求來進行上下游的延伸呢?這個問題經常會讓人摸不著頭腦,而且很多時候大家給出的答案也可能會非常抽象,并不能給出具體的原因或者支撐,尤其是在一些需要發表或者征集意見的時候,這里有幾個方法可以作為參考。

1. 中心環繞式

所謂中心環繞式,是根據一個現有的點尋找到上一級或者更高級的主題,以這個主題為圓心,畫一個圓,這個圓上可以根據主題劃分為幾個相關的部分,然后再根據這個圓來完善當前的產品形態或者產品矩陣。

比如,以數據恢復為例,數據恢復作為一個單獨的需求存在是完全沒有問題的,但如果我們想要實現或者滿足更多的用戶需求,那我們就需要找到數據恢復的上一級概念:數據安全。

在數據安全這個大的概念下,我們可以得到幾個另外不同的區域,比如:數據備份,數據傳輸,數據擦除等,這樣就可以結合實際情況看到我們需要補充什么,還能做什么。

2. 跳蛙式

在太平洋戰爭中,美軍實施了一種“跳蛙戰術”,其實就是集中力量打下一個島,然后從這島點出發,去攻打下一個島,再從下一個島出發,繼續攻打其它的島,以此類推。這種方式的核心就在于,思考的時候如何從新獲得的“島”出發,調整出發點,到我們一直停留在一個點時,我們的思維往往是被限制住的,但如果我們從一個新的點出發,就會增加更多的可能性。

舉個例子,比如首先從數據丟失這個需求點出發,如果用戶無法找回的是他刪除的數據,那么對刪除數據進行備份則是一個新的需求,而從對刪除數據進行備份這個需求點出發,我們還會考慮到備份會占用用戶的磁盤空間,那么使用云備份是不是就可以一定程度上解決這個問題了呢?既然我們已經提出了云備份這個功能,那么就必然會引出一個重要的產品需求,就是用戶賬號系統的搭建和管理。

當然,以上兩種方式還可以結合到一起進行組合,通過一個現有的點,升級到一個已知的主題,在這個主題中選取一個點作為基礎點進行延伸,延伸到一定位置時再根據這個點升級到另一個主題。

二、基于用戶需求進行合理猜測

有依據的方法看完了,這里再貢獻一個看上去“沒有依據”的方法:即根據用戶當前的需求作為基礎點,不斷地延伸和組合,形成新的不同的點,再把這些點進行延伸和組合,獲得更多的點,這些點和線具象化之后就會呈現出“紙牌屋”的樣子。

當然,方法1+方法2+方法3也是完全可行的:

以上就是這次分享的內容了,這三種方法所推導出來的點并不一定都適合作為產品需求或者運營需求,但總還是能夠提供一些參考和借鑒。下次的更新集中說明如何將已有的產品運營內容總結形成體系,發現通用性,實現復用。

作者:吳桐,公眾號:二喵的蠢奴才

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

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

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

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