不知道大家想過沒有，為什麼要把這條作為產品經理進行需求分析的第一原則呢？
我個人覺的，之所以這條作為第一原則，就是告訴我們這些產品經理乙個對待客戶的基礎態度，是什麼呢？就是「平等」。
有朋友會說了，我們提供能夠滿足客戶的產品和服務，客戶付費享受這些，這肯定是平等的呀，有什麼好說的呢？
果然如此嗎？
02年的時候，我在一家軟體公司做產品經理，當時我們公司為了能夠讓我們的客戶更貼近公司產品，最好是參與到公司產品設計中（聯盟裡好像有這樣一篇文章：《讓顧客參與產品設計》）成立了乙個叫「使用者實驗室」的部門，這是乙個常設部門，專門有乙個人在進行管理，主要的工作就是不定期的邀請一些公司的使用者來體驗公司的最新產品，並讓他們提出自己的意見和建議，以方便產品部門進行進一步的改進，目的是在上市的時候，盡量能夠達到使用者期望的指標。
這個部門的運作就不具體說了，具體說乙個案例吧。
有一次，公司另乙個產品的產品經理組織了一次新產品使用者體驗，當時來了大概不到30個使用者參與新產品的試用，大家想了，能夠耽誤個人時間來參加這次試用的使用者肯定是公司或者產品的鐵桿支持者了，因此，這些使用者都顯得非常認真，每乙個細節都不放過，並且在試用完成後，都非常精心的完成了公司準備好的問卷，至少從我乙個旁觀者的角度來說，我覺的這次使用者試用還是非常有成效的。
但是過了幾天，我和那個產品經理閒暇聊天，問他看了那天的使用者問卷，對產品有什麼新的想法嗎，他說「不瞞你說，你是沒看那些問卷，那些人（指使用者）的想法真幼稚呀，我就不信了，使用者會提那樣的問題出來」，我說「那你考慮去改進一下目前的產品嗎？」，他說「改什麼改，我設計的產品我還不知道，要是按照那些人的想法做，這產品成什麼了，我和你說啊，那些人來就是乙個噱頭，咱們該怎麼做還是怎麼做」。
既然不是我負責的產品，我也就不好太多說什麼，這件事情就這樣過去了，直到看到這個原則了，我的頭腦中才又浮現出這個事情。
通過這個案例，我就是想說明一點，其實在許多產品經理的心中，對客戶有一種根深蒂固的「瞧不上」，只不過是看在客戶掏錢的面子上，大家過得去也就算了。
後來開始帶人，不止一次的看到有的產品經理在拜訪完客戶回來後，興奮地和我說「我從來沒見過這樣的客戶，簡直什麼都不懂，提的問題真是弱智」，滿臉的不屑，甚至是鄙夷。
更為可怕的是，這種對待客戶的態度已經蔓延到整個產品團隊甚至是整個公司，大家如果留點心，可以去觀察一下團隊裡的對待客戶的態度。
那麼，為什麼會出現這樣的情況呢？
似乎聯盟裡也就這個事情進行過一些討論，大家都能說出許多原因來，我總結了一下，無非就是三點：
1、我是內行，客戶是外行
2、我是設計者，客戶是使用者
3、我是產品專家，客戶是產品使用者
這三點其實都反映出許多產品經理的一種心態，就是五個字：我懂你不懂。
果然如此嗎？
再來說乙個例子。
04年的時候，我在一家做sp的公司，負責他們的小區簡訊產品，這個產品大家都很熟悉，就是每當我們進入到某個區域的時候，例如你從北京進入到河北，就會自動收到一條河北移動傳送的歡迎簡訊，我們的產品可以由使用者來劃定範圍，例如北京-海淀-中關村-科貿大廈，只要一進入到科貿大廈，就可以收到一條簡訊，具體簡訊內容可以由傳送者來制定，同樣，也可以設定接收者在離開的時候收到簡訊。
按說從服務流程上一點問題也沒有，但是卻出現了乙個很大的問題，那次大概有500家參展商，據說有400家開通了這個服務，大家可以想象了，當那些領導在一踏入指定區域的時候，他們的手機該是多麼的熱鬧呀，當這些領導離開這個區域的時候，又不得不熱鬧一次，這還不是最麻煩的，最麻煩的是有一些領導因為某些事情，必須反覆進出這個區域，我想那些領導的手機在那一霎那，就似乎開了一場交響樂，交相輝映，熱鬧無比了。
最終的結果是移動的老總被省裡警告，我們被移動警告，差一點封了我們的埠。
這說明什麼呢？
我們做產品經理的，或許可以把產品本身設計的足夠好用，足夠完善，但是，我們很難把客戶的業務流程設計的足夠完善，也就是說，我們對於使用者會在什麼環境下使用我們的產品，往往是一無所知的，即使有了一定的資料去支援我們盡量能夠在使用者習慣的環境下使用產品，但是一切皆有可能，使用者是不會按照我們的思路出牌的，除非你做的產品就是獨一無二，無法或者不易被替代的，例如windows，即使這樣，微軟每年也要在使用者使用環境上下很大的功夫。
這就是需求分析原則一中的第二點：客戶比你更熟悉業務環境。
有朋友又會說了，這個問題其實也很容易解決呀，讓使用者把這個問題告訴我們不就可以了，從技術上來說，這個問題是很容易解決的。
果然如此嗎？
還以上面那個簡訊產品的例子來說。
首先，如果沒有這次展會，或許這樣的問題根本不會出現，那麼，我們永遠不會知道如此集中的使用者會在乙個集中的區域傳送簡訊，我們從何得知使用者會有這樣的乙個使用環境呢？
其次，即使出現了這樣的問題，而簡訊的接受人不是這些省力的領導，而是普通的參會觀眾，即使這個問題被反饋上來了，會引起我們的足夠重視嗎，如果能夠引起我們的重視，引發我們的思考當然最好了，那麼，如果沒有呢？
最後，即使我們看到了這個問題，但是通知給我們這個問題的不是運營商（其實也是如此，如果不是移動的警告，我想這個問題還會拖下去）而是乙個具體的客戶，我們能否平等地去對待這個客戶的意見呢？這就又和第一條聯絡在一起了，我們和客戶之間應該是一種平等，這種平等不是建立在交換上的，而是建立在心理上的，尤其對於產品經理來說更是如此。
好，那麼，如何來解決這種問題呢？
這就是需求分析原則中的第三點：真正的問題只有客戶知道，我們要做的就是讓客戶願意說出來。
這裡面包含三層意思：
1、客戶知道問題所在：作為產品經理，有時候會有一種心理優勢，認為自己知道問題的所在，其實不然，你所知道的只是產品本身問題的所在，但是產品不是藝術品，不是放到博物館展覽的，而是要由使用者在千差萬別的業務環境中使用的，不同的使用環境也決定了問題的多樣化，我們仔細想一下，其實有時候我們接觸的大部分產品問題本質上並不是產品本身的問題，而是因為客戶業務環境的不同造成的。
因此，從這個角度來說，客戶才是真正知道問題所在的人。
2、我們如何得知：客戶雖然知道問題，但他們並不是解決問題的人，最終還是要通過我們的分析來解決，那麼，我們就必須知道出現了那些問題，這就得通過客戶反饋給我們，無論是前面說到的使用者實驗室，還是現在咱們常用的許多形式，根本還是希望能夠獲得一手的使用者使用資訊。
3、客戶如何給我們：這裡不是說資訊反饋途徑，而是指客戶傳遞資訊時的心態，其實這是和我們的態度緊密相關的，正如前面第乙個案例說到的，雖然通過使用者實驗室能夠完成第一和第二個工作，找到問題和告訴我們，但是，我們可以假設一下，如果我以前那個同事對待客戶反饋資訊的態度被客戶得知，那麼，我們能認為這些本來很支援我們的客戶還會繼續支援我們嗎？爭取乙個客戶很難，但是放棄乙個客戶卻很容易，大部分客戶的流失並不是因為產品本什麼，而是因為我們對他們的態度。
因此，在第三點裡特別說明了，一定是要讓「客戶願意說出來」，而這種願意，本身就包含一種客戶的主動，而這種主動就是建立在我們對待客戶真正的心理平等之上的。
總結一下需求分析第乙個原則的中心思想：
1、需求分析第乙個原則：永遠不要顯得比客戶更聰明。
聰明反被聰明誤，這樣的事情太多了，我們產品經理都是有智慧型的人，而不是耍小聰明的人。
2、原則第一點：了解需求，而不是去批評客戶。
產品經理不是批評家，心理上要重視客戶，行動上要尊重客戶，平等對待每乙個客戶。
3、原則第二點：客戶比你更熟悉業務的環境。
產品經理熟悉的僅僅是產品本身，但是，產品經理要做的卻不僅僅是產品本身。
4、原則第三點：真正的問題只有客戶知道，我們要做的就是讓客戶願意說出來。
客戶會給你反饋，但是這些反饋有些是真實的，有些是敷衍的，你希望真實還是敷衍，請參考原則第一點。
觸控讀報機產品的研發過程回顧
在原公司開始著手讀報機這個產品的研發差不多有兩年的時間了，作為我完整負責的乙個產品專案，感覺有必要做個回顧和總結。一 市場調研 對於市場的調研分為兩部分，一塊是對市面上同類產品的調研，另外一塊是使用者的調研。從網上資料得知，當時世面上的產品已經有很多家了，大部分都是模仿的一家來做的，另外還有一兩家與...
產品經理如何有效進行產品需求管理
需求是整個軟體專案當中最重要一項輸入。軟體開發和傳統生產行業最大的區別在於，需求總是模糊的 主觀的和隨時變化的。相對於電子產品 汽車等製造行業有形的硬體需求，軟體開發的需求的描述和驗收是個難以解決的問題。但是需求又是整個專案能否成功的決定性因素，所以我們必須對需求進行管理，從而使需求成為整個軟體工程...
敏捷開發需求管理（產品backlog）
傳統的瀑布工作模式使用詳細的需求說明書來表達需求，需求人員負責做需求調研，根據調研情況編制詳細的需求說明書，進行需求評審，評審之後簽字確認交給研發團隊設計開發。在這樣的環境下，需求文件是資訊傳遞的主體，也是乙份契約。然而詳細的需求說明書有以下5大弊端 敏捷使用產品backlog來管理需求，產品bac...