從0到1,做一款互聯網產品需要關注的五個執行重點

7 評論 16888 瀏覽 113 收藏 9 分鐘

現在聊聊從零到一做一款互聯網產品,需要注意的重點。這些點,我看了很多相關的文章,很少有講清楚的。在此簡單列個幾點,與你分享。

1.一切方案以「可執行」為標準

寫出來的東西定義不明確,拆分的不夠細,規則模糊,東西扔給研發之后,人家滿腦子都是問號。這是新人最常犯的錯誤。

舉個例子,假設某款應用有用戶間評分的功能,后臺需要一個列表監測那些連續被打差評的用戶,看看是否存在惡意行為。于是,有人在需求中寫了這句:「若一個用戶連續多次被打低分,則列入觀察列表」。

看到這句我就很惱火。「連續」「多次」是什么意思?什么時間內?幾次?中間有一次例外還算不算連續?「低分」又是什么意思?低于多少分是低分?是低于絕對值,還是整個系統平均值,還是別的什么值?這種東西就是寫出來無法執行的,定義的不夠細,寫了跟沒寫一樣。

這種細節缺失的背后是邏輯的不清晰和一種「總會有人幫我把事情想清楚」的懶惰,它們會在緊張的「從零到一」過程中產生非常多的無效溝通成本,浪費大量時間去解釋、修改。

如果項目中的產品經理都這樣,結果將是毀滅性的。

2.設計機制

不得不說,業內太關注交互、視覺等表層設計了。其實產品設計中更具魅力的,是機制的設計。

機制,就是游戲規則。

往小的說,朋友圈的「關系鏈封閉」機制遠比它的UI更重要,Twitter的關注和轉發機制也是同理。放在游戲里,Tom Clancy’s The Division 中的暗區機制也是整個游戲的核心,引來了無數捧場和吐槽。

往大的說,房屋限購政策、公司注冊制度、股票期權交易規則,都是機制。一個國家或不同國家之間的貧富差距,很大程度上也是由社會的機制(制度)決定的。

機制有好有壞。好的機制能締造一個均衡的系統,讓用戶生產與產品定位相符的內容,發生對產品有價值的行為,減少垃圾內容和惡意行為發生的規模和幾率。壞的機制,則能產生相反的效果,讓系統行為完全脫離控制。

為什么打開各種產品blog,很少看到關于機制設計的內容呢?

第一,可能是因為這里沒有duang這么炫酷的效果;第二,很多產品的機制都是核心秘密,于是沒人拿出來分享是正常的。

所以我也沒辦法拿出來分享,我只能說這個很重要……

3.設計產品管理系統

產品本身重要,產品管理也很重要。數據后臺,運營后臺,這些都屬于產品管理的內容。

數據后臺比較好辦,友盟等成熟工具一般都能搞定絕大部分問題。但數據需求要盡早定下來,而確定數據需求的過程中,就需要解決幾大重要問題:我想判斷的事實能通過哪些數據體現?這些數據通過哪些節點定義、采集?這些數據能為以后的迭代路線有哪些指導意義?這些都要提前想好。

與數據后臺不同,運營后臺一般需要自己搭建。這也是一個產品非?;竞椭匾臇|西,其需求描述的量甚至會超過用戶側的設計。

舉幾個例子,內容類產品絕對都有個內容運營后臺。如果內容是UGC的,那還有一個通過某種規則發現精品內容的運營后臺。所有的社交類產品都要搭建一個舉報審核后臺、異常行為檢測后臺,以及可以執行的禁言/封號類操作。此外,所有產品都會有最最基礎的用戶反饋查看后臺、全局消息發送后臺、文案/入口配置后臺。如果產品增長到一定的體量,還需要設計一套灰度發布機制和相應的后臺,這個就更復雜了……

設計運營后臺的一件要事,是設計運營專員的工作流。

公司雇人是要花錢的,為運營專員設計一套高效的流水線就是在為公司創造價值。而這套流水線也會在運營后臺中體現。舉個例子,運營專員要做舉報審核,首先要瀏覽:考慮要展示哪些信息?怎么排版效率最高?然后進行操作:無視,或執行懲罰措施,是否有需要標記惡意舉報?若沒法當場判定懲罰措施,是否有需求打上一個「待定」標簽?完事之后怎樣匯報?如何評估運營專員做這件事的準確性,并以此為依據進行考核?

