一個項目帶你走進產品經理的世界(5):第一個版本做MVP還是MDP?

15天0基礎極速入門數據分析,掌握一套數據分析流程和方法,學完就能寫一份數據報告!了解一下>>

上一篇文章《一個項目帶你走進產品經理的世界(4):產品規劃》介紹了產品規劃,這一篇我們介紹一下產品的第一個版本。

一、產品的第一個版本要怎么做呢?

我一直比較認可一個觀點,產品經理更像是家庭主婦而不是五星級廚師。五星級廚師是根據完美搭配的食材做出美味可口的食物,而家庭主婦是根據冰箱里現有的食材做出美妙的食物。

因為產品資源和上線時間的限制,很多時候產品經理都是在倒推每個功能或每個版本的時間點。簡單點說,上線時間是確定的,團隊成員是固定的,唯一不確定的是產品的功能。那怎么安排第一個版本的功能呢?

1. MVP?MDP?

提到第一個版本,有兩個詞就不得不說下:MVP ?MDP ?

首先,我們先看下這兩個詞分別代表什么?

MVP:Minimum Viable Product,最小可行化產品。產品的第一個版本需要為產品的早期用戶提供他們需要的功能或傳達產品的價值。簡單來講,產品第一個版本需要為核心用戶提供核心功能,除此之外,一切從簡。因為只有這樣,才能保證開發速度,能夠快速試錯、快速迭代。

MDP:Most Desirable Product,最渴望的產品。產品的第一個版本需要為用戶提供他們最想要的產品,不只是功能上,還需要關注 UI、產品質量等。

最后,究竟是 MVP 還是 MDP?根據產品所在市場的生命周期決定。

導入期:推薦 MVP。快速推出產品,快速占領用戶和市場是第一要素。這個階段相當于市場的紅利期,誰能快速推出產品,誰就是吃螃蟹的人。或者說在食物種類比較匱乏的時候,你提供一個干面包可能銷量就會很好。

成熟期:推薦 MDP。市場的成熟使得用戶的期望變高,再提供簡陋的產品將不再能吸引用戶。或者說,食物已經各種各樣了,此時你再提供一個干面包,用戶極有可能不理不睬。

二、「簡報生成器」應該怎么做呢?

先給結論,「簡報生成器」是按照 MVP 模式進行的。

原因有兩點:一來當前市場上沒有類似的產品,也就是說市場處于導入期,這個階段適合采用 MVP 的模式快速占領市場。二來作為用戶的我沒有在當前市場里找到類似的產品,很關注功能是否滿足,不在乎形式、UI 等。

所以,我們第一版就按照最低標準交付,能滿足用戶需求就行,不追求形式。最終經過商榷(只有一產品一開發的情況),我們決定低成本交付最終生成的簡報,先確保這個模式走得通、流程設計的沒有問題。

上一篇中我們已經了解到「簡報生成器」第一個版本包含內容獲取、內容生成、內容發送三大功能點。

1. 內容獲取 V1.0

首先我們來看下「內容獲取」。「內容獲取」主要包括以下部分:

(1)從哪里獲取

由于第一個版本是為了跑通流程,所以我們先提供一個網址用于獲取簡報信息。在具體實現的時候,我們發現,每新增一個信息源(網址)就要增加一個爬蟲程序獲取信息。這也驗證了我們在整理功能列表時提到的信息源只能勾選,不能支持用戶自主添加。因為沒有背后的爬蟲程序的話,只添加網址是沒有意義的。

第一版我們暫定的網址是:https://readhub.cn/topics

(2)獲取哪些內容

之前已經提過我們是按照關鍵詞區分不同的類型的,因此根據經驗,我們將類型和關鍵詞做了初步的整理,得到如下所示的關聯關系。

  • 熱門:BAT、百度、阿里巴巴、京東、小米、抖音、知乎、騰訊、qq、QQ、微信
  • 產品:宣布、啟動、發布、新增
  • 創投:融資、領投、募資、路演、IPO、招股、上市
  • 科技:研發、特斯拉、亞馬遜、火星、月球、發射、機器人
  • 其它:(不含以上關鍵詞的均屬于這部分)

