又來有關書的事情了，先匯報一下進度：初稿完成7章中的前四章，字數分別為：22k、43k、46k、49k，總計16萬字，從字數看應該有全書的60%出頭，還真是蠻能寫的……漸漸的感到初稿完成後，每個章節的修改工作也是浩大的工程，未必比初稿省事。
前段時間提到了同行前輩們給樣章的意見和建議，我仔細的進行了思考，認為有必要盡早談一下我與本書的侷限性，就像做任何產品都要事先考慮「風險與對策」一樣。所謂「醜話說在前面」，本書給不了讀者的東西，我提前說出來，希望不要給讀者留下沒法滿足的期待。現在，只是我做產品經理的第四年，一直是一名一線的員工，雖說後來有機會帶領臨時團隊、參與戰略制定，但畢竟視野有限，很難做到「站在比較高的高度上看待問題」，強行上公升到理論，只怕會貽笑大方。我認為乙個出色的產品經理絕對需要十年、二十年甚至更長的時間來磨練，我深刻的認識到我還在半路上，有些產品經理應該做的事情我甚至還沒有接觸過，工作中我還沒有產出任何乙個真正值得驕傲的產品，甚至沒有經歷過乙個完全由自己說了算的產品，這也是我最近一年做「3個
1工程」的理由之一。
現在的公司是我的第乙個雇主也是唯一雇主，我待過的團隊也大同小異，而且，我做過的產品有明顯的侷限性，特點鮮明，都是電子商務、中小企業相關的應用，絕大多數讀者應該都沒有用過，對書中的一些例子也不會有切身體會。所以，不可否認我身上肯定深深的打下了阿里的烙印，如果說本書過於「阿里化」，我確實無能為力，因為我沒法寫我不熟悉的事情，否則就真是紙上談兵了。
產品經理做的事情，又不似技術那般嚴謹，所以有很多偏「藝術」的思維方式、做事方法必然只是在特定環境下才適用。但是「不識廬山真面目，只緣身在此山中」，在沒有更豐富經歷之前，對於更普適的情形，我只好盡量去思考，去領悟別人的話。
所以我只能寫出現在的體會，有些觀點可能片面、不成熟，甚至會被將來的我否定，比如在寫書的過程我就發現過自己一兩年前的博文中，有的看法近乎可笑。因此也希望讀者能理解，並帶著大大的問號來讀這本書。
我並不認為一本書需要理論完備，完備的話就意味著這個領域已經發展到盡頭了，爭議是極具價值的，如果本書裡的觀點能通過被批駁發展出更成熟的觀點，我也很樂於被拍磚，這可能有點像為自己的能力不足詭辯，但這也是我的真實想法。當乙個觀點被視為普遍真理的時候，是一件不好的事情，至少，這個觀點不再會發展了。當乙個問題有了明確答案的時候，這個問題也沒意思了。所以當我們發現自己或別人前後的觀點自相矛盾的時候，也許是好事，說明還在進化，當然方向的好壞有待驗證。
我的侷限性導致了本書的侷限性，還會表現在以下幾個方面。
因為我讀書的專業問題，雖然什麼都學了一些，但對於網際網路和軟體的技術，最高境界就是聽過幾門計算機專業的課，只知道一點概念，我更多的是學了不少電子、生物、醫學的知識，所以比較喜歡學科亂交叉，但要我程式設計、寫網頁那是絕對不可能的。
雖然小時候學過八年的畫，但上中學以後就沒繼續了，這是乙個遺憾，也許地球上少了乙個畫家。所以，我不會視覺設計相關的內容，甚至都懷疑自己的審美觀比較小眾，經常不理解一些群眾喜聞樂見的設計，但嘴上又不敢說，於是我只能充分相信專家，要我自己畫海報、設計圖示也是不可能的。
使用者體驗與互動設計很有意思，每乙個從事相關行業的人開始都會很感興趣，我也看過一些書和文章，不過最終還是把這塊當作了興趣，而往產品經理的路上走。我覺得一件事情，如果你真的覺得好玩，就別把它當作職業，當「想做的事」變成「要做的事」以後，不但失去了乙個「玩具」，還會有無盡的痛苦，做產品經理就不好玩，但很有意義。不過工作中我也是經常被迫做很多互動設計的事情，沒辦法，只能通過不斷的犯錯來證明老闆的不英明。
最後小結一下，這本書不是手冊、不是大全、不是工具書，只是乙個產品經理在前幾年成長路上的心得體會，如果你想更全面的了解產品經理，千萬不能只看這本書，試圖只看一本書就了解乙個領域的想法本身就是不成熟的，你能了解的只是作者在寫書時的觀點。我們應該養成乙個習慣，當看到乙個觀點的時候，就有衝動去尋找與之矛盾的觀點，然後通過對不同觀點的分析找出背後的原因，從而更全面的理解某個事物。乙個人成熟的標誌之一就是心中可以容納各種不同的思想而無礙行事，況且這本書裡談到的很多事情，我也無法把資訊完全展現，到不是有所保留或者涉及商業機密，這些因素都可以通過文字的修飾而淡化，而是因為人類所共有的侷限性——記憶失真。
產品設計體會（二九） 產品設計的五個層次
其實這篇是 使用者體驗的要素 的讀後感，其實讀了已經快2個月了，剛讀完寫讀後感會比較全面，而事隔一段時間再寫就能看出哪些是真正沉澱下來的要點了，也算是給自己找個偷懶的理由吧。大產品設計決定使用者體驗，而小產品設計又分為五層，帖一張業內著名了好幾年的圖。戰略層 明確商業目標和使用者目標，重點是解決兩者...
產品設計體會（十六） Feature List
看不清吧，那就對了，暫時不能讓你們看清 p 乙個feature，這次我給了它如下屬性 模組 一般來說，每個模組下分3 10個子模組是合理的，否則要考慮重新劃分 由於這個癖好，自己電腦裡的檔案目錄結構也是遵循這個原則的 子模組 稍大一點的產品至少要給功能模組做二級分類了，這部分其實又涉及另外乙個很大的...
產品設計體會（十二） 少而精
長假回來，這兩天基本在全力做 批量定時上架 的需求，n多的pk 評審 確認會搞得頭昏腦脹，不過終於算是把需求確認掉了。其中有些關於功能做多做少的爭論，這個話題在體會 三 中有所設計，但說的不深，這裡再寫點。一 個功能的多次需求會議中，必然有這樣乙個過程。開始對乙個功能想的不完整，說著說著大家都想把這...