“好産品不是能力内核，做好産品的流程才是”。這是劉潤曾提到過的觀點，本文作者也非常認同，而本篇文章就分了8個部分來講述做“好産品”需要怎樣的流程，一起來看看吧。

劉潤在一篇文章中提到過一個觀點，“好産品不是能力内核，做好産品的流程才是”。我很認同這個觀點，本文主要分享我對做“好産品”的流程當前的一些認知。

全文共8個部分，總字數超過1萬，限于篇幅可能有些内容談的還不夠深入，後續有時間會再做細化。這8個部分是：

1. 建立需求池和需求反饋渠道
2. 建立走進客戶現場機制
3. 建立需求接納機制
4. 建立優先級決策原則
5. 建立産品設計标準
6. 建立産研協作保障
7. 建立産品驗證機制
8. 建立産品場景案例庫

一、建立需求池和需求反饋渠道

需求池管理是B端産品進化最重要的環節，它的重要性遠超産品設計、開發等其他環節。

維護需求池有主動和被動兩種。

主動維護是産品經理在參與售前、疊代、交付、售後、競品分析、老闆溝通等活動時自己發掘、記錄需求，主動收集需求的渠道很多，但不同渠道收集到的需求質量有差異。

通常而言，我認為重要度最高的是售後環節，因為此時反饋的需求通常是讓客戶真正痛的地方；

其次是競品分析，友商決策并實現的能力通常意味着有真實的客戶和需求存在；

再次是售前和交付，這些環節有時候客戶期望過高，容易空想不一定真實存在的需求，要慎重接納；

最後是疊代時開發團隊想出來的需求或老闆提出的概念性需求，這些需求的真實存在性相對更低。

當然，很多時候，從職業本身的角度，老闆需求是重要度“最高”的需求。但一個對産品負責的産品經理，應該通過發問挖掘需求，幫老闆“想清楚”，或讓老闆把自己“說明白”，最終找到真實需求或引導降低優先級。判斷需求收集渠道重要度的原則是需求真實性概率，而需求真實性是指需求存在且有普遍性。

被動維護是建立起需求反饋渠道讓相關角色(售前、交付、客戶經理、客戶響應中心等)可以“有效的提需求”。它包括兩方面：

1. 要有集中化的業務需求電子流，讓相關角色明确的知道有需求在哪提、提給誰、怎樣提等；
2. 要通過需求結構化的方式提高業務需求反饋質量，減少産品經理和需求提出人之間低效溝通次數。

業務需求結構化，除了産品、客戶、金額、姓名、時間等基本屬性之外，更重要的是對需求場景的挖掘。關于需求挖掘，我給售前、交付等職能提供過一個5W3H分析法，具體包括：

• who，誰提的這個需求？最終影響的用戶角色是誰？
• why，客戶該需求的業務背景是什麼？由于什麼原因産生了這個需求？
• when，發生了什麼事，造成了什麼問題，所以有了這個需求？這個需求未實現時，客戶是怎麼解決這個需求的？過程中有什麼痛點（不方便的地方）？
• what，初始需求提出人的原始需求描述是什麼？主業務過程什麼樣？業務過程有哪些異常場景？
• where，如何有了這個功能，客戶會在什麼場景（什麼時候、什麼條件）下使用這個功能？功能使用頻率有多高？
• how，客戶期望産品在哪裡做什麼功能？功能長什麼樣？為什麼期望功能或交互做成這樣？友商是如何實現這個需求的？
• how much，這個需求對客戶的業務價值是什麼？實現後用戶可以得到什麼好處？
• how much，這個需求對在該行業或其他行業客戶是否需要？是不是個性化需求？

産品經理應該把需求池維護作為自己最重要的工作，需求池決定了産品未來的方向。接到需求第一時間需要将原始需求記錄至需求池，定期對需求池中需求進行狀态更新。

二、建立走進客戶現場機制

在辦公室埋頭做設計交互的B端産品經理是不合格的，脫離客戶現場做不好B端産品。設計交互對B端産品并不是最重要的，更重要的是業務目的、業務過程、使用場景、角色群體和替代解決方案等。