(3)獲取哪個時間區間的內容

因為我當前做到是早報,因此需要的時間區間為「昨天」的信息。在后續的版本中,該項會成為一個選擇項,用戶可以自主選擇時間段。

(4)什么時候獲取

「即拿即用」。第一個版本可以接受點擊「生成」之類的按鈕之后去抓取結果(或從數據庫里取結果),后續需要做到定時抓取、定時儲存到數據庫。

(5)怎么獲取

當然是寫程序去網站抓啦,然后將抓到的內容存入數據庫中。

2. 內容獲取 V2.0

當研發拿著內容獲取 V1.0「按關鍵詞做篩選,并歸類到具體的類型下」的規則去爬取內容的時候,我們驚喜地發現這不是我想要的產品。具體表現為:

  • 每種類型的簡報非常少,而且相互有重疊。比如拿關鍵詞「小米」去匹配,「小米旗下某某公司融資或上市」類的新聞也被歸為「熱門」,但其實應該歸為「創投」。
  • 大部分簡報都歸屬于「其它」類。大部分關鍵詞都匹配不到簡報內容,或簡報內容找不到對應的關鍵詞,才導致了這種結果。

為什么會這樣呢?我們分析了下原因:

一來關鍵詞會重疊,如果一個關鍵詞既屬于類型 A,又屬于類型 B,程序是不知道它究竟是屬于哪個類型的,當然產品給的規則也并沒有明確這一點。

二來很難提供全量的關鍵詞匹配所有的內容。根據簡報標題的關鍵詞去區分類型,除非能給予全量的關鍵詞去對應類型,才能保證簡報和類型的一一對應。這件事在當前這個階段根本就不可能實現。

綜上,我們在選擇信息源時,我們不再選用綜合類的信息源,轉而選用垂直領域的信息源。

舉個例子,之前我們使用的是「readhub」這種綜合類新聞網址,在第二版中我們改用了「NEXT」、「知曉程序」這種產品類和小程序類的網站作為信息源。

在確定信息源之后,我們就針對每個網站分別設置內容的抓取規則。比如從「NEXT」上爬取了每日的產品,從「知曉程序」上爬取每日最新的小程序列表。

內容獲取 V2.0 和內容獲取 V1.0 最大的區別就在于「從哪里獲取」和「獲取哪些內容」,其余都是一致的。

3. 內容生成

內容生成要求按照固定的格式生成簡報。因為是第一版,要求比較簡單,用文字版就可以。這里只要提供一個簡單的格式。

4. 內容發送

「內容發送」用于用戶主動生成簡報。嚴格地講,前面兩步已經包含這一個功能點了。但為什么專門把這個功能點列出來,一來為了記錄這一功能點,以免后期有所遺漏;二來后續可以做到訂閱,每天定時通過郵箱等形式給用戶發布簡報。

三、最終的效果

經過五一的勞動,我們把第一版的產品做了出來,具體效果如下圖所示。

1. 簡報設置

如圖,可以選擇簡報的類型和簡報的日期,點擊「生成」即可查看【簡報結果】。

2. 簡報結果

【簡報結果】界面是將爬取的結果展示在這里,只處理了「類型」。

按理說,這個界面只要實現基本的功能就行,不用關注 UI。但是開發同學覺得界面太丑了,自己看不下去,然后簡單處理了下。這其實就是屬于「程序員自嗨」。不過在不影響最終時間的情況下,作為產品我也是可以接受這種現象的。一來簡單的 UI 處理花費不了太多時間,二來也是開發同學想把產品做得更好一些,打擊別人積極性總是不好的,只要最終的結果沒問題就行。

3. 這算是直接上手開發嗎?

直接讓程序員開發產品這件事肯定是不靠譜的,根本沒法避免后期需要填多少坑。雖然我們在做一個臨時的小項目,但是還是會按照「正規流程」走的。

團隊成員只有兩個人:一個我,一個開發同學。我們兩個在做這個項目的時候和以往做產品有些許不同。

