知易行難 | 新專案MVP版本上線後,我總結的一些踩坑點

語言: CN / TW / HK

編輯導語:在專案中,我們或許會犯一下小錯誤,很多人覺得不要緊,沒有犯大錯就行了。其實,這樣一個個小錯誤才是大問題,它會影響專案的上線情況。作者通過其專案經驗,總結了一些自己踩過的坑,與你分享,希望你在成長路上能夠吸取教訓。

大概在11月中旬的時候,我負責的新專案MVP版本就算是正式上線了。雖然團隊內部已經搞過了一個簡單的總結和反思會議,但是我覺得在產品經理個人成長的角度來看,有些東西還可以繼續挖掘一下,所以我寫下了這一篇文章。

MVP版本上線雖然強調小步快跑,快速試錯,也能容忍很多不足,但是其中很多細節或暴露的問題,都是很值得總結和沉澱的,畢竟從0到1的機會不會太多。

11月中旬做總結時候記錄的初稿

我從事產品經理行業其實並沒有很長,也就是大概4年多的時間,大大小小做過的專案大概十來個,真正從0到1的專案也做過挺多。再加上這次的專案和之前的專案業務內容幾乎是一致的,所以我自信這次哪怕是從0開始組建團隊,再去從0到1做專案也應該不會踩很多坑。

但是從實際上線的結果來看,似乎我還是被打臉了。雖然大問題不是很多,但是小問題其實還是足夠給我上一課了。我將這些問題整理出來,一方面是對自己的過往的回顧和沉澱,另外一方面也希望未來自己在類似事件上可以做得更好,最後也希望能對閱讀這篇文章的朋友一些幫助。

一、關鍵性原則的總結

1. 只有理解了需求,才能理解什麼是真正的MVP

需求和MVP這兩個詞幾乎是產品經理天天掛在嘴邊的,但是這兩者的關係要正在的領悟和使用,還是得要實際專案真正驗證了之後才會有切身的感覺。

在前期的時候,由於人力資源不足,客戶資源不足,壓根沒時間調研和訪談,很多需求都是根據之前的個人經驗推出來的,或者是轉了多手之後來到產品經理的手裡。

於是在做產品規劃,產品特性梳理,優先順序和其他資訊決策的時候,往往很難把控住符合MVP的需求到底是哪些。最後該做的可能只做了一點點,不該做的或者不是這個階段做的卻做了很多。

說白了就是,本應該是好鋼用在刀刃上,可結果卻用在了刀把了,沒有擊中要害。

所以,要想確定MVP自己想要什麼,本質上還是得要理清楚需求,而需求從哪裡來呢?

肯定是從實際的客戶上來,如果沒有客戶或者相對明確的使用者畫像,那麼起碼應該少量多次的試探,而不是一把梭哈到一個不確定的因素上去。

2. 簡單,簡單,一定要簡單。刪除,刪除,直到不能再刪除為止

對於SaaS類的B端產品來說,由於需要滿足各種客戶的不同的業務場景,肯定是希望自己的系統做得靈活和強大。

靈活意味著使用者自由配置的空間就很大,可以動態地調整系統邏輯和功能,而開發者也不用頻繁的發版或者定製。

但是對於MVP版本的產品來說,產品經理在這個時刻去思考這種靈活配置化的功能是極度危險的。 因為每次在設計功能的時候總是會想著以後這個地方要靈活,要可配置,要支援自定義,然後就會情不自禁的留口子,留緩衝的餘地 。最後導致出來的功能相對複雜,且其他輔助類功能沒有形成閉環,最後導致使用者體驗不佳。

本來可以給使用者一個寫死的,確定性強的解決方案和流程,但是卻做成了給使用者多個選擇,但是使用者選擇了之後可能會遇到死衚衕(有些功能沒有閉環)的尷尬場景。

「簡單」意味著確定性強,而給多了選擇,留多了口子,肯定會變得「複雜」。

3. 看競品有可能犯錯,但是不會走歪路

對於新產品來說,學習和參考競品的方案是常有的事,這幾乎可以算是業內不成文的規定了。

但是作為產品經理來講,別人雖然做得很好,自己在學習的時候肯定不會一股腦全部抄過來,肯定會加一些自己的理解,或者是刻意地和競品做的不太一樣。

這算是產品經理的態度,也可以理解為一種渴望超越而不服氣的精神,總感覺自己可以做得更好一些。

於是乎,這次MVP很多的大框架和主流程等,我都有意識的和競品做的不太一樣,同時也沿用了大量自己的過往的專案經驗。