其實考慮到了這里,我們的格局就不止是產品設計本身了。

如果加入一個大公司的已有項目,上述這些東西多半是已經弄好的,不用費心去做。但如果是從零到一,情況就不一樣了,你必須事無巨細地把這些東西搞定。

4.通過管理優化效率

從零到一考驗的是整個團隊的品質,而作為處在整個團隊hub位置的人,更有責任影響并驅動整個團隊往更聰明、更高效的方向發展。

我們需要做的是:

  1. 傳播自己對產品的思考和理解,讓團隊每個人都在一定程度上理解產品的規劃與設計;
  2. 督促研發等崗位對產品設計細節的了解和執行(當然前提是你寫得夠好);
  3. 搞好私人關系,建立影響力。

一個「無腦」的研發,會用錯誤的方法,把你的設計實現的亂七八糟,讓你看到 daily build 后勃然大怒,結局必然是返工、延期、加班,而且這鍋還得你背。

而一個「有腦」的研發,會用聰明的方法,實現你的設計,而且還會補全很多你沒想到的 corner case,更有可能挑出你設計中的問題并提出建設性建議。

能跟有腦的研發合作,是產品的一件幸事。既然如此,為何不主動點,把身邊的研發都變成「有腦的研發」呢?

5.提前進行營銷準備

無它,就是預先做好準備:

  • 在產品設計之初就要明確定位,在執行中不斷提取出賣點,特別是文案以及平面品牌元素(最好拉個專業人士一起參與)
  • 提前尋找推廣和渠道運營的資源
  • 列好發布計劃,提前設計首發活動
  • 提前收集活動運營idea,以后逢年過節可以拿出來用
  • 等等,正在探索中……

總的來說,從零到一做件事情,相對而言會復雜很多,但也更有樂趣。在這個過程中,你會發現自己的短板(設計、技術、運營、推廣),并想辦法去學習、尋找資源而彌補它。同時,你思考的格局、完整性也會比以前更上一個檔次。

 

作者:吳亮(微信公眾號:LumiSpace)

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 個人意見:新產品從0到1的過程不用制定流程,不用特別詳盡的文檔。應該把精力用在驗證產品假設上,只要產品能夠穩定運行核心功能,就要拿著產品去找用戶驗證產品,后期才是制定流程提高效率。如果一個創業團隊效率都不高,那直接開掉那個效率慢的,對其他員工更公平。

    來自福建 回復
  2. 求小編微信

    來自北京 回復
  3. 哈撒偷渡ASAP虐QAQ餓了偷渡DVD特色特特特特特特樂呵呵磕頭fuel惡略特特特科特JDK

    回復
  4. ??

    來自北京 回復
  5. 謝謝分享
    談一些個人看法:
    針對第一個問題,個人認為應該是開發團隊的問題,這種看似模棱兩可的需求,其實是可以通過豐富產品設置解決的,開發團隊應該能理解并且做好這部分工作.如果一個產品事無巨細,勢必再某種程度上影響對產品的把控.
    第二個問題,產品設計的制度的均衡,起初可以越簡單越好,這樣也利于用戶在使用中盡情發揮,也會對產品未來發展的起到積極的影響作用,如果設計過于嚴謹,難免會失去一些觀察用戶的機會. 也算是各有利弊吧.
    第三個問題,產品上線初期,沒必要拿出太多精力來設計管理系統,早期可以通過直接查詢修改數據庫方式,而非必須開發一套完整的管理系統,太浪費時間,甚至一旦產品前端進行調整,后邊的管理系統也必然跟著進行調整,成本過高,當然這只是在產品推出的初期試水階段,到了中后期必然會有相應的管理系統與之配合
    第四個問題 沒啥好說的,這跟產品經理性格有關系,一人一套路,哈哈.
    第五個問題 補充一下:營銷運營是要配合產品凋性的,因為無論任何產品的開發,前提都是看到了利潤區,才去組織開發的.運營推廣過程中的任何策略,渠道都是以把握好產品特性為基礎的.
    寫的比較倉促,各種不足之處,請多多指教.

    來自天津 回復
    1. 寫錯字,咋改啊?

      來自天津 回復
    2. 改不了,哈哈。

      來自北京 回復