溝通上

為了提高效率,我們采用了面對面溝通的形式溝通產品的細節以及我想要的最終的呈現方式。在團隊人員比較多的時候,雖然面對面溝通這種形式必不可少,不過還需要記錄文檔留底。一來方面大家后續回憶當時為什么這么做,二來如果需要明確責任(扯皮),留底的文檔是一個很好的武器。雖然我們是兩個人,不過溝通完「產品架構」之后,我們還是簡單地做個圖留底。

項目管理上

雖然團隊成員只有兩個人,不過我們還是使用了項目管理軟件 Tower 記錄。這點和平時工作比較相像。在我們這個項目中,我們將項目分解成具體的任務,并明確具體的責任人。同時,我規定了 Web 端的輸入和輸出格式,并記錄在了 Tower 的對應的任務里。即使過程中有過修改,我們也是在對應任務下做了簡單的描述。

原型設計上

這個產品的原型設計我沒有采用 Axure 之類的軟件,而是直接用筆在紙上畫。一來方便溝通,二來簡單省事。因為我們第一個版本沒有采用小程序的形態來完成,而是用 Web 端實現,本身不是很復雜。用紙畫原型有個不好的點是紙容易丟失,不利于保存。如果你選擇用紙來畫原型,這一點一定要注意。

很多產品新人覺得 Axure 的技能要很牛逼,才能當一個合格的產品經理。其實,所有的工具只是輔助你達到目標的手段,用什么工具真的不重要,能清楚表達意思才最重要。我還見過用 Excel 畫原型的公司呢,依舊不影響人家「活」得很好。這里打個小廣告,后續我會整理「Axure RP 9.0」的系列文章,感興趣的同學可以關注我哈。

UI 和測試

沒有專門的 UI 和測試同學,都是我們兩個人分擔。所以我很擔心程序有沒有 Bug,丑倒還好些。如果你在一個小的創業公司做產品經理,可能也會遇到同樣的情況,這個時候你千萬不要只把自己當成「產品經理」,你還會身兼數職。這個情況產品經理大多扮演的是「補位」的角色,也就是俗話說的「哪里缺人補哪里」。

上線

我們現在使用的版本是在本地運行的,局域網內也是可以訪問的。遺憾的是當前版本還沒有在公網上部署,部署之后我再來補充吧。如果你感興趣的話,可以在 Github 上查看我們這個項目的相關資料。

鏈接:https://github.com/HuaxinLab/briefing-generator

四、總結

1. 為什么要關注產品的第一個版本?

產品的第一個版本就像你給別人的第一印象一樣,非常重要。

在社會心理學中,有一個詞叫「首因效應」,指的是第一印象主導主體印象的形成。也就是說,你對一個人的總體印象如何,往往取決于你對他的第一印象。這是非常常見的一種社會知覺偏差。

一般而言,第一印象一旦建立起來,它對之后的信息理解和組織起著強烈的定向作用。而對產品來說,產品的第一個版本決定了產品在用戶心中留下的形象,也在很大程度上決定了產品的生死。

但有一個很矛盾的點在于,很多時候我們希望第一個版本上線之后,就立馬能夠得到用戶的反饋,不管是積極的反饋還是消極的反饋;但是很多時候,用戶的反應都會「慢半拍」。

也就是說,你很著急得想要看到第一個版本上線后的效果,但往往收不到太多的反饋。可能過了一段時間,市場的反饋才會慢慢多起來。就像談婧在《重新定義分享》里提到的「Uber 和佟大為一起做活動」的例子,剛開始以為這個事件會達到一個爆點,然而沒成想市場反應平平。活動結束后的一段時間,這個事件才達到了高潮。

2. 產品第一個版本指的是什么?

或許你會說,產品的第一個版本就是第一個開發周期結束后的產品。但我這里提到的第一個版本是指面向用戶使用的第一個版本。

