一群PM管理專案的能力都相同專業、EQ也都很棒，此時誰能更快獲得客戶傾心呢？
答案是最懂客戶需求「業務生態」的那一位。
隔行如隔山，懂系統懂專案管理不代表懂業務需求。

熟悉業務溝通少代溝

平時只處理過申辦業務的PM，對系統流程也許只限「前台填寫資料、後台審核、最終審核通過讓前台知道」的部分。
突然要討論「建立課程、報名上課」的業務時，可能也會侷限在一般的申辦流程。
懂「建立課程、報名上課」的PM會萌生其他警覺：學生報名了、課程資料還要改的時候怎麼辦？需要系統輔助做簽到表嗎？
這一點點差距，有時會幫客戶和開發團隊避開不少地雷。
這也是為什麼客戶喜愛懂自己domain konw-how的PM，客戶講兩句話，PM無縫接軌通靈補充很多細節，客戶花錢想買的就是這種有價值的專業服務呀。

有機會借鑑其他系統經驗

懂domain konw-how的PM想必已具備一定程度的經驗，客戶若是首次要系統化某個業務流程，此時PM會像是救命稻草一樣的存在。
客戶如果從PM口中得知已經有系統實驗過類似經驗並取得成功，在討論規劃時會比較安心並對未來有信心。
失敗的經驗也是很棒的參考，其他人踩過的雷可以借鑑避開省去再痛苦一次。

PM跨入新domain的方法

一、順一次需求的業務流程

若客戶的需求是「改版系統」，最快熟悉業務的方法即是親自用一遍舊系統。
沒有系統的狀況下，可以模擬自己是發動業務的人，例如想像自己是民眾要申請補貼業務，以民眾的角度需要填寫什麼表單、接著換成審核者要簽核內容等等。
PM不是專業的分析師，但至少做到這個程度能了解較全面的業務流程，在與各方討論時能快速進入狀況。

二、需求訪談

上一項是沒有客戶輔助下PM能先行準備的功課，主要兩隻腳都跨入新領域應該都是從「需求訪談」開始。
訪談會議前，PM與分析師自我準備時發現的疑問，今早先拋給客戶，預告需求訪談時需要了解哪些問題，能聚焦並加速會議進行。
若PM沒有控管需求訪談進行的方向、節奏，分析師不專業的情況下，客戶會自說自話各種發揮，也許講了一下午都沒講到核心需求，這樣PM很難掌握到domain的核心精神，之後系統設計歪掉的可能性也很高。

建議務必請客戶在訪談時闡述：

1.需求目的性

統計分析的運用可能需注意資料定義，動態數據的展示可能最重視資料即時性⋯⋯瞄準目標才能設計規劃出客戶真正需要的功能。
又是那個經典的舉例：
客戶跟你說他需要一匹馬，PM直接給一匹馬是不明智的，PM應該先了解客戶為什麼需要一匹馬，如果客戶說是為了從台北移動到台中，預算充足的情況下PM提供一張高鐵票才是有效率的方案，也能由此體現出PM的專業性。

2.使用者角色

預計使用系統的人，是一般民眾？有考證照的專業人士？或是資訊部門的同仁？
上述3種角色對於網頁操作的熟悉度和反應截然不同，防呆、防客訴的程度也完全不一樣。
一般民眾可能連怎麼報修都說不清楚，光首頁的UI/UX設計就需要耗費做一番沙盤演練。
使用者也是「利害關係人」的一種，一定要問清楚才能正確分析需求。

3.業務禁忌

各行各業都有絕對絕對不可觸犯的禁忌，剛跨入新領域切記別怕麻煩問清楚禁忌事項。
舉幾個例子：
1.政府機關的網頁，以為什麼色系都可以設計使用就錯了，不小心用了客戶很介意的政治顏色，政黨改朝換代時有得改了。
2.服務對象為高齡者的網站，顏色要吉利不能聯想到死亡、文字大小和配色必須清晰易讀。
3.代碼的英文字母排列可能得避開GG、WC組合，客戶覺得聽起來不舒服。
小眉角只有客戶知道，PM不要吝嗇多開金口問幾句能避免很多麻煩。