通過非直接用戶、客戶反饋的需求，通常會有信息過濾。産品經理要走到客戶現場，感受用戶的情緒，傾聽用戶的怒罵或贊賞，對自己的産品有客觀的認知。傾聽用戶對功能的使用場景，把這些場景包裝成故事講給其他客戶，給客戶“懂我”的信任感。還可以驗證需求池中的需求，傾聽用戶對規劃中需求的期待和反饋，為後續優先級規劃和産品設計做準備。做好B端産品不是跟随友商，而是跟随客戶。

但産品經理的時間、精力是有限的，若出差客戶現場包含往返在途至少半周，每月也隻能安排1～2個客戶拜訪。所以，拜訪客戶的選擇尤為重要。

選擇拜訪的客戶，應該是“天使客戶”。這些客戶的大概畫像是：屬于産品主打行業，處于行業頭部地位；已購買且交付産品，在深度使用，願意每年支付服務費用滾動續簽；客戶接口人懂業務，對産品有想法，有邏輯、講道理。當然，很多時候客戶不是我們能選擇的，隻能盡可能選擇和産品目标客戶相似度高的客戶。

售前階段的客戶并不是适合産品經理拜訪的客戶，一方面此階段的需求不一定是真實場景下産生的，存在過高期望或主觀臆想；另一方面如果客戶提了一堆需求，産品到底響應還是不響應，什麼時候響應都是難題。但售前階段的招标文件，産品經理可以作為重要需求收集渠道，有可能會發現影響産品新定位的需求。

“以客戶為中心，關注場景和痛點”，不應該隻是口号，或依賴每個産品經理自己的主動性，應該建立起機制和制度進行保障，讓産品經理不要脫離客戶現場做産品。

三、建立需求接納機制

從多種渠道收集到的需求，并非所有都應該納入到産品規劃中的，畢竟開發人力總是稀缺的。明确需求接納決策人，建立決策依據原則對B端産品至關重要。

承擔需求接納決策人角色的人，至少應該滿足兩個要求：

1. 他應該懂業務、懂客戶，不脫離一線客戶現場；
2. 他應該對業績負責、對客戶滿意度負責，該産品業績對他的KPI有較大影響。

需求決策人通常是産品經理，也可能是業務負責人。如果需求決策的權力，由脫離客戶一線，不對市場業績負責，缺乏産品管理經驗的人負責，對産品會是一場災難。

需求接納原則，至少應該考慮3個問題，值不值做、該不該做、要不要做。

1. 值不值做。需求實現能幫客戶解決多大的問題，能産生多大的價值收益，如果量化成貨币是多少錢？作為一個商業化産品，每做一個功能都要思考，這個功能客戶是否願意花錢買單？願意花多少錢？市場上有多少客戶願意為這個需求買單？
2. 該不該做。需求是否在産品定位的邊界範圍内，是否該由這個産品來做，還是應該由其他産品做？如果跟産品組合中其他産品存在部分的功能重疊，那這個功能做還是不做？（對這個問題，我的理解是以客戶場景為中心，而非以産品為中心。如果客戶的場景需要這個功能，即使其他産品中存在，也應該在這個産品中進行實現。至于研發成本、重複開發的原則是次要的。研發的問題從研發的角度考慮解決，而不是讓客戶的需求來妥協。）
3. 要不要做。功能實現在技術上是否可行？短期與長期投入産出比如何？标準化程度能做到多高？對比客戶當前方案能有多大收益？現在是否是做這個功能合适的時機？目前的解決方案是否足夠優秀？

需求是否接納通常由産品經理一個人決策，但這會過度依賴産品經理自身能力。建議應該成立需求評審委員會，周期性對産品組合中各個産品經理的決策依據進行評審。

需求評審委員會的成員應該包括産品總監、售前解決方案總監、售後客服總監、研發總監等角色，至少産品總監和售前解決方案總監需要參與。需求是否接納影響産品組合中各個産品未來進化方向，值得管理者參與決策過程。該會議無需對具體功能方案做溝通，隻需要決策需求是否接納即可。

在需求接納管理的過程中，可能總存在一些人發出反對的聲音。每次産品經理決策需求或設計方案時他總能找到反對的理由，但如果你讓他來提該做什麼、怎麼做，他又提不出有價值的想法，反問一句“這是産品經理的事，你是産品經理還是我是産品經理”。