在真實的開發過程中,產品團隊已經開發了好幾個迭代,只是這幾個迭代的成果都沒有面臨市場和用戶的檢驗。也就是說,在面向用戶的第一個版本之前,可能已經有很多個版本。當然也有一些產品在開發了幾個迭代之后,可能由于公司政策調整,也有可能因為需求的急劇減少,這些產品永遠無法面向市場和用戶,也就是說可能永遠都不會有第一個版本。

3. 想清楚第一個版本的目標是什么?

(1) 驗證需求是否存在?

當你不確定需求是否存在時,首先你要做的是驗證需求是否存在。第一個版本就必須要搞清楚這件事,以免浪費過多的時間。驗證需求是否存在,需要驗證:

1)這個需求是真實存在的需求?還是偽需求?可以通過用戶過去的行為來判斷。比如用戶說,如果小區能有健身房就好了。但用戶上次去健身房可能是幾年前。那用戶說的這個需求你就要抱著懷疑的態度合理分析。

2)這個需求的頻次是怎樣?一個月一次,還是每天一次。比如吃飯就是一個高頻需求。

3)這個需求是剛需還是非剛需?比如一天不吃飯就不行,那吃飯就是剛需。

(2)驗證設計是否合理?

在你已經確認需求是存在的并且是合理的情況下,那就需要驗證設計是不是合理。這里需要關注:

1)流程設計;

2)交互設計;

3)視覺設計(顏色、圖標、間距、字體等),優先級依次遞減。

2B 產品大部分屬于這種情況,在需求明確的情況下驗證設計的合理性。2C 產品大多屬于第一種情況。

4. 下一篇?

下一篇我們將重點關注「功能打包」和「產品設計」,主要涉及「需求池管理」、「每個版本的功能列表規劃」等內容,敬請期待。

好的,今天這篇文章到這里就結束了,我們的《一個項目帶你走進產品經理的世界》系列文章完成進度如下:

黃色為當前進度~

相關閱讀

一個項目帶你走進產品經理的世界(1):從收到一個需求談起

一個項目帶你走進產品經理的世界(2):需求分析

一個項目帶你走進產品經理的世界(3):從用戶需求到產品功能

一個項目帶你走進產品經理的世界(4):產品規劃

#專欄作家#

佐珥,微信公眾號:產品碎月(ID:pm_lab),人人都是產品經理專欄作家,專注互聯網產品,樂于通過幽默詼諧、圖文并茂、結合實際的文字分享自己的產品經驗,期望同大家一起快樂成長

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

題圖來自Unsplash,基于CC0協議

給作者打賞,鼓勵TA抓緊創作!
評論
歡迎留言討論~!
  1. 在內容V1.0做選擇簡報的分類的時候 為什么不參考資訊網站的分類去篩選?還有一個不成熟的小建議:以后產品迭代 用戶可以自己選擇時間區間的內容的時候 再新加兩個篩選:“最新”(按發布時間排序)和“最熱”(按瀏覽量排序)

    回復
  2. 用什么軟件畫的圖啊

    回復
  3. 這個感覺更多從C端來講吧,從B端來講我還是比較建議采用MVP的形式,先保證業務有的用,然后才考慮怎么更好用吧

    回復
  4. 首先,作者的系列我從第一篇看完我就知道要追更了,等了一個月,一次性看到這里還是學習到不少東西,謝謝!
    在驗證需求是否存在處,驗證需求頻次的話就需要在功能設計的時候提前埋點了,加上如果是快速開發的狀態的話就更要考慮好埋點的位置,盡量在少而重要的地方做到能統計到自己需要的數據。

    回復
    1. 哇,感動,居然全部看完了。我沒有做埋點,等我研究下

      回復
    2. 好的,等作者開新坑,先看剛更新的那篇 ;-)

      回復
  5. 啥時候更新啊

    回復
    1. 我發新的了呀~ http://www.qlurlm.tw/pd/2338076.html

      回復
  6. 期待ing . . .

    回復
    1. 來來來,next one~http://www.qlurlm.tw/pd/2338076.html

      回復
  7. 更啦!沖鴨

    回復
    1. 呀呀呀,來哇~

      回復
马总会三肖中特