快速解答： 驗證機會只完成一半的工作。你還需要把這些洞察,清楚地傳達給專案團隊、領導層,以及所有會受影響的相關團隊——這一步決定了你的專案是順利推進,還是在後期突然翻車。Claude AI 能幫你整理逐字稿、草擬簡報架構、彙整回饋意見,但真正建立信任、拿到核准的那場對話,還是得靠你自己走進會議室完成。
你是不是也曾經花了三週做用戶訪談、跑漏斗分析、算出漂亮的商業價值估計,結果拿去跟主管報告時,對方一句「這不是我原本想的方向」,就把你打回原點?
先停一下。
這不是你的分析出了問題。是你跳過了一個多數新手 PM——甚至是自己用 Claude 打造產品的獨立開發者——最容易忽略的環節:溝通。
前三篇,我們走過了功能機會驗證的三大支柱,也細講了怎麼用 Claude 精煉用戶價值和商業價值。這一篇,我們要處理最後、也最容易被低估的一塊:怎麼把你的驗證成果,說給對的人聽,並且讓他們點頭。
驗證是給自己看的證據。溝通,才是讓證據發揮作用的方式。
如果你帶著驗證好的洞察,直接跳進下一階段——功能設計——卻沒有先跟你的核心團隊、領導層,以及受影響的相關團隊對齊,錯誤的假設會在無聲無息中,一路累積成後期的災難。
這種代價,通常會用三種形式反撲你:
舉個例子。假設你在做一個看似很小的優化——從結帳流程裡拿掉一個步驟。工程主管可能覺得這不重要,把它排在一個大型多階段產品發布之後。但如果你事先讓他知道,有相當比例的潛在用戶,把「付款過程太麻煩」列為不付費的主要原因,而這正在拖累營收表現——他就會用完全不同的態度看待這個專案。
這正是溝通的價值:它不是驗證之後的附加動作,它本身就是驗證流程裡不可或缺的一部分。
回顧一下,一個值得追求的機會,必須同時具備三個要素:策略契合、用戶價值、商業價值。
在前面幾篇,我們已經示範過 Claude AI 怎麼幫你分群訪談對象、整理逐字稿、彙整漏斗數據、比較代理指標。這些都是輸入端的工作——幫你更快拿到證據。 但接下來要做的事,是輸出端的工作:把這些證據,轉化成能說服別人的敘事。
這正是多數教學文章停下來的地方,也正是新手最容易摔跤的地方。
新手最常犯的錯,是把所有人都拉進同一場會議,結果沒有一個人真正被說服。
正確的做法是分清楚兩種溝通對象、兩種會議形式。
專案更新,是跟你的核心團隊(設計師、工程師)在關鍵轉換點對齊。例如機會驗證結束後,你需要跟設計團隊分享策略契合、用戶價值、商業價值的結論,確保他們帶著正確的問題意識開始畫圖。
產品審查,則是跟領導層對齊,確認你驗證的機會是正確的,並且拿到往下走的核准。這裡的領導層,通常分成兩群:
怎麼判斷一個團隊算不算「被直接或間接影響」?問自己一個問題:如果我的專案往前推進,誰的工作會因此改變?
舉例來說,如果你在改善銷售轉換率,銷售團隊就是你的直接內部客戶,你需要邀請銷售主管。如果你在準備推出一個新功能,行銷和客服團隊都需要提前準備,你也應該邀請他們的負責人。
一個實用的判斷原則是:你應該是這場會議裡最資淺的人。 把會議控制在最小規模,只邀請真正受影響的關鍵領導者。
走進產品審查會議前,先問自己:我要從這場會議帶走什麼?答案通常是三件事。
第一,蒐集對機會的回饋。 在你開始設計和開發之前,讓領導層檢視你的分析,確認理解一致。這一步能大幅降低後期才發現方向錯了的風險。
第二,找出限制與依賴關係。 領導層通常掌握你看不到的組織全貌——時間限制(例如某個功能必須趕在特定季節前上線)、資源限制(例如公司只有兩位 AI 專家,而且沒有計劃再招募)。
第三,拿到明確的核准。 這場會議結束時,你需要清楚知道:領導層是不是同意繼續推進?如果同意,他們也同時核准了高層級的時間軸和行動計畫。
這場會議可以有三種結果:直接綠燈、有條件的暫時綠燈,或是踩剎車。 不管結果是哪一種,重點是你明確地問了這個問題,拿到了明確的答案——這樣未來出現爭議時,你能回頭指向這場會議,作為雙方的共識憑證。
沒有結構的會議,很容易被帶偏到無關的討論,或是陷入沒完沒了的假設性辯論。
好的產品審查,通常分成四段:
開場時,值得先建立幾個參與規則:請與會者尊重簡報順序、避免跳到後面的段落;告知每個段落結束後都有提問時間;請領導層把回饋聚焦在自己的專業領域;請他們清楚標明每個回饋是「阻礙」「意見」還是「建議」。
深挖機會的段落裡,用戶價值通常應該花最多時間講解。 領導層離用戶的日常現實最遠,你的工作,是成為連接兩端的橋樑。這時候,具體的用戶語錄比任何數據都更有說服力——一句「我最怕的是員工的個資外洩」,勝過十張投影片的抽象論述。
商業價值的段落,則要回答三個問題:質化和量化的商業目標是什麼?你用了哪些代理指標和假設來估算改善幅度?誰是這個專案的關鍵利害關係人?
這整個簡報架構的草稿,正是 Claude AI 能派上用場的地方。 把你的訪談洞察和漏斗數據丟給 Claude,請它幫你草擬每個段落的敘事邏輯、篩選出最有代表性的用戶語錄、把冗長的分析壓縮成可以在會議上快速講清楚的版本。但要提醒自己:簡報稿是 Claude 給你的初稿,不是最終答案。 真正能打動領導層的細節,往往來自你親自坐在訪談現場時,聽懂的那些沒說出口的猶豫。
知道流程還不夠,實際執行時,新手常常在這幾個地方摔跤。
講太多。 分享你做過的所有工作,聽起來很負責,實際上只會稀釋重點。好的產品審查應該經過至少兩輪刪減——先把內容做出來,再把它砍短四分之一。
沒有事先跟主管對齊。 如果你的驗證結果推翻了某位高層一直深信的假設,提前跟你的主管溝通,能幫你調整表達的語氣,也能讓主管在會議中成為你的盟友。
忽略依賴團隊的專業邊界。 讓依賴團隊的領導者,只針對自己的專業領域給意見——這能避免討論被拉往錯誤的方向。
驗證完就直接埋頭做設計,跳過溝通這一步。 這是本文開頭就提過的核心錯誤,也是最容易造成後期大爆炸的根源。
這些陷阱背後,其實只有一個共同原因:把「我以為大家都知道」,當成了「大家真的都知道」。
溝通這件事,同樣需要驗證,不能只靠感覺。
會議結束時,直接問三個問題:你同意這個機會的哪些部分?你對哪些部分還有疑慮?我們應不應該繼續推進,為什麼?
這三個問題的答案,就是你判斷溝通是否有效的直接證據。如果領導層給出模糊的回應,例如「聽起來不錯」卻沒有具體表態,這通常代表對齊還沒真正發生——你需要追問,直到拿到清楚的答案。
拿到核准之後,別忘了記錄下來。把策略契合、用戶價值、商業價值的結論,寫進產品需求文件(PRD)裡,作為整個專案期間的共同參考點。這份文件應該是活的——隨著設計和開發階段的推進,持續更新它,讓它繼續發揮對齊團隊的作用。
走完這四篇文章的完整流程,你應該已經看出一個清楚的規律:Claude AI 在每個階段都能幫上忙——分群訪談對象、整理逐字稿、彙整漏斗數據、草擬簡報架構。但每一次真正關鍵的判斷——這個問題夠不夠嚴重、這個估算夠不夠保守、這場會議該不該繼續往下走——都得靠你自己拍板。
驗證,決定了你知不知道正確答案。溝通,決定了別人相不相信你。兩者少了一個,你的機會就只是一份寫得很漂亮、卻沒人買單的文件。
下次你做完一輪驗證,別急著打開設計工具。先問自己:我的團隊、我的主管、我的依賴團隊,是不是都已經跟我站在同一個理解上?
產品審查會議通常要花多久準備?
視專案複雜度而定,小型功能可能只需要幾天整理簡報素材,大型或跨團隊的專案可能需要一到兩週,包含跟主管的事先對齊與簡報內容的反覆刪減。
如果我是自己用 Claude 打造產品,沒有團隊或領導層,還需要做產品審查嗎?
需要,只是形式不同。你可以定期把驗證結果整理成書面總結,強迫自己重新檢視策略契合、用戶價值、商業價值是否依然成立——這相當於自己扮演審查者的角色。
跳過溝通直接進入設計階段,最大的風險是什麼?
最大的風險是後期才發現團隊理解不一致,導致大量重工,或是專案在快完成時被領導層喊停。這些代價,通常遠比花時間事先溝通還要高。
Claude AI 能完全取代跟利害關係人的對話嗎?
不能。Claude 能幫你整理素材、草擬簡報邏輯、彙整回饋紀錄,但建立信任、判斷語氣、臨場回答尖銳問題,這些都需要你親自在場完成。
這套溝通框架適合什麼樣的人學習?
任何正在推進產品決策的人都適用——不管你是團隊裡的產品經理,還是正用 Claude 一個人打造軟體產品的初學者。只要你的機會驗證涉及其他人的工作或資源,這都是你不能跳過的一步。
iThome鐵人賽
看影片追技術