我們要知道，每一個決策都有利弊，我們隻要追求當下能做出的最佳決策即可。如果因為懼怕決策風險，就停滞下來不做決策，做無意義的時間消耗，這才是最大的損失。對于有價值的聲音需要接納，對于沒價值的反對，隻能練就一顆強大的内心。微笑面對反對和質疑，堅持自己的選擇，并能在失敗後平靜面對他們的嘲笑。

但行前路，無愧于心，足矣。

四、建立優先級決策原則

研發人力和時間總是稀缺的，需求優先級排序直接影響着市場業績和客戶滿意度，做好優先級排序對産品非常重要。如果需求收集和接納決策是對産品經理能力第一重要的考驗，那需求優先級決策則是對産品經理能力第二重要的考驗。

需求優先級排序的方法論很多，但回歸本質是ROI和對比排序。對比排序，即使沒有方法論也能做，但有方法論可以讓排序有據可依，标準相對清楚，更容易同其他人達成一緻。

不同商業模式、不同産品、不同階段衡量ROI的标準不同，要根據自身産品選擇适合的一套或多套組合衡量方法，不要迷信特定理論。

比如，對于内部系統或大客戶定制項目，收益主要是關鍵角色的滿意度，其次是次要角色使用價值，更多使用提出人權力/影響矩陣做優先級排序；對于處于0-1打造階段的産品，收益主要是MVP版本交付與反饋，更多使用KANO或MoSCoW做優先級排序；對于處于1-n階段的商業B端産品，收益主要是短/長期市場收入，更多使用效益/緊急矩陣做優先級排序。

對于1-n的商業B端産品，我推薦效益/緊急矩陣優先級排序法。既然是商業産品，那就向錢看。效益高且緊急的需求優先級最高，效益高不緊急的需求其次，效益低緊急的需求再次，最後考慮效益低不緊急的需求。看似簡單，但如何定義效益呢？

效益是短期、長期經濟收益的綜合評估，短期經濟收益好評估，承諾或完成某個功能就能讓正在售前的客戶願意付錢購買。但長期經濟收益呢？在沒看到項目機會前，是否能絕對預測做了某個功能一定能夠帶來多少客戶、多少收入增長？這個很難，因為決定收入的因素很多。但可以确定的是功能解決的場景價值越大，則産品綜合價值越高，特定客戶購買概率也更高。

那如何評估場景價值大小呢？一種參考方法是大概估測，沒有這個功能時，客戶想達到業務目的需要投入多少人、多長時間，這些人需要的薪資是多少，這個事每年做幾次，最後大概能評估一個年度貨币成本數量級即可。

這個評估不需要精确的數值，這種數值也沒有意義，可以拍腦袋估測，隻需要能跟需求池中其他需求有個大緻對比即可。做這個估測的意義不在于準确，核心是需要産品經理建立起關注需求背後業務價值的意識，而不是關注在功能設計本身。

通常來講，處于售前關鍵時刻（客戶已完成預算申請且内部立項，正處于确定招标參數階段）的大金額項目是經濟效益最高的，畢竟“百鳥在林，不如一鳥在手”；其次是涉及客戶多、業務價值高的普适需求。

對于經濟效益在相似量級的需求，可以引入成本作為第二優先級排序考慮因素。成本越低，相對優先級越高。

需求優先級并不意味着絕對的開發疊代順序，在開發疊代排期時我們還需要兼顧每個開發周期内大小需求的均衡性、市場響應及時性等。可能有些小需求經濟效益不高，但成本極低，此時考慮到市場響應和客戶滿意度，也可以将這些小需求排入靠前的開發疊代。

對于經濟效益高但難度大、成本高的需求，不能因為難就一直拖延着不做，我們需要勇于啃硬骨頭，在具體推進時可以把這類需求穿插在多個疊代中硬啃，做難而正确的事，我們才能拉開與競争對手的差距。

五、建立産品設計标準

一個優秀的B端産品除了功能，更應該靠場景打動客戶。B端産品設計不能狹義的理解為單純的功能交互設計，而應該圍繞客戶業務問題、場景來綜合考慮，我們的終極目的不隻是做一個漂亮的界面、好用的交互，更是幫助客戶解決當前存在的問題。

根據經驗，我将産品設計劃分為：業務背景澄清、業務過程梳理，流程與角色設計、角色任務設計、功能設計，架構設計、交互設計，平面設計，視覺設計等一系列過程，這個劃分方法借鑒了《用戶體驗五要素》中戰略層、範圍層、結構層、框架層、表現層的思路。

