開發團隊很辛苦地按照產品經理所提供的需求進行開發，開發團隊也覺得自己開發的功能創新度非常夠，而且產品經理也很努力的推廣自家的產品，為什麼最終的轉化率卻是不盡如人意呢？

每一位想要開發產品的人心目中都會想像著美好的光景，除了是能夠獲得金錢方面的收益之外，也會期待產品能獲得好評，真正的叫好又叫座。現實的狀況是，產品轉化率很低，甚至換算成本之後發現到自己的產品的廣告費遠大於收益，變相地說明自己的產品其實並不那麼受歡迎，是功能不夠好？還是不夠全面呢？或者是廣告的力度不夠大？

其實上述的原因都不是真正的原因，而是最一開始就沒有確定好產品的基底假設是否正確。什麼是基底假設呢？由於軟體開發的市場日新月異，開發團隊不可能在蒐集了大量的資訊和證據之後，才開始著手開發，而是會基於一個假設開展所有一切的考量並且規劃產品開發的工作。而這個最初的假設就是基底假設。

如何驗證這個基底假設呢？最簡單的方法就是進行顧客訪談，不過該怎麼進行訪談才會有效率並且有效果呢？
訪談框架：開放式提問 + 具體化概念 + 差異對比 + 總結核實

開放式提問

Q: 請問您喜歡喝茶還是咖啡呢？

上述的例子就是一種典型的封閉式問題。如何判斷一個問題是封閉式還是開放式呢？僅需要評估這個問題是否僅有提供有限的「選項」可以選，如果符合這個狀況，這就是封閉式的問題。

實務上來說，並非不能詢問顧客封閉式問題。如果想要快速篩選受訪顧客，採用封閉式是最快的。

開放式的問題除了讓受訪的顧客有更多的詮釋空間之外，訪談者也可以從受訪的顧客所陳述的內容中，衍生更多可以詢問的問題，讓原本許多模糊不清的部分得以被探索。

Q: 請問您都吃什麼？

上述看起來是一個開放式的問題，不過，這個開放式的問題幾乎沒有邊界可言，受訪的顧客可能會說出難以想像的答案，這反而讓這場訪談失去焦點，訪談者還得花費心力把受訪的顧客重新拉回到想要討論的主題上。

具體化概念

人類的思考並非是採用名詞，而是概念。既然是採用概念思考，那麼，依照受訪顧客的個人學經歷，同樣的概念在不同的人身上，就會講出不同的內容。

當然，任何生物都是有情緒的，因此，受訪的顧客很可能會在陳述的內容中，夾帶許多個人的觀點。能夠區分出「事實」和「觀點」的不同是很重要的訪談技能。如果大量採用或是紀錄受訪者的個人觀點，那麼這一場訪談可能會很有效率，但是很可惜的是，這是一場沒有效果的訪談，因為得到的資訊都是無用的資訊。

追問、排除、篩選，這些都是必要的訪談招式。將觀點背後的客觀事實追問出來，學會排除陳述中被扭曲的事實，或是被抽象化的概念。能夠訪問到並且篩選出真正的客觀事實是重要的。

差異對比

追問受訪者某件事物對其帶來的影響，以及為什麼會做出這樣的決定或者是做出這樣的行為。任何行為的誕生都是由其背後的動機所推動的，因此，如果訪談者僅停留在對於知道了發生了什麼事件，而不瞭解這個事件背後的脈絡和執行動作進而引發這個事件的背後動機，那麼，訪談者只是事件的紀錄者，而不是洞悉事物的底層邏輯。

如果在這個階段沒有確實的執行，會讓最後一個階段無法正確或是順暢地的進行，因為，對於受訪的顧客僅有表面上的認知，而不知道底層邏輯，這一場訪談可說是千里之堤潰於蟻穴，那就太可惜了，畢竟這場訪談幾乎可說是就快成功收尾了。

總結核實

溝通是說者和聽者的互動。如果說者提到的是概念 A，而聽者理解的是 A’，那麼，這個溝通不一定是正確的。不是都是 A 嗎？聽者只是理解成 A 的變形版本，但是本質可能還是 A，這有什麼不對？

大家應該都聽過「傳話」遊戲，這個遊戲是這樣的；多個人站成一排，每次都只能是前面一位告訴後面一位資訊，其他人不能聽不能說，當這個動作直到最後一位的時候，遊戲主持人訪談最後這一位遊戲參與者，會發現到這最後一位參與者所說出來的內容，與最一開始第一位所聽到的幾乎不同。

綜上所述，就算是從 A 變成 A’ 也不能輕忽，誰能知道最後會變成什麼呢？因此，訪談者需要總結訪談內容，並且簡單扼要地說出來給受訪的顧客聽，以及確認核實。

總結

訪談是一個看似容易的工具，因為單從旁人視角來看，只是一個人在詢問問題，另一個人回答問題而已，但是不知道技巧的訪談會讓好不容易促成的訪談變成一場沒有效果的對話而已，這對於開發團隊以及受訪的顧客來說，都是非常可惜的事情。

掌握需求訪談的技巧可以讓產品贏在起跑點上。