最後產品肯定可以快速完成,但是在實際交付客戶試用體驗的時候,就發現花了很多時間做的功能使用者並不太認同,反而是一些和競品做得比較類似的基礎功能,客戶卻很喜歡。

最根本的原因就是兩套方案面向的客戶群體,使用者畫像是不一樣的,而我的方案瞄準的恰恰不是MVP階段的目標客戶群體,所以試用的時候才會被使用者吐槽用的太麻煩,不太好用,建議我們做的簡單一些。

看競品的時候,除了基礎的功能和業務邏輯之外, 還有一個很關鍵的因素就是看雙方的使用者畫像群體是不是一致。如果大方向就不一致了,那麼細節的功能點參考起來就很容易走歪了。

4. 相似的專案經驗是好處,也是壞處

之前我寫過一篇文章,講有經驗的產品經理反而容易吃虧,其實就是從這個專案引發的感慨。

相似的專案經驗看似很美好,直接上手可用,直接Copy一套,但是隱藏在各處的坑坑窪窪的細節,積累多了還是很容易讓老司機翻車。

關於這一塊我不再贅述了,感興趣的可以去看我之前寫的文章《納尼?有經驗的產品經理反而容易吃虧?》

想要提醒大家的就是:

別困在過往經歷中,隨時打破更新自己的固有觀念,才能更加有效地避開這些小坑小窪。

二、細節方面的總結

一些細節方面做得不好的地方

1.功能儘量一次性閉環,別做一半留一半,總是留點邊邊角角會給自己挖坑。閉環是指核心流程的功能要做完,而不是所有內容做完才是閉環。

2.MVP期間如果要趕工期,那麼就要考慮減少介面的開發,例如查詢,提交,刪除,頻率低的異常功能等,很少用上的,不確定能不能用上的,一律就先不做了。

3.減少非必要欄位和功能的拓展,當前用不上就別加,加了再去掉就很麻煩。很多時候會考慮未來這個地方要拓展,所有就留著一個欄位放在那裡,結果前後端理解有差異,測試理解也有差異,該做的漏了做,不該做的卻做上去了,徒增麻煩。

4.在MVP期間,太遠的事別想,太複雜的方案別想,太難落地的方案別想。先確定一個基礎的目標,先完成再完美。初期以人工+系統的方式解決也未嘗不可,不一定任何事情都需要用系統來解決,別陷入“手裡有錘子,看啥都是釘子”的怪圈中。

5.設計核心業務方案的時候,別想著優化使用者體驗或者互動問題,瑣碎的事情專門去做,效率更高。例如專案初期的時候,沒有UI,沒有標準組件庫,然後在出原型的時候一方面要考慮業務的問題,另外一方面要考慮前端交付的問題,最後導致產品出原型慢,前端看到的交付物也丟三落四的,反而效率不高。還不如先專心搞業務的事情,然後統一時間或者讓專人來負責原型標準化元件,與前端交付的問題。

6.產品經理要敢於認錯,方案有問題,決策有問題,錯了就是錯了,坦坦蕩蕩地承認、道歉,然後及時改正。別羞於承認錯誤而固執堅持,最終專案失敗,辜負團隊眾多同事的心血,這樣的後果更加嚴重。

7.當面說,小會議說,然後文件說,需要循序漸進地來推進。很多時候產品經理自己寫了很多規範和標準放在原型的某個角落,然後群裡@各位開發、測試去看一下,這種情況下大多數人都不會去看,只有到用的時候,出問題的時候才回去查文件。團隊協作的規範推動是一個急不得的事情,只要還有問題沒解決,就需要不斷地強調和推動,過程會很累,但是這必不可少。

8.要給團隊清晰明確的規劃和指令,未來要做什麼,要做到什麼程度,這些規劃可能由於某些東西還不夠清晰,所以只存在產品經理自己的文件裡。不清晰的規劃別亂公佈,如果需要公佈則最好做好相應的註釋說明或者通過會議+文件的形式傳達。對產品經理來說,職業天性就是和模糊不定的東西打交道,而對開發和測試來說,清晰和準確無誤的資訊是他們特別在意關注的。所以產品需要將不確定性轉為確定性,將模糊的東西清晰化後,再準確無誤地傳達給他們。

#專欄作家#

我叫維他命(Vitamin),微信公眾號:PM維他命。前PHPer,做過線上教育類產品,也做過4年多的跨境倉儲物流方向的產品,目前是一位外貿SaaS領域的供應鏈產品經理。主要專注於WMS/OMS/TMS/BMS/ERP等領域,分享供應鏈相關的產品知識。

本文原創釋出於人人都是產品經理,未經作者許可,禁止轉載

題圖來自 Unsplash,基於 CC0 協議