這些設計過程隻是一種知識體系化的拆解維度，劃分并不精确，各個過程未完全遵循MECE原則，沒有嚴格的先後順序。在實際設計過程中，我們可以有意識的注意這些過程，針對具體場景來裁剪使用。以下将對每個過程簡略描述：

1. 業務背景澄清

将需求收集時5W3H問題和答案再确認一遍，回顧一下我們核心要解決的問題是什麼，業務目的是什麼，價值是什麼。

2. 業務過程梳理

将客戶線下解決問題的方案搞清楚，都涉及哪些角色，每個角色做什麼，角色間如何協作，業務涉及多少個環節，每個環節具體做什麼。我們要介入這個過程應該從哪些地方介入合适，哪些地方不适合軟件介入，軟件介入比原有方案增加了多少價值。

3. 流程與角色設計

流程與角色設計是基于原有業務過程，考慮轉化到軟件上該如何做，每個角色需要設計哪些任務。在設計時我們可能需要打破、調整原有業務過程，以線上更合适的方式來做。

4. 角色任務設計

是基于單個角色設計他的主任務、次任務，該角色在業務中的目的是什麼，主任務需要幾個步驟，是否可簡化步驟，每個步驟具體做什麼。

完成主任務涉及多少個核心頁面、多少個關鍵功能，如何保障主任務過程順暢。分支任務有哪些，如何即能讓分支任務為主任務提供便利，又能避免分支任務幹擾主任務，分支任務應該有哪些入口，如何即易找又不喧賓奪主。任務過程中可能有哪些異常，哪些應該軟件來避免，哪些應該交給用戶自己判斷避免。

角色任務設計完成，需要什麼頁面、什麼功能基本已經确定了。

5. 功能設計

是确定每個功能實現邏輯、方法，功能設計要基于業務問題和場景，如何設計能帶來最大的收益，再衡量如何降低成本獲取最大ROI，這個過程中可能功能設計需要做一些妥協，但仍需保障功能的價值度，這個平衡并不容易做到。

另外一個很難平衡的問題是，“追求更完美的方案再開發，還是先有一個簡單方案再持續疊代”。首先，我傾向于持續疊代。在實際使用中不斷反饋和疊代，要比一直憋方案，遲遲功能推不出來更好。

而且，我們很難預知能設計出一個完美方案，也很難預知我們認為的完美會被客戶認可。對于創新型功能設計，有改進、有價值即可，不過度設計、夠用即可。

但同時，又需要平衡最低設計标準，不要讓産品掉檔次，讓客戶感覺草率、粗糙。起碼應該達到讓産品經理自己願意承認，這個設計是出自我手的程度。否則，産品經理就應該有所堅持，不能因老闆或大項目壓力而妥協，要盡可能在有限時間内追求更好的方案，對自己的産品負責。我們不是為了做功能而做功能，最起碼應該保障功能在場景中能解決問題，否則絕不将就。

功能設計推薦4個原則，按重要性排序是，有用、好用、靈活、簡單：

1. 有用是指功能設計要能解決業務問題，在設計過程中由于要平衡考慮靈活性、易用性、成本等，方案可能會不斷調整，所以在設計的過程中要不斷回顧是否偏離“有用”原則。
2. 好用是指功能的用戶體驗，涉及架構、交互、UI等，下文會繼續展開，此處需要注意的是，有些客戶會對功能設計提出自己的方案，産品經理要認真聽，但不可照做，對客戶建議的功能設計要綜合考慮，而不是做一個傳話筒。
3. 靈活是指功能設計時要考慮在不同行業、不同規模客戶處，有哪些差異性，如何通過設計兼容這些差異性；以及未來需求若出現變化，如何通過設計進行兼容。靈活性可能會造成用戶體驗下降，開發成本提升，所以需要進行平衡，沒必要追求過度靈活性。
4. 簡單包括多方面，設計方案要盡可能簡單，可以清楚的傳達給開發團隊；開發方案要盡可能簡單，避免複雜度帶來的Bug、維護成本、升級不便性等；用戶理解認知要盡可能簡單，避免造成用戶不會用、不願用。

功能設計完成後，産品經理的核心工作基本完成。UI/UE設計是專業領域，專業的事情應該交給專業的人做，産品經理更多是配合UX設計師。但公司如果沒有專職的UX設計師，則需要産品經理主導設計。

