文章為作者產品上線的項目復盤，希望能夠對產品路上的各位帶來一些啟發。
最近回顧了一下從去年年底到現在做過的兩個 B 端產品，從需求調研到產品設計再到最後上線落地，耗時接近4個月；整體來看，時間有點超出預期。作為產品經理的我，有很大一部分責任的。
從開始的行業不夠了解，需求分析跑偏。到定位錯誤，導致產品調整。也經歷需求臨時變卦，功能不斷修改調整……不過，好在項目最終都順利上線！
發表一下感慨：產品真難！
不過這些坑都是非常寶貴的經歷，對於產品而言，如果能有效地進行思考、復盤、調整，或許能帶來很多新的東西。
那過程中，我究竟經歷了踩了哪些坑呢，以下是文章目錄，我們一條條看！
兩項目其中一個來源於總監對業務的規劃，目的是 通過供應商對資源的有效競爭，來降低公司跨境物流成本；這個我最初的定位是做一個公司內部的工具。另一個來源於公司產品的迭代，根據公司現有業務和未來發展，對官網前後臺進行重構。
這兩個產品說不上多大的工程，但對我而言已經很滿足，至少讓我有了產品從零到一，上線並給用戶使用的經歷。當親眼看到後臺有新增用戶註冊，使用產品的時候，感覺又心酸又有成就感。
其實工具產品一開始的定位太窄，產品服務對象沒搞清楚，對公司做這個產品的思考較少，類似於跟著別人思維走。比如，公司總監告訴我需要滿足什麼樣的需求，我總是站在他的立場上，想著如何設計一個產品，高效地滿足他所提出的這些問題。
現在我仔細回顧決策的過程，發現問題的根本原因在於：我忽略需求分析階段，思考方式的重要性，而是跳過了頭腦風暴階段，習慣性地直接做流程梳理。
這個問題很嚴重，要想辦法養成習慣避免；那我們如何站在公司業務角度思考需求，防止自己閉門造車呢？ 這裡根據案例，復盤整理了兩個核心點：
試著把公司人力當工具組件、把服務當商品，把用戶當買家。公司其實就是用工具組件製造商品，和用戶交易。
以工具 A 為例，最初定位是給內部員工用，整個鏈路是：用內部成本打造了一款商品，賣給了自己。既然都是賣，那我可不可以賣給其他有需求的用戶，那其他有需求的用戶是誰？我要不找找看有沒有這樣的用戶？
後來經過自己對競品調研，發現需求和用戶都存在，提供服務的公司還不小。
當你找老闆聊需求，總是會被問到：成本多少？收益多大？業務持續多久？ 從老闆的日常話語中，我們大概就能知道：產品價值 = 收益 – 成本。
最初工具 A的 收益是效率，成本是 技術開發 ，價值不好評估，可能收益不大；如果能開放使用，至少未來不會太局限，如果有機會做出來，也是盈利的機會。
總監經常和我說，產品設計其實是在設計一項業務，任何一項服務的打磨，都要當成是一門生意來看待。仔細回味這句話，確實沒毛病。
站在公司角度思考業務，其實就是一種向上思考的過程。這種產品思維日常培養很重要，也非常實用。比如找一份工作的時候，思考自己的收益是什麼，付出哪些成本，持續性怎樣？
第一點中，我們說到產品設計是設計一項業務。而業務其實是市場和行業背景下催生的產物，一個運轉過程。所以從這個角度來看，自己一開始對行業信息懵懵懂懂就開始設計產品，明顯踩坑太深。
了解行業信息其實就是調研，這個過程我有遇到了三個問題：
為了熟悉行業知識，搜尋了相應資料。發現照搬有點不靠譜，太大而全，於是照貓畫虎，整理出來的東西好像很厲害，但肚子裡真正沉澱的不多；
做了無用功，花了大把時間，還沒學到東西。
於是項目實踐後，我嘗試做一些刪減，個人覺得做好這三點是能對行業有一個基本了解的。
回顧這個過程，其實還蠻有意思的：為了了解競品流程，自己模擬下單遇到問題，說沒辦法解決。最後加了對方微信，還拋出一大堆疑問諮詢。這個方式，你也可以試試。
B 端 尋找目標用戶，其實就是做場景的還原；比如做人力資源管理系統，我們需要找 HR 還原現場，溝通日常招聘、郵件發放、資料管理等。
在做場景還原的時候，發現自己沒有提前做問題大綱的習慣，導致最終的調研產出內容非常零散；這樣一來，需求分析是很容易出錯的。
其實找用戶調研的時候，很有必要提前準備一些問題，和用戶聊的時候思緒會更清晰。比如 提前整理表格，列出核心問題，儘量不做無效溝通。
這裡要注意的是，在問題設計上也有一定的學問，線下調研因為過程比較開放，話題相對問卷調研來說，思維不會閉塞。所以線下面對面溝通的過程中，問題要儘量針對關鍵點，提一些開放性的問題，讓用戶盡情表達自己的觀點。
給一個模板例子希望能給你參考：
因為上一次調研，信息收集不全，導致後續自己三番五次 找用戶請教問題。
因為對用戶不夠了解，遇到任何規則的變化，我們很容易陷入聯想狀態，假設的越多，錯得也就越多。提供一個參考思路：
比如用戶登錄密碼錯誤，用戶可能會產生懊惱情緒，會嘗試找回密碼，感受用戶也是同理心的過程。
產品定位的調整，是血淋淋的教訓。第一點中有說到產品定位太窄。那現在，我針對這個坑點，來說說定位調整，給產品帶來的影響。
產品定位踩過的坑：產品定位有用戶、痛點、也有方案，但忽略了盈利和收益。
工具 A 最初定位是給內部使用，調研過程用戶述求不斷。讓自己陷入了功能堆積過程。剛開始的架構思路 大體上是這樣的：公司產品設計人員 負責打磨服務，產品管理人員負責運營管理，吸引客戶和我們籤約，服務售賣。
簡單的看，是能夠滿足公司目前的業務，但總監看了之後和我說：我讓你設計，是讓你打磨出來，日後拿出來給 合作公司用，我是要收費賺錢的，聽完恍然大悟。
後來站在其他公司的角度，發現需求依舊存在（有競品），於是在方案上加了一層用戶關係。把工具 A 迭代成服務平臺。這樣的改動，給產品帶來盈利的可能性。
表面一些小改動，觸動的是後臺整個邏輯的修改。增加一層用戶，實際上後臺增加的有：帳戶體系、付費模塊、數據關聯表修改等。所以，做 B 端產品，決策路徑很長，千萬不能忽視了任何一個改動。
做出決定修改之後的一周，我將需求重新整理，按照調研的方式進行問題回訪。對場景的規則和模塊二次補充。產品工作倒無所謂，最可怕的是開發小哥因為我的調整，最終結項時間推遲一周多。
為了避免熬夜爆肝，產品設計之前，我們得先把定位想清楚。其次是，如果做一個產品，一開始就在不斷累加需求，多問問自己用戶是不是找對了。
經過這次項目經歷，讓我對經驗和方法的重要性，有了新的定義：經驗是輪子，給不了我們建設性的創新，但能避免我們在一條錯誤的路上，越走越遠。
產品設計階段做的更多是模塊和流程性的梳理，先定義問題，再找場景，然後梳理規則，最後抽離模塊；比如這樣：
但這個過程也遇到了兩個問題，十分困擾。
產品設計時感覺自己信心滿滿，業務催催需求，就亂了陣腳，跳過功能設計開始畫圖。結果證明，越畫越亂。
後來強迫自己回到正軌，會議、催需求，先晾著，完整流程先跑通（回顧一下我的整個流程，如果感興趣，可以給我留言，後續加油補充）：
關於配置的問題：也是踩了太多坑，我們總想把所有功能都做成配置，用戶想要什麼，產品上給個界面，用戶自己設置。
於是在這種思路下，我發現最後出來的產品後臺，還沒上線就顯得十分臃腫。
過程中總結了部分規律，發現功能配置其實有一個核心思維在的：頻次 & 範圍 四象限：頻次越高，說明使用非常頻繁，用戶量大，說明需求的集合也就越大，所以結合這兩者進行思考配置功能，再適合不過。
以下為詳情：
像電商後臺產品，類似商品添加，價格設定這種，涵蓋用戶量大，且切換頻率較高的，妥妥的配置。
直到項目開發，我才發覺要檢查一下邏輯，看看文案，再想想交互。
於是準備不夠充分，評審會高光時刻成了批鬥會。業務會覺得比產品更懂需求，開發覺得邏輯理解優於產品。總之百口莫辯，事情講不清楚，一個問題 N 多方案。
後來自己整理了一張自查表，項目開發之前，我時不時就會看下，這裡分享一下：
按照這樣的流程將自己的產品原型 從頭到尾的梳理，假以時日，我們的產品邏輯肯定日飛沖天（雞湯句哈）！
加需求了怎麼辦？
你是否有這樣的經歷：開發到一半，業務過來教你做人（做產品） 老闆或者業務諮詢一下需求狀況，靈感爆發，給我們提幾個優化，導致需求變更。
在做官網 B 產品的時候，我經歷了兩次官網核心下單業務的修改，主要是項目到開發階段了，業務對需求二次定義，麻煩的不是補充內容，而是在修改，產品邏輯改動，可能對產品最終的走向都會產生影響。
新增需求我們要看對現有影響，也要看是否可持續。其次產品設計階段，我們是比業務更懂產品邏輯的，如果需求對現有影響範圍過大，不可持續，不符合產品定位，可以打回去。即便是新增也要儘量歸併二期。
針對需求變動，在需求評審之前，很有必要拉上業務，將模塊、流程、原型和UI 進行共享，內容走查，確保需求完善。當然，也要有一定領導力，主動推進項目，給開發小哥一點關愛。
項目延期了怎麼辦？
上線推遲，作為產品經理，我們怎麼都脫不了干係。
為減少推遲上線對業務的影響，可以嘗試：
過程中，主人翁意識強一點，專業度就會有提升，別人會覺得我們靠譜。
總之讓產品由我們掌控，把問題扼殺在過程，不能等到開發上線後再解決。
產品進階是一個緩慢迭代過程，B 端類產品升級頻率較低，但並不意味不需要迭代。這次實踐過程，讓我體會到 B 端產品更需要 關注變化。「牛鞭效應」就是一個很好的例子。
系統服務類的產品 實際上非常個性化的，本質原因就是因為場景的不同。比如我們把一個產品開放，即便基本模塊都有，遇上不同客戶，定製化需求依舊很多。
系統服務類的產品很多時候是在還原 場景，服務多少企業，可能就有多少種服務方式。
所以，B端產品個性化是件好事，很多企業初期就是在提供個性化服務，待成型，才考慮標準化。
最後分享復盤的五點感悟：
本文以自己項目經歷在此拋磚引玉，如果大家有不同意見歡迎一起交流。希望能和喜歡寫字的你，交個朋友。
本文由 @好奇產品鋪 原創發布於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。