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