不建議産品經理拍腦袋創新，最好直接向那些有UX設計師的友商“借鑒”（抄襲）。如果友商做的也不好，可以向一些優秀作品學習，如騰訊系的産品，但抄的過程中也需要有自己的選擇和判斷标準，不行無腦全抄。B端産品最重要的是功能設計之前戰略層、範圍層的事，産品經理若花過多時間在框架層、表現層則有些本末倒置。

6. 架構設計

是确定不同功能具體在哪個頁面，以及用戶完成任務需要按順序使用哪些頁面，各頁面之間如何跳轉。常見手段如：面包屑導航、高級搜索、首頁快捷入口、列表或詳情頁超鍊接、彈窗、抽屜、返回等。

跳轉設計時要結合任務場景來設計，比如，在運維管理的資源設備添加時，如果添加成功應該自動跳轉至列表頁，因為用戶的主任務已經完成，下一個主任務是再新增一個資源或者使用其他功能菜單，所以要自動跳轉至列表頁；

而如果資源添加失敗，則應該停留在本頁面，因為大概率是由于賬号密碼錯誤造成連接測試失敗，這個場景下用戶會走入賬号密碼修改的分支任務，而該分支任務就是在詳情頁完成，所以不能讓用戶跳轉至列表頁，而是留在當前頁面增加用戶修改的便利性。

7. 交互設計

廣義上講包括了架構、交互、平面、視覺等，狹隘上講是一組觸發點、觸發動作和動作反饋，包括控件選擇、控件交互及用戶操作聯動等。控件不建議自己開發，直接采用開源控件庫，如element、iview、antd等，這些控件大多數情況下夠用了，但也有些需求場景下這些控件無法滿足，有人力可以二次開發或新設計。

即使采用标準開源控件，仍需産品經理參與設計。産品經理需要根據需求場景選擇最适合的控件、确定控件默認值、确定控件之間的聯動邏輯、設計用戶視覺及鼠标鍵盤操作動作、路徑等。

交互設計推薦3個原則，少想、少看、少動：

1. 少想是降低用戶認知負荷，如貼合用戶習慣（設計跟用戶線下認知保持一緻、跟行業通用設計保持一緻、産品組合中設計保持一緻）、UI設計、簡化設計、漸進式任務設計、文案設計等。
2. 少看是減少用戶視覺負荷，如縮短眼動路徑，将用戶一次任務需要的内容放在相近的位置；簡化頁面内容，使用對比、組合、隐藏等UI設計、簡化設計技巧。
3. 少動是減少用戶操作動作，如鼠标移動總距離、鼠标點擊總次數、鼠标鍵盤任務切換總次數等。

簡化設計推薦4個原則，删除、組織、隐藏、轉移：

1. 删除是将極少使用的功能删掉，僅保留不可删除的功能；
2. 組織是按功能邏輯進行分組、分塊、分層；
3. 隐藏是将不常用又不能删除的功能隐藏的路徑深一些，用戶使用時能找到即可；
4. 轉移是将功能轉移到其他載體上（用戶自己、其他産品模塊）。

平面設計推薦4個原則，親密、對齊、對比、重複：

1. 親密是将邏輯上相關的内容組織在一起，讓物理位置靠近，相反，将邏輯上相關性低的内容增加物理距離；
2. 對齊是讓物理布局整齊，明确對齊線，讓頁面内容顯得有條理，增加可讀性；
3. 對比是通過明顯的視覺反差效果，将不同的内容區分開；
4. 重複是在整個産品設計中相同目的保持相同設計，如圖标、顔色、樣式等，增加産品統一性，另外，也盡可能跟用戶日常認知保持一緻性重複。

視覺設計需要審美，我的直男審美相對差一些，所以更多追求簡單、簡潔，在配色、比例、鈍銳角、線條、對稱、平衡等因素上較多依賴于借鑒（抄襲）優秀友商作品。

最後，在産品設計上我想強調的是，設計隻是解決問題的手段而已，最核心的還是理解并解決業務問題。

六、建立産研協作保障

通常情況下，産品經理和研發歸屬同一個大部門，辦公距離相近，疊代過程中有問題可以及時溝通解決，産品經理隻需要保持正常的節奏參與疊代規劃會、疊代驗收會等即可。産研利益一緻，協作高效，溝通基本不會出現問題。

