編輯導語：本文作者總結了自己3年C端、5年B端產品路的產品修煉感悟，從產品、管理、思維等方面進行了分析，希望能給你帶來幫助。

歲月不居，時節如流，不知不覺已走過3年C端、5年B端產品路，從0到1，做成了幾款產品，現將我這八年的產品修煉感悟總結出來，與大家交流。

一、產品設計&需求管理

功能上線沒有人用怎么辦？考慮功能入口是否隱蔽，低頻功能入口可以放到高頻頁面中來提升用戶使用率，引用Ant Design聯合創始人林外的一句話就是，“讓功能找用戶”。

比如，在某平臺的需求管理子系統中，需求評價功能上線后無人使用，如何優化呢？僅需把需求評價放到平臺首頁待辦中（首頁是高頻，每日都進），待辦有郵件提醒（郵箱更是高頻，打工人必用）。

MVP最小可行性產品策略真是太香了，但在乞丐版產品上線后，耐得住寂寞是成功的關鍵，一開始的用戶數據必然不會太好也不要強推，驗證產品方向正確后，這時產品經理只需要抓住關鍵用戶，與用戶一起打磨產品。

打磨一段時間后，就是大規模推廣階段，這時數據會隨著時間的推移呈上升曲線，有用戶，就有反饋，這個產品就被打磨的越來越好，產生正向飛輪效應。

在做平臺類產品時，一個產品有多個子系統，有時子系統的產品設計人員會局限在自己負責的子系統內部進行設計，不與平臺及其他子系統產生關聯。

我們拿故障管理功能舉例，如果故障發現、故障調度、故障工單、故障處置互為孤島，那用戶需要在這4個子系統中來回跳轉，體驗極不連貫，產品經理需要有整體的思維，端到端的設計解決方案。

產品設計不要大而全，面面俱到。道理都知道，尤其在外采項目中很難執行，想著采購周期長，后期加需求難。采購項目一期的時候建議小兒精，用戶用的好了，自然會提新需求，項目都是漸進明細的，大而全的產品設計必然考慮不周，資源鋪不開，后期還需返工。

B端公司內部產品的用戶提的需求，不一定是他想要的，需求收集時會邀請相關干系團隊，各團隊派一名代表提需求，有些代表擔心漏提需求未來加需求難，把能想到的需求都提了一遍，有些代表其實沒有需求，但是看到別的代表都提了，自己感覺不提虧了，產品經理不是用戶的傳聲筒，用戶不能講清楚需求是常態，產品經理應該識別目標用戶，挖掘本質需求，排除偽需求。

在需求評審階段發現問題，比在測試及交付階段發現問題，付出的時間和人力成本要小的多。

熟讀唐詩三百首，不會作詩也會吟。產品經理需要多看、多體驗各種產品，在做產品設計時，會發現自己有了信手拈來的能力。

產品經理需要做好需求后評估，有些用戶提的需求上線后沒有使用，下次這個用戶提的需求，就應該調低優先級。

二、迭代管理&項目管理

迭代時間真是越短越好嗎？是不是把迭代周期縮短就能做更多需求了？針對小型項目的的答案是：是的（迭代周期1-2周都行）?！犊窗鍖崙稹芬粫ㄟ^便士（硬幣）傳遞游戲直觀的告訴我們，限制在制品（需求）的數量，促進工作快速流動，軟件交付的速度更快、數量更多。

但是針對大型復雜項目不適合將迭代時間安排的太短，著名架構師郭東白在《如何組織階段性的價值交付》一文中寫到：“大項目的聯調成本很高，交付過于頻繁會會打亂研發節奏”，復雜的團隊聯調和溝通成本高是常態，在做項目計劃的時候，這部分的時間成本需要考慮進來的（建議3周及以上最佳）。

世界上最快的速度是勻速運動，研發團隊的研發節奏、默契感一旦形成，將收獲穩定的產出。

不要小看每日站會的力量，每日花的時間不多，卻能讓團隊成員目標感更強，大家說自己的進度、需要別人配合的、遇到的問題，一起討論解決，每個人的進度透明，項目進度和風險就可控了。

需求文檔和測試數據如果可以一直提前一個迭代完成，就能保證后端資源最大化利用。

一個再厲害的產品經理，遇上能力、執行力低的研發團隊，也拿不到好的結果?！度嗽律裨挕芬粫袑懙?，一次實際項目的測量結果：“最好的和最差的程序員表現在生產率上的差異平均為10：1?！庇袝r候項目能拿到好結果，是整個團隊共同努力的結果。不要把團隊的成功，當成產品經理自己的成功，空杯心態。

一個再小的需求，并沒有我們想象的小，小需求也會涉及到產品、后端、數據開發、測試、部署5個項目成員，項目成員越多溝通成本越高。

少量經驗不足程序員在技術評估方案時比較樂觀時，這時作為產品經理一定要請他三思，請研發經理再次評估，方案工時需要在一開始評估好，避免后期出現多次反復。

接手一個歷史項目，比從0 到1新開發一個項目難的多，梳理和學習歷史項目的時間成本需要考慮。

跟軟件廠商合作，需要做好教練工作，什么時間做什么事情，完成標準是什么，不要給廠商太多的冗余時間，因為不給廠商壓力，廠商的時間就可能會用到其他項目上。

