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

大概在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 協議

,