但在有些大公司，産品經理和研發可能跨了大事業部，位置也可能分布在不同城市，産品經理的核心工作是市場商業，極難保證跟研發溝通的時間。這種情況下，會出現很多問題，想把産品做好很難。

比如，因組織架構原因，産研利益不一緻，産品經理推動力不足；産品經理跟研發溝通時間較少，關系融洽度較難維持，相互信任度低，容易産生嫌隙；疊代中研發有問題很難随時跟産品經理确認，問題被拖延影響開發效率等。

我的應對思路是：

• 懼怕沖突，堅守産品規劃不退縮；
• 工作公開透明，把事情擺到桌面上；
• 借助多個相關方力量，共同影響研發接納需求；
• 多方位影響高層管理者注意到問題，為産品經理争取時間；
• 至少保證疊代計劃會、演示會和研發團隊有交流；
• 盡量保障定期線上會議幫研發解答疑問。

産研溝通存在障礙不可怕，可怕的是接納這種狀态不做改變。做好産品我們要保障産品經理和研發利益一緻、溝通順暢，讓産品經理對産品規劃有主導權，有充足的時間完成需求分析、及時解答研發疑問。

七、建立産品驗證機制

産品設計不能閉門造車，為避免功能不被客戶認可，要頻繁驗證。尤其B端産品，上線一個功能容易，但下線一個功能很難，需要在很長一段時間承受壓力（客戶質疑售前時有的功能，為何交付時沒有了，這種情況處理很棘手）。

客戶定制或内部自研産品需求方明确，相對容易驗證。但标準化商業産品的需求方來自多行業、不同規模客戶，相對驗證困難。

對于客戶定制或内部自研産品可以秉持”最低成本驗證“的原則驗證功能設計是否滿足客戶需求，必須完成的驗證包括：業務背景确認（會議）、核心業務流程确認（Visio）、核心功能确認（Xmind）。

若需求較大，驗證手段按成本從小至大包括：紙面線框圖、低保真原型、需求概要說明書、高保真原型、需求詳細設計說明書。需求驗證的交付物并沒有實際價值，所以應該根據客戶和場景盡量選擇成本最低的方式。

對于标準化商業産品我沒很好的方法，目前的思路包括：

• 借助PPT跟售前、客戶經理等團隊做概念宣講，驗證需求普遍性及價值度；
• 借助重大項目售前/售後交流機會做概念宣講，驗證需求期望度；
• 借助交付中典型行業客戶，對功能設計方案進行驗證；
• 借助公司内部交付專家，對功能交互/UI設計方案進行驗證；
• 由産品經理/測試人員把自己想象成小白用戶，模拟用戶完整業務過程使用體驗。

在我管理的産品組合中，有幾個需求推動很久了卻一直未被研發接納，但今年通過重大項目完成了一舉多得。這些項目金額達到數百萬級，售前申請了産線産品經理直接參與。

在跟大客戶溝通過程中，我提及了幾個功能設計理念（未承諾，以規劃中引導），很切中他們的實際痛點，在會議上客戶大加贊賞，直言“你們的産品是我看過的所有國内外産品中，做的最好的”。最終，我們既完成了需求驗證，又拿下了多個數百萬級項目，還成功讓研發接納了需求，提升了産品未來競争力，一舉多得。

當然，标準化商業産品的功能驗證并不容易，有很多要考慮的因素，比如：客戶過度期望風險、功能交付時間風險、技術方案風險、通用度不足風險等，但我們不能因為有風險就停下腳步，産品經理要有敢承擔風險的魄力。

八、建立産品場景案例庫

項目成交的關鍵是客戶對産品的認可和信任，産品功能是重要因素。但單純的功能介紹不易讓客戶感受到産品的價值以及我們和競争對手的差異性，所以，我們需要借助客戶實際工作的場景故事，讓客戶更容易感受到價值和我們在領域内的專業性。

通常來講，優秀的解決方案專家應該對産品特定功能使用場景和價值很清楚，産品案例庫也應該由售前解決方案團隊來維護。但若解決方案崗位由于各種原因出現缺位，如負責多個産品線精力不足、人員流動率高、工作經驗不足等，産品經理需要在這個關鍵之處做補位，反向培訓解決方案專家。

