起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識To B｜做項目的無私與自私
編輯導語：產品經理在進行產品規劃時，需要考慮到多個方面；站在客戶層面，產品經理需要洞察客戶的真正需求，解決客戶的核心問題；而站在團隊層面，產品經理需要思考如何協調人員分配、并降低項目的開發成本，實現降本增效。不妨看看作者的經驗總結，也許會對你有所啟發。
提到產品規劃，我們一般都會有慣用套路，比如從行業調研、客戶需求分析、競品摸底、產品價值本身等分別去切入，先發散再聚焦……
說起來頭頭是道，做起來并不輕松?，F在換個情境，當你深入到前線做項目時，面對客戶源源不斷的訴求時，怎么辦？
注意，此時你不僅是產品經理，你還是項目的核心成員，你該如何去權衡二者的關系？
事實上，做to B產品的團隊，大部分在高價值方案的沉淀和復制上都做得不足，很多時候基本都是貼著客戶需求做項目，缺少了打磨和沉淀優質產品。
于是愈演愈烈，做項目的過程中不僅不夠聚焦，甚至動到了其他團隊的蛋糕，產品邊界沒劃清，客戶方案也頻頻返工，如此下去，更別提卡位行業KA客戶了。
眾所周知，任何業務發展都會經歷一個過程，面對不同層級的客戶也會有不同的策略，你心中要有一把秤，一邊是你的產品和業務，一邊是你服務的客戶。仔細掂量下當下業務和客戶的輕重，無法望其項背還是勢均力敵？
誠然，早期業務需要求生存，在打標桿階段，往往需要投入更多來確保項目成功，提供客戶全方位的貼身服務，一切以客戶口碑為目標；隨著產品與方案逐步穩定和完善，服務與管理體系逐步標準和成熟，你可以嘗試引入合作伙伴來完成部署實施（若是私有化產品）、集成與交付、定制開發、運營運維服務，再從集成產品過渡到產品被集成，去發展更健康的業務結構。
話雖如此，在真正深耕一個客戶項目時，如何權衡客戶訴求的合理性，再最大限度地實現完整功能的閉環，并且能做到將項目上的成果復制到其他項目里實現事半功倍，是每一位產品經理作為項目成員時要時刻思考和提升的地方。
一、無私的：錨定客戶需求場景的本質
先明確一個概念：什么是客戶需求？
無論你的產品處于什么樣的發展階段，一旦它開始有自己服務的客戶群，必然伴隨著客戶的聲音。不得不承認一點，客戶用得好，大概率不會告訴你；但客戶吐槽你不好，不管反饋渠道有多曲折，你總會聽得見，甚至是振聾發聵。
而當我們接收到客戶需求時，總會下意識去了解這是出自客戶側的什么角色，繼而了解需求的緊急程度、預期交付時間等，缺乏對需求本身的進一步探索。
首先搞明白，客戶提出的需求是出自什么目的？到底是要解決客戶業務上的什么痛點呢，還是要給客戶的業務做創新呢？
如果是為了解決業務痛點，不妨去了解客戶當前遇到的問題，在沒引入新方案之前怎么解決的，現有方案存在什么不足，還可以從哪些維度去改進。
尤其在行業內卷的時代，痛點變得非常隱秘，如果你發現不了，解決不了，那你只能一味地被卷進無窮無盡的需求漩渦里，爬出來的勝算不大。
- 要解決什么問題？為什么非解決不可？影響面有多大？不解決可以嗎？
- 以前是怎么做的？別的企業是怎么做的？存在什么不足？
- 這些問題里你最想解決的是哪一點？之前的方案你最無法忍受的是哪一點？
如果是為了搞業務創新，你的關注點就完全不同了。
- 客戶前幾年有沒有做過創新業務，效果怎么樣，有沒有用起來？
- 客戶有沒有在學習和借鑒的其他企業，對這些標桿企業的哪些業務有興趣？
- 客戶決策者本人的訴求，是否在事業上有追求，希望能出成績、盡快出成績？
理清客戶提需求的目的，是業務痛點還是業務創新，我們才能有目的地去拆解需求：該砍的需求就不要手軟，該博弈的就和客戶磋商，該接受的就組織評估產品方案，再客觀權衡新方案相比原有的方案的區別與優勢，以此來進一步打動客戶。
舉個例子，之前我在一個大型政府項目里做過一套輕量的任務督辦系統，該產品有強業務屬性，但又不全是為了替換政府內現有的督辦系統，于是初期我們花了不少時間和客戶開展調研工作。
經了解，現有方案里客戶側所有的督辦任務均由紙質文件蓋章審批后逐層流轉，定期再由各單位負責人逐一核實任務進度，填報督辦任務表，這中間耗費巨大的人力和精力，費力不討好，數據的完整性和精確性也有待商榷。
于是我們在設計產品的時候，從任務的創建（數據來源可能是客戶自身的督查督辦系統，或是自行創建任務）、任務的辦理（包括多人的協同辦理）、任務的進展反饋、辦結等全流程進行梳理，并針對不同版塊劃分不同的角色和權限。甚至在第一個版本挖掘需求場景時，考慮到在政府內實際辦公場景下，不少任務都是委派給各辦公室領導，再由領導分發子任務到對應的辦理人。
于是我們又基于任務衍生了關聯任務，并花了不少時間琢磨不同角色對于不同任務單據的權限，基于各自的權限去看是否能將任務督辦集成現有的平臺能力，比如快速喚起選人組件、一鍵發起群聊、一鍵拉起會議、所有任務流轉的進程可快速通知到任務干系人，等等。
我們信心滿滿，我們斗志昂揚，然后挑了一個良辰吉日給客戶鑒定方案，客戶第一句話就是：我要的督辦一覽表呢？
傻眼了。
的確，你的任務督辦系統做得挺完善，你自覺把業務的全流程管理考慮得無比周全，但你沒解決客戶最核心的痛點，那他憑什么來用你的產品？
回歸初心，回歸產品要提供給客戶的本質價值，究竟這個產品是要解決業務痛點，還是想做業務創新？
其次，把握好客戶的需求場景，并把握好一個度，在這個場景的彈性區間內去試探客戶的底線，試探產品的底線?？蛻舻男枨竽康母忝靼琢耍谠撃康囊采w的客戶場景是什么，這一點必須反復去挖掘和分析。
記住，客戶的需求，不是一個人的抽象需求，而是特定場景下的需求。
我們常說，設計功能之前搞明白客戶的需求場景，本質上說的就是這一回事。
還是以上述的任務督辦應用為例，客戶最核心要解決的是“快速導出督辦一覽表”的問題，基于該目的倒逼我們思索一個命題：如何快速導出督辦一覽表？
這個命題里涉及到幾個元素：誰能導數據？數據類型和范圍是什么？如何操作起來更敏捷？
- 誰能導出數據：涉及到角色和權限項的設計；
- 數據類型和范圍：涉及到數據來源（與其他系統的集成或是自身系統的數據承載）、數據管理（增刪改查）、數據運營（可視化分析）、數據安全審計等；
- 怎么操作：導出表格、開放api接口等都是可行的辦法。
你看，基于目的出發再去分析客戶場景，才算得上真正地從需求場景出發。
如果梳理出來的場景較多，能投入到產品研發的資源又少，與其試圖去覆蓋每一個場景，但又經不起推敲，還不如做深哪怕一個場景，小步快跑，持續迭代和優化。
當然，你還可能遇到一種情況，客戶的需求并沒有想得那么清楚，在沒有明確需求目的和需求場景下，怎么去提煉需求呢？
請注意，即便客戶沒有明確場景，我們也要創造場景。
創造場景就是給客戶定義一條路，給客戶遞上一個臺階，讓他自然地踏上去。
比如天貓淘寶上的7天無理由退換貨，很久以前都是由買家自行承擔訂單帶來的不確定風險，自從2008年淘寶的“消費者保障計劃”進入第二階段，商戶一旦選擇加入這項服務后，由商戶替你承擔該風險，免去你的后顧之憂。
都說網絡購物是“隔山打?！?，尤其是針對消費者最底層需求的領域，“7天無理由退換貨”算是給消費者戴上了護身符，給賣家套上了緊箍咒，創造一個“你放心購買，后果由我兜底”的場景，完成用戶價值的創造。
二、自私的：項目復盤與項目復制
前文提到，即便你考慮到客戶最本質的訴求，但你依然是在貼著客戶做需求，換個項目還要從頭再來，這跟我們的初衷背道而馳，不是嗎？
當你融入一個項目時，你考慮的是怎么更快更好地滿足這單客戶的訴求，為此你會分析這個客戶的需求，盡可能將客戶訴求產品化。這都沒錯，但攤平該項目到所有的項目大盤里，你再來看這件事，投入產出比就相當低了。
我始終認為，做項目的時候你要夾帶私心，跳出來想一想，該項目結束后，你做過的功能、設計過的流程、battle過的方案，是否可以復用到其他項目？
在考慮復制之前，首先要學會復盤項目。
這就好比拉片子，一個學習小組分工合作，逐格、逐句地解讀電影和電視劇，通過細致地觀摩，全面掌握片中的內容、風格與技巧，系統地分析一部影片。雖說這是影視編劇學習的常用方法，但放在復盤項目的情景下也同樣適用。
如果你正處于項目的建設過程中，不妨組織項目核心成員在各自負責的模塊里養成隨時記錄項目筆記的習慣，分階段去審視，甚至是分化出旁觀者的視角去審視發生的事情，比如你在不同階段下遇到了什么問題，提出了什么假設，與哪些角色進行了什么樣的探討或切磋，最終為什么選定了這個方案而不是其他方案，后續還打算怎么做，原因是什么……
為什么我鼓勵你記錄這些過程性的客觀事實和觀點？
翻開你復盤過的項目，發現了沒？是不是說盡項目的成果，產品的成功或失敗，每個人的功勞與苦勞……這的確是可喜可賀，但這樣的復盤對其他項目幫助不大，無法對復制項目提供參考價值。
復盤項目是為了還原項目成功或失敗的全過程，而不僅是擺結果邀功鳴謝。這并不是你事后一拍腦袋，問幾個人就能整理出來的，這可是“項目的一生”，你要成為它的傳記編寫者。
如同一個專業畫家臨摹一幅好畫，如果僅僅描繪出輪廓就等于什么也沒看到。他應該看到的是構圖、色彩、技法、步驟、情感表達方式等大到整體、小到非常具體而瑣碎的別人不屑看或看不出來的內容。
你要知道，大到團隊、小到個人做的某件事、某個決策的成與敗，原因究竟是什么。很多時候哪怕是成功的項目，項目成員也經常不知道究竟是怎么成功的，于是在之后即便是同一撥人交付相似的項目，做起來還是很吃力，甚至很難保持這種成功。
再來說項目復制。
實話說，這四個字本身就是個偽命題。不存在兩個完全相同的人，也不會存在兩個完全相同的項目。所以與其說是復制項目，不如說是最大限度地站在前個項目的肩膀上，盡可能地重復利用數據和服務。
只要你留心到這一點，很多動作就更有指向性了。
1）在你建設產品的過程中，你會刻意加強產品功能的延展性，比如接口的開放性，提煉通用的公共組件，適用于不同產品在不同場景下的能力補充。
我在做項目之前，一直都清楚跨產品集成的難度，通過項目的驅動，至少在利益和意愿上各方有相對更強的合作動力。那么接下來的問題就是：
- 針對本項目，如何區分不同的應用場景更好更快地集成某個產品或平臺，補齊產品能力，縮小與實際客戶場景的gap；
- 針對其他項目，如何做到產品集成的流程是清晰的、流暢的，換個項目也能如法炮制，換個集成商也能勝任，你無需額外再去投產品資源。
2）在你階段性完成產品建設后，產品標準化也要開始籌備起來，包括：
- 產品本身能力的標準化沉淀：哪些能力可以原子化，適用于什么場景，是否需要定制開發？
- 文檔標準化：面向內部團隊、面向客戶和合作伙伴的標準化文檔的梳理，比如助銷、交付、運營、運維資料等，都會成為后續其他項目學習的彈藥庫；
- 流程標準化：項目中涉及到的合作伙伴、合作團隊之間的配合機制和流程的標準化，換個項目，換個合作伙伴也可以按照同樣的合作模式去開展工作；
- 項目模式標準化：建團隊、定機制、定規范，這三板斧無論在哪個項目里都需要，什么人在什么機制下以什么標準規范去做事，這是項目運作模式的根基，也是最關鍵的部分。
當然，基于具體項目所做的所有復盤和標準化沉淀，都不一定能有效地解決其他某個項目的問題。
不妨試著跳出某個具體項目，針對核心攻堅的項目，全面做一次復盤。
我非常建議團隊作戰，所有參與過不同項目的同事一起攤平所有項目，整理出最佳實踐，分類型分緯度分打法；再來看有哪些共性的部分，可以復用到大多數的項目里，哪些個性的部分，是尤其要注意和規避風險的，以此來形成行業拓展的系統打法。
三、飛輪效應
亞馬遜CEO貝佐斯反復強調過一個商業理念：飛輪效應（Flywheel effect)，即：
一個公司的各個業務模塊之間，會有機地相互推動，就像咬合的齒輪一樣互相帶動。一開始從靜止到轉動需要花比較大的力氣，但每一圈的努力都不會白費，一旦轉動起來，齒輪就會轉得越來越快。
同樣的，在你做每個項目的過程中，一開始你會痛苦、難受，隨著團隊建立、資源到位、機制明確下來之后，之后的每一次交付和驗收都會更加胸有成竹。非要說這其中的關鍵要素是什么，絕對不僅是產品或研發能決定的，而是整個項目團隊共同的決策與執行。
王俊煜老師打過一個比方：
有時候企業就像一個飛速上升的電梯。電梯里有人靜靜地站著、有人在倒立、有人在不停地跑圈，最后等電梯上到最高層的時候，每個人都認為自己做的事，才是讓這個電梯上來的最重要的原因。
但實際上我們都清楚不是這樣的。
那你說，產品經理在這過程中究竟能發揮多大的力量？
可大可小。
你滿腔熱血拿下這一票，給客戶提供周到的貼身服務是很好；但如果你多一分留心和私心，放眼到更長遠的利益上，憑借這個支點也能撬起更多的機會，何樂而不為？
#專欄作家#
健壯的大姐姐，微信公眾號：健壯的大姐姐（ID: is_strong），人人都是產品經理專欄作家。騰訊高級產品經理，專注于To B服務項目管理和行業分析，歡迎各路好漢一起探討。
本文原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自?Unsplash，基于 CC0 協議
居然是個大姐姐。
這篇文章很有價值，作者經的經歷感同身受，去年也在往項目復制化、規范化、標準化的路子走。把項目工作的日常記錄下來這個方法可以去試一試。項目結束后再復盤，只能記得一些“痛”和“甜”
在考慮復制之前，首先要學會復盤項目。
這就好比拉片子，一個學習小組分工合作，逐格、逐句地解讀電影和電視劇，通過細致地觀摩，全面掌握片中的內容、風格與技巧，系統地分析一部影片。雖說這是影視編劇學習的常用方法，但放在復盤項目的情景下也同樣適用。
真的是非常認同的呢，對于拉片就好比去學習，去復制，同樣的也是反思和復盤自己的工作和任務。
作為剛入行的，覺得這兩句話真的非常好。
“基于目的出發再去分析客戶場景，才算得上真正地從需求場景出發?！?br /> “請注意，即便客戶沒有明確場景，我們也要創造場景。創造場景就是給客戶定義一條路，給客戶遞上一個臺階，讓他自然地踏上去?！蔽覀€人認為成熟的B端產品經理就是要有這樣的認知和能力，讓我有了目標。
謝謝認可哈