遇到過少量程序員，喜歡用即時通訊軟件打字溝通，別人沒有回復也不跟進了，可能進度就卡住了。建議如果在自己的項目中，遇到該類程序員，需要在團隊內培訓大家遇到卡住的問題直接電話呼過去，積極主動。

這是我們的研發諸經理經常給項目成員強調的話：“目標為導向，要先解決阻塞自己的問題，我不管你在干嘛，你給先配合我解決我的問題，如果對方時間上影響到我們的項目或是不配合，需要第一時間上報研發經理、產品經理”。

產品經理需要和運維團隊分割好各自的領域，如果用戶線上使用問題、BUG都來找產品經理，產品經理還有精力做其他事情嗎？方法是交維時配置產品撥測和告警，產品有異常告警派單給運維人員處理。

各種評審，是收集各個領域的意見，完善自己方案的必備過程，人無完人，查漏補缺。

避免變更升級當晚狀態頻出，需要提前做好變更評審，核對變更前的checklist。管理好自己的上下游，約定好上游變更時，一定要通知我們，我們自己變更時，也會通知下游。

三、思維升級&影響力

產品經理需要處理好整體和局部的關系，面臨業務復雜、多團隊&多模塊的跨領域整合難點，如果是涉及跨域管理的產品經理需要有從整體視角出發，如果是子域的產品經理，切忌不要過度優化，局部利益服從整體利益。

著名供應鏈管理專家劉寶紅在其書《供應鏈管理：高成本、高庫存、重資產的解決方案》中寫道：“有些民營企業實現了訂單、料號層次的最優，比如成本最低，卻以供應商層面的最大優化為代價。供應商層次的大優化總體上可彌補料號、訂單層次的不優化，但料號、訂單層次的優化很難彌補供應商層次的不優化。沒有統一的供應商管理流程，就不可能有一致的、可預見的供應商管理結果”。

盡可能多地參加比賽。2021年，我們團隊打造的兩個產品獲得了公司在崗革新二等獎、公司研發管理最佳實踐二等獎、部門內部打榜兩個一等獎，比賽獲獎可以讓團隊成員獲得自信、獎金和名氣的激勵，也可調動項目成員的積極性，提升團隊凝聚力。

內部工具產品，就是用于效率提升的，為業務帶來了什么，效果最好有一些數據化的東西去呈現，比如用戶規模、使用情況、使用后的業務指標有沒有提升，有沒有提升了滿意度等。這些指標最好可以做成在線報表，可以節約拉數據人工統計數據的重復工作量。

功能升級后的階段性培訓可以增加與用戶的接觸次數，也是提升影響力的一種方式。

產品經理如果自身夠專業、自律、愛學習，在朋友圈分享自己的心得的同時，順便刷個臉熟，得到大多數人的好感，會發現自己在協調項目的時候更順暢。

四、心態管理

別讓自己忙到沒有時間思考。作家九邊在自己的書《向上生長》中給我們介紹了熱力學第二定律：“孤立的系統不持續輸入能量就是死路一條”。產品經理如果不能從外部輸入不一樣的能量，那成長速度將是緩慢的。

每個人都有遇到不公平待遇，內心郁悶、自我懷疑的時候，該如何快速走出心魔呢？我們都知道大型比賽的評分，為了保持客觀公正，都是要去除一個最高分，去除一個最低分，而這個給我們不公平待遇的人的評價其實就是最低分，應該是無效的，不應該對我們造成傷害。內心一定要強大，自信的人是無敵的！

負能量的人悲觀、做什么都提不起勁，自然會一事無成。如何才能改變呢？答案是少想多做。把我什么都做不成的想法，改成先做了再說立即行動！學到新知識，想到了一個好的點子，都會讓人心情開心，不要一直想自己無能為力的事情，繞過它，去做能讓自己開心的事情。一個正能量的人，會自信發光、身上有花不完的勁。千磨萬擊還堅勁，任爾東西南北風！

手不釋卷，越讀書，越發現自己的淺薄，終身學習。華杉、馮唐、俞敏洪、余世維等等都是愛讀書的前輩。不能只讀技術相關書籍了，需要拓展閱讀心理學、社會學、經濟學、歷史相關的書籍，便于我們能夠更好地理解人性、理解這個世界的底層邏輯。

無我，放下以自我為中心，從社會導向來思考，不計回報地做有意義的事情，會讓人成就感滿滿，愿我們出走半生，歸來仍是少年！

參考資料：

1、文章《前饋：讓功能找到用戶》林外：https://mp.weixin.qq.com/s/bJuGQqE-1K4JPLHBwrcYIQ

2、《看板實戰》（瑞典）哈馬伯格，（瑞典）森頓著. ——北京：人民郵電出版社，2016.1

3、文章《如何組織階段性的價值交付》郭東白：https://time.geekbang.org/column/article/c8d4806af8578be483719ffbbea40b9e/share?code=MjHN-6SA7Vf8-MyUcubIAkd%2F64BL0w7NCjaiVQg9TYA%3D&source=app_share

4、《人月神話》（美）布魯克斯著. ——北京：清華大學出版社，2007.9

5、《供應鏈管理：高成本、高庫存、重資產的解決方案》劉寶紅著. ——北京：機械工業出版社，2016.4

6、《向上生長》九邊著. ——貴陽：貴州人民出版社，2020.6

#專欄作家#

沈子硯，公眾號：ziyan-shen，人人都是產品經理專欄作家。用戶體驗專家、PMP項目管理專業人士，3年C端、5年B端，從0到1，做成了幾款產品。

本文原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議