幫助客戶發現産品功能更多的使用場景，也是産品經理需要關注的事。因為增加功能的目的是增加産品價值，發掘原有功能更多使用場景也能幫助客戶增加産品價值。從場景中來，到場景中去。

坦白講在産品場景庫建設上我目前做的并不好，曾經推動體系化的做行業場景案例庫，隻輸出了一篇，後續由于相關角色配合度不高，自己做又缺少時間，就擱置了。

不過，在特定行業解決方案PPT輸出時，我有意識的采用了以場景為線索組織結構，跟客戶交流時效果很好，我認為這種模式對今年幾個數百萬級大項目中标有很大的正面效果。

我組織場景有兩個思路：

第一個思路是從用戶的實際工作角度出發，拆分多個場景，然後把産品組合中各個産品的功能打散進每個場景中，告訴客戶在不同的工作領域中，我能幫你解決什麼問題，我是如何解決的。比如：

在講整體網絡自動化解決方案中，我拆分了設備入網、服務請求實施、日常監控與管理、故障響應4類大場景，然後每個大場景再具體細化拆分成4個具體小場景，然後每個小場景采用幾頁PPT詳細介紹我的産品功能是如何在這些場景中發揮作用的。

在單獨的IP地址管理解決方案中，我按IP管理全生命周期拆分了IP規劃、IP收集、IP展示查詢、IP分配、IP審計、IP回收6大場景，然後針對每個場景分析客戶現狀最大的3個問題，提出針對性的3個解決思路，然後每個解決思路用幾頁PPT詳細介紹我的産品功能是如何一步步使用來解決這些問題的。

這樣按場景來組織的解決方案，會給客戶“懂我”的信任感。同時，也通過在場景中的功能演示，增強了客戶對産品實際落地的信心。

第二個思路是從産品功能角度出發，挖掘功能可以響應的特定場景。

比如，對于IP地址管理查詢列表頁，我會跟客戶講的場景是，“在交換機故障或報廢下線時，需要确定該交換機影響的具體業務或IP，此時，可以通過該設備IP可以直接查詢到所有接入IP，大幅減少了人工确認工作量”，“在對一個IP地址做故障分析或安全回溯時，通過IP地址可以快速查詢到這個IP是通過哪個交換機、哪個端口入網的，具體使用人是誰、用途是什麼、近期有哪些安全告警等信息，輔助快速定位故障、審計使用記錄”。

你看，僅僅一個列表頁，就可以講出很多使用場景。

另外，一些高價值場景比如，“投入上百萬建設CMDB，但仍不敢保證IP不遺漏，此時，可以通過IP地址管理的CMDB校驗能力，幫助發現CMDB中缺失的IP地址”；

“安全準入系統隻能管已經安裝了客戶端的終端，但真正的非安全終端沒有安裝客戶端難以發現，此時，可以通過IP地址管理對終端準入系統中IP進行校驗，輔助發現那些安全威脅”；

“網絡中IP沖突可能會造成關鍵業務斷網，此時，可以通過IP地址管理做IP分配集中歸口，減少IP沖突風險出現”；

“每年要做業務擴容時，哪些業務需要新采設備很多時候靠人拍腦袋，此時，可以通過IP地址管理自動查詢各業務設備接口使用率情況，通過數據很快就可以确定具體擴容業務和設備量”。

類似場景故事還有很多，正是這些貼合客戶業務的真實場景，會讓客戶更有體感，也更容易體會到産品的價值。

最後，我想說，一個優秀的産品經理非常重要。在業務上，他可以給客戶創造很大價值，給公司帶來長期收益；在産研協同上，他可以幫助研發少走很多彎路，大幅提升研發産出效率。

但是，好的産品經理可遇不可求，從公司角度需要有一套機制來保障産品經理不至于做的太差，才能保障公司正常發展。正如亞馬遜貝佐斯所說，“仰仗别人的善意來完成工作不是長遠之計，公司的運作需要依靠完善的機制”。

作者：李曉傑；産品曉說（ID：pmxiaosi）。10年以上産品、項目管理實戰經驗，近7年服務大B端客戶運營商（移動、聯通），核心産品為企業信息化與協同，包括研發管理、财務管理、辦公自動化OA、數據可視化等。喜歡讀書、分享，希望與同路人共同探索産品經理成長之路。

本文由 @産品曉說 原創發布于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部