你心中認為做產品應該是什麼樣的事呢？
這本書其實不多在講如何管理專案，更多是談產品管理。但是在談產品管理之前，其實1/3的內容是講更本質的東西，就是組織架構和組織文化。為什麼一本講產品管理的書，要花這麼多篇幅來講這些感覺不很務實的東西呢？
書中不只一次提到這個問題，並從很多不同面向談到：很多時候一個公司最後沒有成功，並不是在於誰不夠努力，或誰不稱職。而是有時候人人都努力了，也都盡責了，事情卻依然不如預期。這是為什麼呢？
關鍵就在於沒有將人放在對的位置。或者在一開始是對的，但隨著環境情勢改變、內部人員流動，或是組織本身成長等各種原因，使得現在公司組織結構不再能滿足現況了。所以怎麼能把人放對位置呢?
其實在新創公司可能相對容易，成員不多自然選擇不多，人少於事時，有什麼事誰能做就去做了，甚至即使人不行也得想辦法頂上。注意：如果你所在的新創公司不像這樣，可能要多關注一下公司的未來發展了。又或者你對公司了解太少，不曉得是什麼人在為公司負重前行。
但隨著公司成長，人員增多，漸漸就會發生不曉得要將有些人放在什麼位置，似乎漸漸沒有那麼多合適他的事情讓他做了。也可能是新招募進來的人在公司沒有合適的位置。後著聽起來很誇張，但是招募前真的要想清楚為什麼要招募這個人? 他是來負責什麼沒人做的事?這些事目前是怎麼完成的？如果現在能完成這些事確定找一個新人那麼有必要嗎？ 還是替補什麼缺的嗎? 以前有這個缺，但是現在真的還需要嗎？這些事真的全部都需要做嗎？更何況實際上很難有人能完全替代另一個人。尤其很多是在公司成長過程中磨練出來的技能和經驗，你找來的人能完全替代嗎？不能完全替代也許沒關係，關鍵是你要知道這個人能在公司裡負責什麼。當然這也是好好思考公司各個職掌的時候，如果你平時沒時間好好思考這件事的話。
除此之外，公司其實是一個系統，關鍵的就是這樣一個組織像是個有機體，能自我成長，會自我復原。更明白的說就是，這個系統不會因為某一個人走了就垮了。每家企業其實都應該能做到 這點，成為一個系統。而要做到這點，重要的就是要有一個明確的組織結構，也就是說能明白區分織織裡的每個人負責什麼，以及不負責什麼，才不會浪費人力重複投資。這點看起來似乎很顯而易見不是嗎？ 但是卻不是每家公司都能做到。為什麼？
首先有可能的是，目前的分工和組織結構不合適現在的商業環境或情勢了。例如：以前都只做實體店面生意的，突然新增了線上業務了，這部份的事要交給誰負責? 原來負責實體業務的人可能很希望也能掌握，也趁機擴大自己部門，但是他忙得過來嗎? 又或是他的想法能轉換過來做新的模式嗎？ 那如果交給新的人負責，那會不會又和實體業務部門有衝突呢？像是線上訂價打到線下的銷售，大家都只去店面看看然後回家上網買。這些都沒有正確答案，但是如果要讓公司成為系統，不需要每次遇事不決，都要有請CEO裁決，或者要拉來一群"相關人等"來開會，花多很多時間，最後還是採投票表決。
所以這就是彼得聖吉(Peter M. Senge)的第五項修練裡提到的系統性思考。裡面提到的五個層次，事件、模式、結構、心智模型、願景。公司成為系統至少會有一個結構，所謂的組織結構。因為有了結構，所以公司能持續、穩定的來回應事件。這種持續穩定來自於結構產生的模式。所以公司不會也不應該依照每個客戶而各有不同的處理法，公司應該會有一個固定的模式來進行業務（或回應事件），而為了能有模式，公司組織必須有個相應的結構。
具體說到產品，其實產品不應該只是我們最後生產出來的那個東西。以軟體產品而言，要成為一個產品，絕對不是只有R&D寫好Code，然後Build出一套軟體（當然應該有足夠的測試過程），然後這軟體就能拿去賣給客戶了。要能把這軟體賣給客戶，其實中間還有各式各樣的問題要解決。即便不考慮行銷和定價這部分商業問題，光談技術面就有很多問題要解決。比如：這套軟體要如何安裝，能安裝在什麼機器上？怎麼更新？有什麼可能會遇到的問題，遇到了要怎麼排查錯誤和回報？回報問題後誰來處理，是有專門的技術支持，還是直接就會回到原本的R&D身上？（大公司通常會有技術支持，而且會分好幾線，處理不同難度的問題。而新創公司可能沒那麼多餘裕，回到R&D身上各人造業各人擔也是很正常的。）再到這套軟體能提供客戶多久技術支援，超過多少時間後不再支持？因為要維持一個版本的支援，表示就得要有人持續了解，並能修正上面的問題，而這些東西通常都已經在新版本上修正過了，所以更合理減少人力負擔的方式是超過一定時間的版本會停止技術支持，除非升級。就像微軟的Windows 7在發布十年後的2020年初也正式停止所有技術支持了。已安裝的使用者當然可以繼續用，但是微軟不會再提供更新了。
這些技術問題都處理完了，這在技術上才能算是一個完整產品。而且必須要有一套完整的流程能處理，而不是每次遇到不同客戶都要重新思考誰來處理，那才算是一個成熟的系統。
所以一旦外部或內部的環境及情勢有所改變，為了能再次建立符合環境情勢的模式，公司就會需要改變組結構，也就是我們平時聽到的組織再造，或是re-organize，簡稱re-org。
實際上當組織結構和環境情勢不相符時，你會常看到類似這樣的情況：
- 名不符實：有人開始在做著不屬於他職責的事。這有時候表面上看起來會是有人主動承擔職責外責任，但是差別在於，長期來看，這樣的職責外工作的效果不好。在變動快的環境有人願意承擔額外責任是好事。但是如果長期反而造成有事做不好，甚至無法究責（你怎麼忍心責怪一個好心做他份外之事的人呢？）。那不管是新的事或原職責，那也許就是組織結構有問題了。
- 反應緩慢：既然很多事在原先職責之外，那表示很多事都是以事件來處理，case by case，面對外界迅速改變，很容易慢慢就跟不上節奏。症狀就是，一直覺得很多事沒做，而且連具體要找誰來做都不曉得。初期可能找人兼任，就會出現上述名不符實的情況。
- 協調會議很多：到了後面階段，可能是新業務逐漸成形，機會明顯了，大家開始都想進入新業務，但因為組織結構還未有相應調整，造成互相踩線，所以老要協調。或者單一部門無法獨力完成整個業務流程而需要調動別的部門資源，這也需要常有協調會議。當然可能都是經理甚至總監去開。對於一般員工而言，可能看到的會是，老是被交待要做一些事，但是卻無法具體看到這件事和原本部門目標有什麼關係。似乎自己部門沒有足夠的能力、技術、資源能做，但老闆又無法答應提供相應的資源。
扯了這麼遠，其實這本書就是在講一件事，對於一個科技和服務類公司，什麼樣的結構，才是經過業界驗證和作者本身經驗覺得好的結構。有了對的結構，也才能打破那些做不好產品的模式，進而做出好產品。
是的，產品持續做不好也是一種模式。這時候你可以翻開這本書看看，借鑑一下，想想是不是有發生其中說到的問題。
而本書講這些內容的這部分，就是我從中得到最多啟發的部分。希望你在看本書時，不要錯過了。
產品專案管理全書
