文章為作者產品上線的項目復盤，希望能夠對產品路上的各位帶來一些啟發。
最近回顧了一下從去年年底到現在做過的兩個產品，一個是工具服務類，另一個是公司某業務線的官網；針對產品上線全流程，以復盤的角度，來講講背後踩的坑。
一句話感慨下：產品真難！
對行業知識不夠瞭解，需求分析跑偏。定位錯誤，導致產品調整。需求臨時變卦，功能刪刪改改…..這些基本踩過，且很痛，以下是文章目錄，一條條講吧！
01 不清楚產品服務對象，是慘痛教訓
兩項目其中一個來源於總監對業務的規劃，目的是 通過供應商對資源的有效競爭，來降低公司跨境物流成本；這個我最初的定位是做一個公司內部的工具。
另一個來源於公司產品的迭代，根據公司現有業務和未來發展，對官網前後臺進行重構。
工具產品一開始的定位太窄，產品服務對象沒搞清楚，對公司做這個產品的思考較少。如何站在公司業務角度思考需求，防止自己閉門造車呢？ 這裡根據案例整理兩個核心點：
1. 我們如何切換思維？
試著把公司人力當工具組件、把服務當商品，把用戶當買家。公司其實就是用工具組件製造商品，和用戶交易。
以工具 A 為例，最初定位是給內部員工用，整個鏈路是：用內部成本打造了一款商品，賣給了自己。既然都是賣，為何不多賣幾個。
2. 我們如何站在公司角度評估業務？
當你找老闆聊需求，總是會被問到：成本多少？收益多大？業務持續多久？ 從老闆的日常話語中，我們大概就能知道：產品價值 = 收益 – 成本。
最初工具 A的 收益是效率，成本是 技術開發 ，價值不好評估，可能收益不大；如果能開放使用，收益不會太局限，至於成不成就另外一回事了。
有時候，做產品的思維也可以運用到選職業：比如一份工作，收益是什麼，成本是什麼，持續性怎樣？
02 不瞭解行業信息，是慘痛教訓
瞭解行業信息其實就是調研，這個過程我有遇到了三個問題：
- 如何瞭解一個行業基本信息？
- 如何找目標用戶並調研？
- 如何評估對用戶瞭解程度？
1. 如何瞭解一個行業基本信息
為了熟悉行業知識，搜尋了相應資料。發現照搬有點不靠譜，太大而全，於是照貓畫虎，整理出來的東西好像很厲害，但肚子里真正沉澱的不多；
做了無用功，花了大把時間，還沒學到東西。
於是項目實踐後，我嘗試做一些刪減，個人覺得做好這三點是能對行業有一個基本瞭解的。
- 先瞭解行業基本信息：知乎、百度、谷歌上找，通過搜索我大概知道跨境電商行業，有倉儲、物流、採購、供應商、亞馬遜平臺等，再逐個細分下去深挖一下，我的知識面就更廣了；
- 瞭解業務流程，及上下游角色：躬身入局，親自實操一下；我們常用的做法是線下找相關崗位人觀察，聊天，主要看他們做的 事情和協同交流部分。
- 瞭解競品：有些行業信息競品是比我們更早察覺的，看看競品看他們的玩法，可以嘗試註冊，找他們的客服銷售問問題。
2. 目標用戶？怎麼調研？
B 端 尋找目標用戶，其實就是做場景的還原；比如做人力資源管理系統，我們需要找 HR 還原現場，溝通日常招聘、郵件發放、資料管理等。
在做場景還原的時候，發現自己沒有提前做問題大綱的習慣，導致最終的調研產出內容非常零散；這樣一來，需求分析是很容易出錯的。
其實找用戶調研的時候，很有必要提前準備一些問題，和用戶聊的時候思緒會更清晰。比如 提前整理表格，列出核心問題，儘量不做無效溝通。
類似於這樣：
3. 對用戶瞭解程度？
因為上一次調研，信息收集不全，導致後續自己三番五次 找用戶請教問題。
因為對用戶不夠瞭解，遇到任何規則的變化，我們很容易陷入聯想狀態，假設的越多，錯得也就越多。提供一個參考思路：
- 首先按照上述方式調研場景，整理並劃分好用戶基本類型和特征，這裡的特征不是性格特點，是用戶群體對行為的偏好。
- 針對不同用戶類型，若預測用戶在不同外部條件下的預期和行為，說明我們對用戶的掌握基本合格。
比如用戶登錄密碼錯誤，用戶可能會產生懊惱情緒，會嘗試找回密碼，感受用戶也是同理心的過程。
03 產品定位錯誤，是慘痛教訓
產品定位踩過的坑：產品定位有用戶、痛點、也有方案，但忽略了盈利和收益。
工具 A 最初定位是給內部使用，調研過程用戶述求不斷。讓自己陷入了功能堆積過程。剛開始的架構思路 大體上是這樣的：
後來站在其他公司的角度，發現需求依舊存在（有競品），於是在方案上加了一層用戶關係。把工具 A 迭代成服務平臺。這樣的改動，給產品帶來盈利的可能性。
錶面一些小改動，觸動的是後臺整個邏輯的修改。增加一層用戶，實際上後臺增加的有：賬戶體系、付費模塊、數據關聯表修改等。所以，做 B 端產品，決策路徑很長，千萬不能忽視了任何一個改動。
為了避免熬夜爆肝，產品設計之前，我們得先把定位想清楚。其次是，如果做一個產品，一開始就在不斷累加需求，多問問自己用戶是不是找對了。
04 產品設計不規範，是慘痛教訓
產品設計階段做的更多是模塊和流程性的梳理，先定義問題，再找場景，然後梳理規則，最後抽離模塊；比如這樣：
但這個過程也遇到了兩個問題，十分困擾。
- 產品設計如何避免東拼西湊，有條理進行展開？
- 功能和規則這麼多，配置怎麼做？
產品設計時感覺自己信心滿滿，業務催催需求，就亂了陣腳，跳過功能設計開始畫圖。結果證明，越畫越亂。
後來強迫自己回到正軌，會議、催需求，先晾著，完整流程先跑通（回顧一下我的整個流程）：
關於配置的問題：也是踩了太多坑，我們總想把所有功能都做成配置，用戶想要什麼，產品上給個界面，用戶自己設置。
於是在這種思路下，我發現最後出來的產品後臺，還沒上線就顯得十分臃腫。
過程中總結了部分規律，發現功能配置其實有一個核心思維在的：頻次 & 範圍 四象限；
像電商後臺產品，類似商品添加，價格設定這種，涵蓋用戶量大，且切換頻率較高的，妥妥的配置。
05 評審成批鬥會，是慘痛教訓
直到項目開發，我才發覺要檢查一下邏輯，看看文案，再想想交互。
於是準備不夠充分，評審會高光時刻成了批鬥會。業務會覺得比產品更懂需求，開發覺得邏輯理解優於產品。總之百口莫辯，事情講不清楚，一個問題 N 多方案。
後來自己整理了一張自查表，項目開發之前，我時不時就會看下，這裡分享一下：
06 需求失控是慘痛教訓
加需求了怎麼辦？
你是否有這樣的經歷：開發到一半，業務過來教你做人（做產品） 老闆或者業務咨詢一下需求狀況，靈感爆發，給我們提幾個優化，導致需求變更。
在做官網 B 產品的時候，我經歷了兩次官網核心下單業務的修改，主要是項目到開發階段了，業務對需求二次定義，麻煩的不是補充內容，而是在修改，產品邏輯改動，可能對產品最終的走向都會產生影響。
新增需求我們要看對現有影響，也要看是否可持續。其次產品設計階段，我們是比業務更懂產品邏輯的，如果需求不符合產品定位，可以打回去。即便是新增也要儘量歸併二期。
針對需求變動，在需求評審之前，很有必要拉上業務，將模塊、流程、原型和UI 進行共享，內容走查，確保需求完善。當然，也要有一定領導力，主動推進項目，給開發小哥一點關愛。
07 項目延期是慘痛教訓
項目延期了怎麼辦？
上線推遲，作為產品經理，我們怎麼都脫不了干係。
為減少推遲上線對業務的影響，可以嘗試：
- 提前制定里程碑：在什麼時間點完成那些核心功能，提前準備內容；
- 上線二次預估：預計推遲到什麼時候，保證後續資源能繼續開發；
- 廣而告之：將里程碑、現有進度、發佈時間和開發 及 業務多方確認，想辦法分配資源。
過程中，主人翁意識強一點，專業度就會有提升，別人會覺得我們靠譜。
總之讓產品由我們掌控，把問題扼殺在過程，不能等到開發上線後再解決。
08 關於迭代的思考和復盤感悟
B 端產品迭代的思考
產品進階是一個緩慢迭代過程，B 端類產品升級頻率較低，但並不意味不需要迭代。這次實踐過程，讓我體會到 B 端產品更需要 關註變化。“牛鞭效應”就是一個很好的例子。
系統服務類的產品 實際上非常個性化的，本質原因就是因為場景的不同。比如我們把一個產品開放，即便基本模塊都有，遇上不同客戶，定製化需求依舊很多。
系統服務類的產品很多時候是在還原 場景，服務多少企業，可能就有多少種服務方式。
所以，B端產品個性化是件好事，很多企業初期就是在提供個性化服務，待成型，才考慮標準化。
最後分享復盤的五點感悟：
- 問題複雜度越高，解決過程越投入，成長也會更快；
- 產品方法論終究是方法，實踐內容和結果還是得自己慢慢找；
- 如果解決問題的方案過於複雜，不糾結，有可能是問題本身不對；
- 以用戶角度看問題，以生意角度思考業務，比如收益、成本，是否一直存在；
- 復盤包含：實踐、思考、回顧、調整，難在調整，因為是推翻自己的過程；
本文以自己項目經歷在此拋磚引玉，如果大家有不同意見歡迎一起交流。希望能和喜歡寫字的你，交個朋友。
本文由 @好奇產品鋪 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。