該買NAS還是自己裝機器？

過去一陣子，經常有朋友向我問這個問題：「買台NAS有用嗎？」通常我會說要看你的需求而定。如果只是想找個簡單機器提供檔案分享，預算又還夠，買台小型NAS是最快又簡單的方法；但如果想要省點錢，又有些技術能力，用現有的設備改裝一下，安裝Opensource的套件，也是不錯的方法。

不過，最終仍然要看總體持有成本而定，意思是，初期除了購買零件、安裝軟體以外，後期維護和設定是不是會占了很多時間和精力。換句話說，在一、兩年以後，你還會想要管理這台機器，升級軟體並且設定備份功能嗎？如果答案是「不想」，那找台現成的NAS是不錯的選擇。

NAS優點：

• 設計成買來就用，安裝設定簡化過，操作更加容易
• 廠商會針對應用提供專屬服務，只需更新軟體就能修復錯誤或讓功能更豐富
• 內建磁碟保護，通常包含檔案層級和區塊層級的保護功能
• 省電安靜是最大的賣點，使用嵌入式系統和低耗電的處理器，讓整體系統維持較低的電力消耗，智慧型風扇也可以讓聲音不會那麼大
• 許多人會覺得NAS價格偏高，但如果和整機都是合法授權的電腦相比，其實更便宜

NAS缺點：

• 與具備高速處理器和記憶體的PC相比，小型NAS的效能不如個人電腦
• 因為系統是特殊設計，再加上專有軟體，價格可能由幾千到幾十萬塊，差異很大，選擇不容易
• 嵌入式系統會限制擴充的能力，想要把NAS變成ERP伺服器？那要看廠商支不支援

除了價位和功能，選擇品牌還是比較有保障，有些比較具知名度的廠商會提供不錯的客戶服務，甚至能透過遠端連線幫忙解決一些NAS問題，這些都是決定要採購NAS還是自組檔案伺服器時可以用的考慮項目。

展開新生活

經過數個月的考慮，終於還是決定要離開耕耘了八年的公司，雖然有許多的不捨，但對於一個只是實現某個人夢想的企業來說，光有夢想和資金仍然不夠，缺乏執行力，以及實際投入的心態，依舊無法讓夢想朝實現前進。

如果要用一句話總結這些年的經驗，我想應該是「信念的力量」吧。

在過去，我認為依靠一個人的力量要扭轉局勢，簡直就是痴人說夢話，現在，我徹底改變了這個想法，一個人的力量確實無法改變環境，但是一個人的信念，卻能夠讓局勢徹底改變，甚至能夠扭轉乾坤。

Discovery經常播放第二次大戰影片，就像是一場戰爭，在條件相似的情況下，決勝的關鍵就在於主帥的思維。也很像下一盤棋，對手總是時刻想要併吞我們的領地，而我們要做的，除了鞏固自己的領地外，還要想辦法去攻略對方的地盤，取得最後勝利。

如果連這點意識都沒有，就不要來參加這盤局。要不然就找個會下棋的人，來操盤整個棋局。

另外一件我學到的事情，是讓正確的人做正確的事情，才會成功。

在科技業，我看過的人，從大學生到博士，基本上能進公司，可以說都非常聰明，也非常勤奮。不過，稱得上成功的其實是寥寥可數，為什麼會這樣，經過這些年的風浪，我總算知道，即便是最絕頂聰明的人，都有其上限，也都有個人的局限性，不可能樣樣都能通，也不可能每件事都能站在最高的頂點。

而科技業是這樣，不站在頂點，就等於失去任何意義。

唯有團隊能讓企業站到頂點，而團隊需要領隊，這個領隊決定了團隊能否達成目標。

一群很厲害的工程師只會把事情搞砸，一群很厲害的工程師加上一個頭腦清楚的領隊，就非常有可能會成功。

問題是，頭腦清楚的領隊是怎麼產生的？

這讓我回想到當兵的時候，我有個學長從旅部轉到我們營，和我一起負責某個業務。部隊是這樣，每個月上級都會評比，並且發公告給全師，我們這個單位，一向是不好不壞的排在中間，我這個學長，從轉到營的第一天，就和我說，「你想不想放榮譽假」，我當然說好啊，學長說，哪你要照我說的做，從那天起，學長就和我把文書櫃搬到外面集合場，將塵封已久的舊卷宗全部拿出來，學長把大多數老舊的卷宗夾全部丟掉，能夠請購新的請購，不夠的部分就由我去外面買，然後用電腦列印將封面的標籤重新打過，接著我們粉刷文書櫃和推車，我可以理解粉刷櫃子，但是為什麼要刷推車就搞不太懂。然後，評比的日子到了，學長和我將規定的卷宗資料，裝在一個嶄新的塑膠箱，用粉刷過的推車，一路就推到評比單位。

榜單公布，我們負責的業務，出乎所有人意外，獲得了首次的第一名，長官龍心大悅，要人事官給我寫簽呈，各放兩個榮譽假。往後的日子，直到我交接然後退伍，總是保持第一、二名。之後我問學長，為什麼你知道這樣做可以讓我們領先其他單位，學長不說，只是笑笑，說這是秘密。

我現在想想，其實我們做的不過是最基本，最簡單的工作，甚至只是很簡單的清潔和整理而已，但光是這樣，對於評比單位來說，既然每個送檢的內容大同小異，整齊的外觀就代表業務負責人有盡心處理，甚至連推車這麼為不足道的小事，都就夠讓我們服務的對象感到滿意，也因此大幅提高了對我們努力工作的評價。

這個道理，我可以懂，但我不能了解，為什麼學長能夠那麼篤定，這樣做是對的，是怎樣的經驗，或是怎樣的觀察，讓學長輕易的得出結論呢？

產品管理的精隨，也或許就在此深刻的被顯示出來。

如何管理彆腳的創新產品

這是一個很怪的題目，是我在某個國外論壇看到的，覺得很有趣，提出些想法和大家聊聊。

某些時候，我們會遇到一些天才級的作品，通常是由技術高超的研發工程師想出來的，比我們曾知道的「殺手級應用」還要殺，不僅一舉突破現有的商業模式，甚至還產生典範移轉，因為跳Tone得很厲害，這樣的產品，我們通常叫做非連續性創新。

麻煩的是，天才的想法經常很不切實際，使用上困難重重，搞得大家叫苦連天，因此非連續性創新又叫破壞性創新，有時候是專門破壞自家的客戶，但有時候卻可以破壞主流商品的地位，是產品管理中難搞又不可忽視的一環。

相對於非連續性，大多數人習慣的是連續性創新。連續性，是指產品的本質沒有更動，只修改了一部份的功能或外觀，因此也稱為維持性創新，例如將螢幕由小變大，或反過來由大變小。連續性創新比較容易實現，因為變動的幅度小，阻力也比較小，不過產生的市場影響通常也不會很明顯。

非連續性創新就不同，意味著類型的改變，影響程度非常深遠又顯著，同樣的，也產生了巨大的阻力和風險，幾乎變成一場豪賭。

由於大多數的非連續性創新都是失敗收場，遭受四周無情的譴責和批判，理由不外乎是不了解市場、客戶需求就貿然進行，遇到這類的案子，如果公司仍執意要進行，產品經理在跳海自殺前，必須先想辦法改變自己的習慣做法。

就產品管理的立場，非連續性創新其實是很好的市場策略，因為產品的獲利報酬是最大的，但由於風險太高，除非必要，一般公司是不應該輕言嘗試。如何判斷產品是非連續性創新呢？最簡單的方式，就是檢查產品交給消費者後，是不是會要求使用者改變原有的習慣或行為，來配合產品的運作。要知道，除了極少數的技術狂熱者，一般人是不太容易接受改變習慣的新產品，也因此非連續性創新的商品，必須具備極高的價值，吸引使用者放棄原有的方式，願意改變成新的做法。

也就是說，管理會讓使用者感覺不舒服的新產品，最重要的是管理「產品的價值」。

一個例子是電腦軟體的Client-Server架構，早期的電腦軟體，大多都是單機執行，運作沒有太多問題也非常順利，讓許多商業公司獲得極大的效益，因此當第一批Client-Server架構軟體推出市面時，其實並沒有那麼受歡迎，實際上，還遭遇到極大的阻力。

最主要的抱怨是當Server出問題，所有前端電腦的應用程式都失效了，造成所有人的工作全部停擺。直覺上應該是很難讓企業接受的方案才對，然而，就後見之明來看，現在幾乎所有的企業都導入了ERP系統，證明Client-Server並沒有想像中的那麼難以接受。

雖然ERP伺服器故障確實會造成大問題，但ERP所帶來的好處，統合商業流程和再造，卻遠高過伺服器故障的風險，更何況，陸續出現更多能夠保護伺服器的系統，大幅降低多數可能的風險。因此 Client-Server雖然改變了企業購買軟體的習慣，讓企業必須承受相當高的風險和漫長過渡期，但結果卻能打敗單機商用軟體，成為破壞原本市場的創新架構。

因此，管理非連續性創新的產品，不能用常理來看待，特別要注重與現有商品的比較，由於競爭對手是目前市場的廣泛布局的商品，提供的功能和運作，如果必須要改變，那就要比現有產品具備更好、更明確的價值。問題是，評估商品效益的Criteria已經被現有商品占據了，要打破相當不容易，因此產品經理的另一個要務，就是思考該如何使用其他的Performance Benchmark來凸顯新產品的特性。

舉例來說，傳統吃汽油的汽車，加速和長距離運輸都占有優勢，具有市場破壞性的電動車，以原先指標比較，很難在短時間超越，因此改以環保這個新指標來對抗，也許剛開始消費者意識不夠，並沒有造成風潮，但當市場逐漸重視環保議題，電動車就有可趁之機。

為了要突破市場的瓶頸，公司總要保持一兩樣非連續性創新的產品開發案，產品經理在面對類似的案子，先不要急著調頭就跑，謹記不要用一般的管理技巧來看待，要比連續性創新產品更加注重價值，時常和現有商品進行比較，甚至天馬行空想些不同的驗證方式來強調新產品的獨特性，彆腳產品能否出線，成為破壞競爭市場的超級大殺手，就看產品經理這個「伯樂」能發揮多少作用了。

如何招募產品經理

很快一個農曆新年過去了，公司行號除了規劃新年度計畫之外，招募新人也是很重要的工作。既然我們談的是產品管理，那我們這次就來聊一聊，該如何招聘一位稱職的產品經理（Product Manager）。

有別於列出所有產品經理該有的特質，我比較喜歡採用問答方式來挖掘有潛力的人選，有興趣投入產品管理的讀者，也可以試著回答下面的問題，看看自己是不是適合這樣的工作。

原則上，產品管理工作屬於彈性應變的類型，與其希望候選人能夠回答出正確的答案，倒不如採用開放式問話[1][2][3]，深入了解候選人的思考模式，反而更能有助於準確判斷出潛力，我們將項目大抵分成個人特質和職業技能兩部分。

一、個人特質

「你看過最棒的產品是什麼？」

也可以改成「最喜歡的網站」或是「最喜歡的手機」，然後試著問問具體的理由，普通人會試著告訴你幾種市面上有名的產品，卻不知道為什麼這些產品會受到歡迎，而一個有潛力的產品經理，會告訴你喜歡這些產品的具體原因，例如產品具簡潔優雅的介面設計，或是無與倫比的執行效能。

從這裡也可以看出面試者是否具有產品熱情，和宅男不同的是，好的產品經理不止熱衷於最新產品，也會尊敬產品的創新，對相關產品也能滔滔不絕，朗朗上口。缺乏熱情的候選人，只是把產品當作謀生工作，動機不夠積極之外，也不會願意深入產業環境。

「你覺得誰會購買公司產品？」

或者是「你覺得誰會用公司產品？」，好的產品經理，也是願意去了解人性的人。產品最終還是要由人來使用，只重視產品功能，而不去考慮使用者的感受，製造出來的產品，很容易就變得非常「工程化」，即便現今的鋼筋建材，也必須有一些方便施工的設計，或利於運輸的滑軌裝置。

有時候產品設計會牽連到介面設計，尤其使用者直接面對產品介面，和候選人聊一聊介面如何改進，有助於了解候選人對人性的理解程度。如果認為讓使用者直接在介面下SQL語法，是一種有效率的做法，哪公司可能要稍微考慮一下這個人選是不是太過技術了。

「人孔蓋為什麼是圓的？」

這個問題其實是有名的微軟面試題，好的產品經理也是聰明的人，不僅邏輯分析清楚，也能夠深入了解問題的根源。產品在市場總是要面對各種狀況，普通候選人思緒不清，面對問題手足無措，連帶會影響產品團隊信心。

「談一談你的失敗經驗」

繼續上一個問題，產品總是會遇到問題，好的產品經理必須是有責任心的人，即是面對可能的狀況，也能冷靜分析，堅持到底。這個問題的目的是要了解候選人面對失敗的態度，是屬於消極逃避，還是勇敢面對，當然，好的產品經理總是有許多備份方案，了解候選人如何安排備份方案，可以挖掘出更多個性上的特質。

「你要如何告訴你的老闆，時程要延誤了？」

產品經理必須實事求是，也必須是個正直的人，面對可能的失敗，大多數人會選擇逃避或隱瞞，但公司開發產品，最終仍是要獲利，遇到隱瞞問題的產品經理，公司要付出的，往往會遠高過Cancel產品的代價。

「公司提供你甚麼東西會讓你成功？」

好的產品經理往往是領導型的人，一個有信心的產品經理，影響不只是產品本身，最重要是能夠影響開發團隊，鼓舞團隊士氣。

新人可能沒辦法像有經驗的人那麼有信心，這時候就需要充分的學習能力，主動了解產品管理該有的技能，並利用這些技能，將產品規劃出來，以此逐漸建立自信心，而自信產生最好的方法，就是曾經成功銷售產品過。

二、職業技能

「你如何獲得開發團隊的尊敬？」

有別於專案Leader，產品經理深入技術層面比較淺，有些開發團隊，對於不夠「技術」的人來領導團隊，會有怨言，或有瞧不起心態，因此產品經理必須善於溝通，讓開發團隊了解，產品經理不是開發團隊的老闆，不是來管理團隊的，而是要帶領團隊，開發出市場會大賣的商品。

客戶是產品經理最堅實的後盾，好的產品經理，會試著利用客戶故事來影響開發團隊，故事尤其能串起大家的共同思維，錄一段客戶的影片也是很好的做法，利用幾個畫面將產品的特點強調出來，是能夠加強溝通的重要技巧。我會希望候選人真的有拿過V8，去拍過客戶使用產品的樣子，而不是嘴巴說說而已，因為實際做起來會比想像中難多了。

「你要如何知道客戶滿不滿意產品？」

如同上面提到，產品開發或進入市場，總是會遇到挫折，好的產品經理是正面、樂觀、不抱怨的人，此外，也會想辦法讓客戶更能夠接受產品。在這之前，了解客戶對產品的觀感就變得很重要，如果候選人表示曾有客戶願意推薦產品給其他朋友，則顯現了更好的結果。

當然，客戶一定會挑剔產品，不適應的產品經理，可能會將問題推給開發團隊，並不斷抱怨開發團隊的能力有問題，而不去想辦法讓產品改進，這樣對公司來說，不但沒有解決問題，反而產生更多的團隊衝突，變成所謂的「爛PM」。

「談一談你曾做過最有創意的事情」

科技和市場總是不斷變化，產品經理不能守成不變，必須時刻了解最新科技的進展，並有能力應用新技術解決產品問題，我們不必發明太多的新輪子，但當新輪子出現在市面，能意識到新方法可以解決問題，這種技能需要長時間的培養，沒有辦法在學校學到。代工類型的產品經理發揮創意的機會比較少，但可以從流程中下手，例如改變一些做法，就可以讓產品更有效達到較高的良率。

「你如何決定不要哪些產品功能？」

我認為這個問題非常不好回答，卻最能看出候選人是否是個稱職的產品經理。產品經理要能專注解決問題，最好是 KPI導向，但非要學術化。好的產品經理知道，做哪些事情，能帶來哪種影響，而這些活動最終能解決大多數的產品問題。至於其他無助於解決問題的功能，自然就會排除在優先列表上，當然連帶開發團隊的工作，也會更加有效益。

之所以難回答，在於增加功能總是比較容易，而要刪減功能必須面對政治壓力，其他部門的挑戰等，有經驗的產品經理必定經歷這個過程。

「你如何判斷產品是完善設計的？」

如果我們要知道一件畫作的價值，我們會去找鑑定師，請他們為藝術作品估價，鑑定師的評價重點，大多在於作品細節，尤其觀察作者是否投入心力去完成。好的產品經理也是注重細節的人，就像評鑑一幅畫作，產品經理也不斷評估產品是否完善。也許產品經理不知道產品是怎麼開發出來的，但具有明瞭產品優劣的眼光，可以彌補這方面不足。

「你如何讓團隊成員承諾開發時程？」

開發團隊總是不喜歡訂一個明確的時間，但好的產品經理必須有時間觀念，因此公司需要有時間管理能力的人，這裡的管理，不僅是說產品要準時，而包含了所有團隊成員的時間，互相搭配的切入點，以避免團隊從事浪費精力的事情。

「你覺得產品需求文件需要哪些內容？」

好的產品經理也是擅長寫作的人，許多成功的產品經理，甚至可以代表公司發表部落格文章。產品規格文章最重視能夠清楚傳達想法，避免造成混淆，其中市場和產品需求是產品經理必做的文件，如何讓公司主管和團隊成員，只要透過文件就達成共識，是產品經理最有用的技能。

這裡有一個範例[4]供大家參考。

「你要如何向你的姪子解釋，什麼是資料庫？」

產品經理要有將複雜的事情，用簡單的方式表達的能力，以目前大環境來說，就是要有簡報能力的人，要評估候選人是否有能力化繁為簡，最簡單的方式就是請候選人說明一個難以解釋的物品，然後看看候選人如何描述。類比技巧在這邊是很有用的方法，不過要小心過度使用類比，造成畫虎不成反類犬。

「你覺得1 giga byte的gmail值多少錢？」

這也是一個有名的Google面試題，即便是名校MBA也不見得能回答的正確，因為其中牽連的技術層面並不低。但好的產品經理，是技術和商業知識並重的人，在規劃功能時，也會同時加入商業考量，如此才不至於落入技術泥沼，而忽略的成本議題，最後造成產品做出來了，卻沒有人買得起。

許多剛取得MBA學位的畢業生，第一份工作就是產品經理，這是因為具有商業知識的人在技術掛帥的公司裡面，是比較稀有的類型，公司理所當然也就期望新人能帶來更多商業上的幫助。

這裡有一個爭議，是應該找具有技術背景，還是具備商業背景的人選比較好？

只能說各有優缺點。如果可以選擇，可能有人會對我的想法不太贊成，我的意見是，找具有技術背景的人比較好。

並不是說MBA沒有用，事實上，MBA更像是培養未來的CEO，而我的理由是，商業知識在產品管理中，並不需要太深入，雖然財務和會計分析也是產品管理的一部分，但並不是全部，沒有必要像財務部門哪麼精深，了解一些基本的名詞和用法，例如邊際效應（Marginal Effect）或損益平衡點（Break-even Point），也就夠了，而這些還不至於需要去修個MBA學位。

能夠完美回答上面所有問題的候選人其實不多，當我們在尋找適合的產品經理，也必須考量公司的需求，例如企業文化和公司組織，特別需要哪些特質，這樣才不會浪費雙方時間，讓每個人都更容易找到適才適所的位置。



Reference:
[1] Marty Cagan. Recruiting Product Managers. 2007.
[2] Product Manager Interview Questions.
[3] How to hire a product manager.
[4] Product Requirements Document.

回復：如何開發高價值的產品

: 滾輪滑鼠製造商也改做光學滑鼠
: 甚至提供市場更便宜的價錢和更好的Quality
: 那這樣光學滑鼠的競爭優勢不也漸漸消失了嗎? 就再也不獨特了
: 不知道這樣想有沒有甚麼錯誤的地方?
: 或者創業初期評估的時候  是否需要包含別人可copy性的barrier呢?

看到大家對高價值產品議題這麼熱心，可見這是個不錯的題目，尤其draculatu、ocksure56、BLPS和super101大大分別提出了不同的看法，顯現出產品的獨特性，或者說產品競爭力，是大家一直關注的話題。

利用回答BLPS這個機會，補充說明我對獨特性競爭優勢的總體解釋。基本上，我認為大家的看法都有一定的正確性，唯一的差異，包括我，是我們分別回答了企業不同階段面對的問題。

開始之前，引用「企業生命週期管理」[1][2][3]，來解釋投資者對於企業在不同階段的價值，為何有不同的觀點。

我們通常會將企業的生命周期，簡單分為兩個階段：「成長」、「老化」。我假設應該沒有太多人會再想灑錢到一個邁入老化的企業，因此重點在成長型的公司。

成長型公司又可以分為六個時期：

1. 追求期
2. 嬰兒期
3. 學步期
4. 青春期
5. 壯年期
6. 穩定期

題外話，看到上面這樣的條列，我真的覺得產品管理和顧小孩沒兩樣。

上一篇我提到USP（Unique Selling Proposition），當時公司大概是處在學步期左右，這個時期的目標，比較著重在「業績和市占率」，公司的體質還不算健全，名氣較低，產品種類也比較少，公司競爭力主要還是看產品的價值而定，沒辦法考慮太多，以盡快取得市場能見度為要務。因此投資者會迫切想要知道，產品和競爭者之間有多少差距，也就不足為奇了，所以我們必須要告訴他們，產品的獨特價值，以及我們如何超越競爭者。

而到了青春期和壯年期之間，利潤就變成企業追求的目標，也就是轉變成利潤導向，產品除了要達到相當程度的市占率之外，也必須能開始為公司帶來高利潤，這樣投資者的回收才會提高。

這個時期，競爭者開始模仿優勢功能，產品本身的功能獨特性會下降，
由於現在這年頭，很少有技術是沒辦法跟上的，建立門檻變得很困難。
當滾輪滑鼠的廠商開始製造光學滑鼠，Unique的優勢就會逐漸接近，
甚至很快就能夠達到平等。

那接下來該怎麼辦？這個階段，投資者就會像draculatu和cocksure56提到的一樣，看的是企業的研發能力或商業模式。如果我是滑鼠廠商的投資者，我會想知道，下一代具有其他Unique話題的滑鼠產品，多快可以上市？有沒有專利保護？這些屬於體質面的獨特價值。

不久前我在某雜誌上看到，某廠商發表了宣稱可以在牛仔褲上面操作的光學滑鼠。至於這樣的獨特性是否會吸引顧客，或者足以大幅度的擺脫競爭對手，則是另外一種議題了。

順帶一提，步入老化的企業如何產生Unique的商品，最快方法就是併購新創事業，引入沒有受到「汙染」的創意，擴增更多的獨特性，例如IBM或Intel，這樣一來，股市交易才會更加活絡。因此，新創企業也可以採用逆向思考，考慮如何讓大型企業併購，以獲得更充裕的發展資金。

我個人特別喜歡super1012的這一句：

「Product life cycle management is a science...」

我覺得，PLM不僅是種Science，更接近是一種Art，因為它充滿了各種主、客觀的意識，運用人機智慧整合的技術，形成一個具體的實務，提供使用者各式各樣奇妙、驚豔的感官享受。但市場瞬息萬變，客戶口味不盡相同，產品的改良是永無止境的，也正因此這是產品管理之所以存在的最大價值。

Reference:
[1] 楊千. 企業生命週期的管理法則.
http://www.scmlife.com/telelogic/Events/2007/TW/PPT/yangqian.pdf
[2] 林美鳳, 吳琮璠, 吳青松. 資訊科技投資與企業績效之關係— 從企業生命週期論析.
http://ntur.lib.ntu.edu.tw/bitstream/246246/84810/1/3.pdf
[3] 戴秋芸. 從企業生命週期談 高績效組織的人力資源管理.
http://www.cphr.tw/images/0705_1.ppt

如何開發高價值的產品

前幾回，談到獨特性這個議題，後來有讀者寫Mail向我反應，產品過於獨特，會不會還來不及「一枝獨秀」，就先變成「特異獨行」？

這是個大問哉，我想利用一個親身經歷的故事，稍微有點長，來解釋獨特性的意義。

早些日子，天氣晴朗的上午，公司莫名其妙來了通電話，通知要開會，說是一位很重要的人物要來，希望我能協助簡報市場現況，剛開始沒想很多，只是很單純的答應，雖然臨時被通知很突然，不過不會難倒我，
因為我平時就準備得很充足，相信臨場反應沒有問題。

然而，就是因為太過自信，而讓我犯下了兩個錯誤，導致會議有點尷尬。

很快的，我就將資料重新整理，帶著簡報到會議室，待老闆介紹完前言，我就開始進行報告，由於通知我的人忘了告訴我，來的很重要的人是誰，因此我就犯了第一個錯誤：報告內容沒有「針對性」。市場的資料，我已經調查了很久，也寫了好幾十頁的分析，內容沒有問題，但我偏重產品銷售角度，因此雖然我在報告時講得口沫橫飛，卻隱隱約約感覺不到聽眾有共鳴，當然，業務主管倒是很有反應，只是他並不是我的重點。

接著，這位很重要的人問了幾個問題，我都可以直接回答出來，但有一個問題，他重複了好幾遍，始終覺得很不滿意，甚至說：「我覺得你聽不懂我在問什麼」，大老闆看情況有點不對，就叫我們先暫停一下，我在休息時間，問了其他主管，那位很重要的人是誰，才知道他是某大公司的高層，也是我們潛在投資者，就是所謂的金主，今天是來確認我們的能力。

這下麻煩了，由於我主要是從事產品管理，還沒有碰過類似投資者的角色，一下子不知道該怎麼回答他的問題，後來我的老闆出面打圓場，總算是先讓這位重要的人知道我們要回答的內容。他的問題則是我的第二個錯誤，其實是一個很簡單的問題：

「你們產品和市面上的競爭對手，有哪裡不同？」

這應該是個容易回答的問題，但我直接的答案並沒有辦法讓他感覺滿意，我利用準備好的資料，和已經完成的比較表，列舉了數項與競爭者不同的功能，但他似乎還是不認同，不斷反駁我提出的產品功能優勢，直到會議結束。

事後，我問了其他人的意見，並密集搜尋有關創投想要的資料，想要了解究竟他想問什麼，最終，我終於弄懂，他要問的是：

「舉一個例子，你們的競爭者無論怎麼努力，也無法贏過你們的地方，一個就可以。」

其實這是投資者思維和工作者思維的最大不同點，投資者永遠看著價值，不管是金錢的價值，產品的價值，還是為其工作者的價值，有高價值的事物，才值得持續投資。產品能夠帶來哪些具體的價值，也就是投資者最重視的條件，而這裡所說的價值，並不是說產品的功能多麼優秀，反應速度多快，或者價格比別人低。因為價值觀是隨著人的觀點而改變，不同的對象面對同樣的東西，會有天差地別的評價，例如我認為LV包實在不值那個錢，但我老婆則認為LV包是無法用金錢來衡量。熟悉企業經營的投資者，非常重視價值觀的運作，也就如此，我們必須清楚告訴他們，我們的團隊和產品是如何的有價值。

姑且不論團隊的素質，就產品本身，問題是，什麼樣的產品，才叫做有價值？我相信，「無可取代」應該大家可以認同的價值觀中最高點吧，
用商業用語來說明，表達的方式就是USP[1]，全稱是Unique Selling Proposition。

為了更深入了解USP的定義，我先利用網路搜尋所有相關的資料，在Google裡面，有超過一百萬個網頁談到USP，而在Slideshare，我找到了533個和USP有關的簡報，這麼龐大了數量，顯現出這是一種易懂難精的方法，意思是，真正能透過USP將產品獨特性發揮出來的案例，其實是寥寥可數。

要先了解，為什麼產品獨特性，這邊是指 Unique這個字眼，那麼重要，因為我們生活在一個物質過分充裕的時代，有非常多樣可供選擇的商品，已經不是廠商做甚麼，顧客只能傻傻買單的美好年代。因此，產品開發一定有競爭者，即便是在1950年代，從事DNA研究，就有一大堆人馬在進行，所有人都在求快、狠、準，誰能更具有獨特性，誰就能夠成功，「紫牛」[4]這本書已經談很多，我就不多贅述了。

我所犯的錯誤，在於將產品特性用技術的方式表達，因而忽略掉，價值的重要性。我會忽略掉，是以為USP是廣告公司用的行銷技巧，根據記載，USP在1961年提出，主要用於廣告行銷的一種表現技術，但是，到了最近幾年，USP卻演變成在撰寫Business Plan[5]時就會用到的基本項目。主要因素，是2000年網際網路泡沫化之後，投資者或創投公司，對浮華不實，過度誇大的商業計畫，越來越沒有信心，也逐漸認清，產品本身的價值才能帶來實際的利潤。而獨特性是其中一項要素，因為Unique不僅能夠說明價值之外，也能帶來市場能見度，能夠在眾生芸芸環境中，脫穎而出，擺脫競爭者，如果連這點都做不到，只是Me Too的話，投資者的信心會降得很低。

此外，一般獨特性被質疑的問題是，Unique代表只能滿足特性需求，
或是針對某些族群才有銷售賣點，這樣會不會讓產品視野做小，變成小眾市場？當然這是所有人都會擔心的問題，然而，就「跨越鴻溝」的說明，如果連Early Adapter都過不去，更別提後續龐大的普通消費者。
那該如何避免造成「特異獨行」的問題？我認為應該要在制定USP時就將分析做好。

基本上，一個完整的USP，會由兩個部分所組成：

1. 問題
2. 提案

以M&M巧克力為例，傳統的問題是巧克力放在手裡太久會融化，不管是大人還是小孩，因為巧克力溶化，將手弄得髒髒的，黏黏的，總是會破壞吃巧克力的好心情，有些人甚至認為滿手油脂是一件很噁心的事情。M&M提出的方案，是一種不會在手中融化的巧克力，這種產品的表層有一層薄糖衣，五顏六色，拿在手中，因為糖衣的溶解溫度比較高，手心的溫度還不太會溶化巧克力糖衣，因此吃得過程相對就乾淨許多。不過就我的實際經驗，拿太久還是會融化，可能是手汗多，算是我比較挑剔。總和問題和提案的部分，就成了家喻戶曉的「只融你口不融你手」這句話。

轉化到產品開發，當價值觀很明確，產品和研發部門就有清楚的共同目標，能夠開始深入研究，應該怎麼開發出這種高價值的巧克力。我記得，看過一本書「如何移動富士山」，裡面曾提出一個問題，不曉得有沒有人能回答：「你要怎麼製造M&M巧克力？」。如果我們沒有經過價值觀的洗禮，一下子就進入到思考如何製造巧克力，就陷入錯誤的思考邏輯，最終結果可能會開發出很好撕的外包裝，也就因此失去獨特性了。所以，透過USP，不管是投資者或是客戶，還是企業員工，都能夠很輕易的瞭解產品的賣點。

既然知道了USP的作用，我們就來嘗試建立一個自己的USP，引用[2][3]說明的方法，從事新產品開發的讀者，也可以自己試看看：

1. 寫下三個產品最好的優點
描述產品可以提供的優點，例如更好的品質、服務或是更低的價格，
然後要進一步解釋，為什麼更好的品質對顧客是重要的，顧客一定非常重視品質嗎？還是其實他們更重視價格呢？

如果不知道怎麼開始，我的做法是將幾個可能的特性，大約五個，畫成雷達圖，MS Excel有內建這個圖的樣本，有看過以前「火焰大挑戰」的人，應該知道雷達圖的作用，表現出各個特性的強弱程度，利用雷達圖將產品優點強調出來，最好多嘗試幾種不同的組合，也許會有不同的發現。

2. 寫下客戶購買的選擇項目
其次，寫下客戶採購產品時，可能會列入選擇的功能，想像自己是客戶，當要買這類型的產品，哪些是購買的考量，這邊加入我的經驗，
最好是將Must to have和Nice to have標示出來，然後確定其中有最獨特的Unique點。

例如運動鞋，我第一個考慮品牌，因為我主要運動是慢跑，因此幾乎只穿 Nike，第二是要有慢跑鞋款式，重量要輕。寫下這些條件，判斷的標準很容易，就是其他競爭者，無論怎麼努力，就是無法跟上的項目。

要注意，價格可能是產品的優勢，但並不獨特，因為競爭對手只要稍微調整一下，就能夠輕易的趕上來。比較好的例子像是舒適性，例如光學滑鼠比滾輪滑鼠更加舒適，因為光學滑鼠不會因為需要清潔滾輪，而越用越不順手，但無論滾輪滑鼠再怎麼改善，都無法超越光學滑鼠，因此可以說具備Unique特性。

3. 寫下產業的痛點
然後，試著描述產品解決的問題，或者產業面臨的挑戰。困難的地方在於如何辨識出哪些問題還沒有人解決，或者需要更好的方法。

我個人認為，分析產業的挑戰是最難的，因為大多數的人，只要還能用，或不會有太大的困擾，基本上都還算可以忍受。比如，我個人覺得LCD電視的畫質實在不怎麼樣，但是要我換成更高檔的電漿電視，考慮費用的增加，還有目前勉強能適應，我是不會去更換家裡的電視機。因此當我們告訴客戶，這樣的狀況真的很不好，大部分的客戶反而會告訴我們，額外的費用付出，沒有辦法吸引他們，改用我們的產品。

4. 寫下產品對客戶的承諾
要相信客戶看待產品的承諾是非常嚴肅的，就像我們會相信某家奶粉會讓小孩長得像大樹一樣，產品給予客戶的承諾，也就是客戶購買產品的價值，必須是簡單易懂，而且是具有高度的可性度。一個錯誤的例子：「給我一塊錢，我會給你一千元。」很明顯就是一種不切實際的承諾，
不但沒有人相信，還可能讓公司吃上官司。我個人喜歡這一句：「給我30分鐘，我給你全世界。」

5. 重複修改文句，直到無法再增減任何字
最後，把所有的字句組合起來，用各種可能的排列組合，找出一個感覺最通順，最能直接表達意涵的句子。花個三、四天的時間，不斷的增修刪減，直到無法再有更好的，也是最完整的一段話，達到「增一分太肥，減一分太瘦」。

6. 將USP放在所有的產品文宣，然後拿給客戶看
然後，將完成的句子放在現有的文宣或網頁上，看看有什麼不同，跟原本的版本做個比較，是不是更容易讓人對產品感到好奇，或者更加感興趣。試著請公司所有的人，以及現有的客戶，一起比較看看，問問研發人員，完成的USP能不能觸發靈感，如果答覆是正面的，這就是一個非常有用的高價值產品描述。

要注意，客戶的直接反應才是最真實的，我們認為的優點，不見得是客戶需要的，一意孤行最後就會變成特異獨行，也就是「Go play with yourself」^^。

7. 確認產品不會違背USP的承諾
一般來說，提供給投資者的內容，大概到第六項就夠了，但因為我們從事產品管理，還必須特別注意第七項。我們是不是真的能夠遵守承諾？
特別要注意，產品開發公司，信賴是絕對重要的資產，而客戶信賴感絕對不是一時三刻就能夠產生出來，它要歷經長久的磨合，不斷的淬煉才能夠擁有，但只要一次違背了對客戶的承諾，所有的努力和付出，就會在一夜之間付之流水。而這個工作，正是產品管理的責任！

價值是產品的基礎，獨特的價值則是產品競爭力。能夠激起共鳴的USP，還有一個重要作用，就是對經銷商特別有用，因為他們只要照抄就行了，此外，也能夠激起經銷商的創意，發現其他我們沒有發現的商機。畢竟產品公司需要花費大量的時間，管理產品開發，維持品質和提案新產品，對客戶的實際需求，總不如經銷商來的更深入。我在以前的文章說過，經銷商不會幫產品公司思考產品價值，他們的任務是將好產品送到客戶手中，並協助客戶使用產品，至於產品的價值，則是產品公司必須提供的資訊，而USP是一個簡單易懂的方法，用在通路管理，也是一個好工具。

Reference:
[1] IMP. 獨特賣點（Unique Selling Proposition）.
http://www.twcim.com.tw/front/bin/ptdetail.phtml?Part=column013&Category=255021
[2] Alyssa Gregory. 6 Steps to Creating a Unique Selling Proposition.
http://www.sitepoint.com/blogs/2009/09/12/how-to-create-unique-selling-proposition/#
[3] Matt Hockin. How to Create Your "Unique Selling Proposition" (USP).
http://www.interactivemarketinginc.com/unique-selling-proposition.html
[4] Seth Godin. 紫牛－讓產品自己說故事.
http://www.books.com.tw/exep/prod/booksfile.php?item=0010239596
[5] Alyssa Gregory. Business Plans: Do You Really Need One?
http://www.sitepoint.com/blogs/2009/09/03/do-you-need-a-business-plan/

老調重彈，談專案經理要不要懂程式設計？

我應該是適合談論這個話題的人選之一吧。

回顧短短十年間，我從拿烙鐵的電子科系轉到拿鍵盤的資訊工程，再從專案管理轉到產品分析和打嘴泡企劃，經歷過的工作內容，包含開發第一支Disk ROM程式，負責規劃出完整系統，帶領專案完成開發，製作產品簡報，到客戶公司介紹功能，撰寫應用架構說明等，完成的工作可能是許多人一輩子都做不完的事情，也因此我手上有一些壁紙和房貸，不過這是後話了。這樣，我大概稍微有立場能和大家家聊聊，RD與專案經理之間的愛恨情仇。
                                                                               
碰巧最近公司內，因為某些原因，又開啟了這個骨董級的話題，頗有感觸，本來是不想下去淌渾水，後來想想，如果換個角度，從現在產品管理立場來看，是不是有更好的詮釋。先回答標題的問題：專案經理要不要懂程式設計？就我的看法，我認為，應該要懂；不過，不懂，也沒關係。

我們現在有很多年輕的程式設計師，功力相當不錯，工作交辦下去，不用太擔心，但就怕走錯路。
                                                                               
當我是專案經理的時候，我怎麼讓專案進行呢？分成兩階段，早期，當時的開發功力，現在當然爛很多了，要打趴大多數的人，應該不是甚麼問題，事實上，我那時也天真的這麼認為，所以，看到一些人不爭氣，就變成自己下海解決問題，熬夜趕工，結果呢，幾乎把自己累死，還差點害專案開天窗。

後來的階段，我才慢慢弄清楚，團隊的力量該如展現，最主要是常盯著目標，一直看一直看，盯到連目標都不好意思（>/////<）。讓團隊逐步前進，然後時常看看四周，有誰跟不上來，趕快想辦法處理，該去推，還是該去扶，真的跟不上，就請他離開，換到別的適合工作。當團隊發現，主導者非常篤定的朝向目標前進，大家自然就會有信心，全力將手中的工作完成，不需要用很強勢的專業去壓抑，就能讓團隊的表現更加顯眼。
                                                                               
現在，換了一個領域，我又更加深了解到，商業交易的流程中，專案開發也不過占了整體的一小部分，如果從產品交付的生命週期角度來看，我會把專案執行時間，評估為約30%左右，大部分視情況而定，有時候還會再少一點，也就是說，將產品交付到客戶手中，實際的開發時間，可能就只有幾個月而已，其他的時間，是用來做分析、規劃和打嘴泡。
                                                                               
過程中，我們指派專案經理要幹甚麼呢？來，可能大家忘記了，我們再來念一次：

「如期、如質、如預算」
                                                                               
很好，回家抄十遍，順便寫一篇心得報告，題目是，為什麼我們要從事這種狗屁倒灶的工作。
                                                                               
可見，專案經理的作用，就是為了要確保交出準時又符合品質的產品，最後送到客戶手上。那我們為什麼不直接告訴RD，要做哪些事，甚麼時候要做完，最後驗收結案就好了？套用一句D大大的名言，RD都是住在象牙塔裡，我補一句，一堆的宅男和宅女。由於我也宅了很久一段時間，因此我非常了解，除了用MSN、Facebook和朋友聊天、聯絡以外，RD平常很少有機會與其他人面對面溝通，更不用提直接和客戶碰頭，也就是說，外面發生地震、海嘯還是倒扁（馬？）遊行，都和我沒有關係，我的人生就是和電腦溝通（科科科～）。也因此，站在產品銷售的立場，我們需要一個在象牙塔外面的人，搞懂外面的狀況，幫忙這些宅人，統籌專案進度和處理工作的雜事，從一個更高層面的角度去關照，讓眾宅人不要走偏掉。
                                                                               
如果你比較喜歡"乾淨的"人生，只想要面對電腦就好，請回到象牙塔，繼續瀏覽線上漫畫，HunterxHunter總算開始連載了；如果覺得厭煩想不開，希望出來見識見識凡間俗事，體驗人性醜惡的一面，也歡迎加入專案經理的行列。
                                                                               
「我是程式設計高手，經驗非常豐富，管理這些小毛頭，簡直是蛋糕一盤」，剛從開發轉職過來的專案經理，常有這種不可一世的傲氣，心裡幻想著，憑藉個人高超武藝，一定能夠成就一翻豐功偉業，絕對不會像之前那個白目的專案經理，只會空口說白話，一點專業能力也沒有！不過，我看過太多這種類型的專案經理，下場都不太好，甚至比非科班出身的專案經理還糟糕，很多人最後又回去象牙塔了。因為他們忘記一件重要的事，專案經理必須要從象牙塔外面，照顧一群窩在象牙塔的工程師，齊力去完成一項艱鉅的任務。因為還是保持著「宅氣」，很容易忽略或輕視了各種危險跡象，橫衝直撞，因而讓專案進展延誤，不知道事情嚴重性就罷了，甚至還會理直氣壯的告訴老闆，根據「專業的判斷」，專案延誤是意料中的事情，老闆妳就認命吧。可想而知，除非老闆不敢動這些有恃無恐的大爺，不然一定很想大刀下去，砍死這些頑固份子。所以囉，諸君是不是我所描述的樣子，自己可以打量看看。
                                                                               
「我不是科班出身，也沒有寫過程式，可不可以當專案經理？」不用擔心，當然可以，只要你/妳是「帥哥、正妹」，身材姣好，口齒伶俐，就沒有問題了。雖然我很想說這只是個玩笑話，不過事實上還是滿適用的。因為如果不具備開發技術的背景，要和這堆宅人溝通，除非EQ夠高，脾氣夠好，不然保證會被氣到發昏，甚至七孔流血，然後跑到基隆港邊，握緊雙拳發出怒吼：
                                                                               
「吼～這些人是不懂社會現實嗎？」
                                                                               
「吼～他/她們是活在自己的想像空間嗎？」
                                                                               
既然各位誠心正意的發問了，告訴大家，猜對了沒錯，「喵～就是這樣」。
                                                                               
如果把RD當成電影雨人裡面的主角雷蒙，大家就不會感到訝異，RD通常具有高超的智力，不需要專案經理告訴他們，要怎麼工作，或是怎麼開發高效率的演算法，但是缺乏社會能力，又是工作狂的他們，像一群小旅鼠，需要被細心照顧，打點各種生活起居，才不會釀出大事情，造成可怕的災難。因此，當個不懂開發技術的專案經理，最好的做法，是利用俊俏或甜美的外型，經常沒事就走到RD的小隔間，和這些孤男寡女聊聊天：
                                                                               
「大葛格~大姊姊~，拜託一下啦，老闆說進度要快點，好不好嘛～啾咪」
                                                                               
告訴各位一個祕密，RD幾乎都是情感的弱者，利用溫情攻勢，保證無往不利，絕對可以讓專案經理勝任愉快，「升級當幹部，上任當部長」。

想更清楚知道怎麼和RD共處，可以參考這本書：「與天才團隊共舞：研發組織管理聖經」
                                                                               
再來，我們來看一個案子，這是從104網站，摘錄下來某Q公司的專案經理條件：
                                                                               
1. Project Manager
2. Management project _schedule/plan_ and _risk_ from project early stage (around kick-off) to RAMP (include mass production)
3. _Communication_ with customer teams, RD teams and production teams
4. EE Engineer background, need the schematic design, layout review and debug related Exp. and the _English_ conversation
                                                                               
雖然條件上很明顯要求要有EE背景，但從應徵分析的結果來看，企業管理和電子電機背景的人數差不了多少，各占了23% 和26%，畫底線的部分是我自己標注的重點，我不知道Q公司是不是大量錄用了企業管理背景的人，但我知道，Q公司重視英文，勝過於專業技能，這點與我個人的經驗雷同。不管是否具有開發背景，出任上面這個職缺的專案管理工作，只要能夠好好調整心態，積極學習，加強溝通能力，在整體效果上，我相信都能正確的完成任務，表現上也不會輸給具有專業背景的專案經理。
                                                                               
但究竟我們要的是一個可以解決專案開發的問題「超人」，還是一個可以確保專案正確進行的「經理」呢？我認為，要看專案的目標而定，指派專案經理的主管，真的需要好好想一下，倒底最需要的是哪一種類型，而不是為了想要節省成本，以為光暈效應很好用，隨便將開發高手拉上來，一邊管進度，一邊解問題，造成專案的問題沒人處理，管理狀況變成一團混亂。
                                                                               
如果採用了沒有專業背景的專案經理，搭配一個開發Leader就很重要，這樣一搭一唱，專案的方向，和專案的問題，就能夠同時解決，唯一的缺點是成本偏高。因此，剛畢業或者沒有開發經驗的專案經理，承接專案以後，最好能主動提出，或積極尋找搭配的高手，不然就是想辦法請主管拉攏超人當靠山，這樣就可以減少許多困難，老闆也會比較相信專案經理真的有在做事。同樣的，非本科系的畢業生，想要找到專案經理的工作，重點也是該如何說服老闆，除了基本的語言能力以外，溝通和觀察能力是特別的專長，如果在學校有完成專案的經驗，例如招集同學舉辦宿舍迎新活動，那加分就會更高了。
                                                                               
最後，不管專案經理懂不懂程式設計或開發技術，最終的目的還是在於提高溝通的效率，專業背景可以讓專案經理和RD更有話題，但並不能因此而去喧賓奪主，搶了開發工程師的工作，輕易跳過溝通過程的結果，不僅無法達到有效散播知識，反而讓大家更加無所適從。如果專案經理真的不懂技術，那溝通絕對是最重要的武器，善用各種技巧，強化原本需要專業技能才能達成的效果，例如抓緊時程、計畫和風險管理，利用直接或間接證據，讓開發團隊相信專案經理真的是有所本，目標導向，不是一個門外漢大外行，那才是專案管理真正會讓人心悅誠服的功效。
                                                                               
                                                                                                                                                             

利用市場定位創造出好產品

最近幾天，帶小孩去學校上課，在大門口，發現每個小朋友穿的都花花綠綠，雖然現在是寒冷冬天的季節，各種毛衣、外套的花色，竟然比春天花草還要多。

一時想到，「制服」這個我們六年級生的共同回憶，不知道什麼開始，就已經在周遭環境消失了，大概只剩下某些貴族私立學校，為了凸顯特色，而讓學生們穿著那種像哈利波特，高級的英式制服。我問我們家小孩的媽咪，這些制服都去哪裡了？媽咪說，很久以前學校就不讓小孩穿制服了，好像是因為教育部想要學習美式作風，從小凸顯每個小孩的個人特質，不要再像我們，每個人都理一樣頭髮，穿得一樣的衣服，讓小孩有自己的風格，培養不受束縛的創造能力。

雖然我不是學教育的，我倒是贊同這樣的做法，我們以前的年代，物資不是哪麼豐富，就算有天馬行空的創造力，實際上要製造出來，其實還有相當大的一段距離，因為資源和可用的工具遠遠不足，需要花很多的時間，將必要的材料找齊才有辦法開始。然而，現代社會資源充足，所得提高，平台、材料已經不是問題，然而，現代社會資源充足，所得提高，平台、材料已經不是問題，反而大量缺乏創造能力，幾乎可以說只要有構想，就能夠很快將成果創造出來。
因為幫小孩準備衣服很麻煩，老婆大人還是比較喜歡制服，但我認為培養差異性是有遠見的做法。

這倒是讓我想起了，產品市場區隔定位這件事的重要性。

很多從事產品開發的公司，經常會有一種幻想，希望能夠開發出一種萬物皆可用的商品，而且最好是能從消費者到企業用戶，全都能買單的萬能商品。不過現實的情況，不可能會有這種東西存在，因為針對某些族群，更能滿足特定需求的商品，總是存在市場上，當選擇夠多的時候，消費者當然會選擇CP值最高的，而不是一個什麼都會的商品。什麼對象都可以適用，這種想法，是非常危險的，尤其常出現在新產品發想的階段。更好的做法，應該是深入目標市場的客戶，發揮創意，因為以現今的技術，要製造任何東西都不是太大問題，因此，對產品開發公司來說，思考、創造，是更重要的事情。

產品沒有市場區隔會發生甚麼事？會造成很多問題，最大問題是應該是資源分散，讓事倍功半。拿釣魚當例子，拿一個小鉤子，坐上海釣船，就說要去釣黑鮪魚，不用想也知道會發生什麼事；反過來也一樣，要在溪流釣香魚，卻拿了標槍來，這要不是瘋子，就是來搞笑的。偏偏，我常發現，這麼顯而易見的事，經常發生在四周各種商品上面。而有更多人告訴我，用標槍偶爾也是射的到香魚，面對這種回答，我只能說：「God bless you!」。

既然大家都知道市場區隔很重要，那為什麼做不好？答案其實也很簡單，因為準確的區隔太困難，太窄或太廣都會造成問題。太過狹窄的市場區隔，例如像是：「使用手機傳送電子郵件的商務使用者」，就顯得太過聚集，這種產品往往變成只能適用在iPhone或者Android手機，導致市場縮小得太厲害，而無法創造高利潤。太過廣泛的區隔，則可能會變成：「發送電子郵件給其他人」，問題就會出現在，其他人是指一個人，還是一大群人，可想而知，產品面貌也會有完全不同的長相。非常Aggrasive的公司，就可能會這樣想，「我們要開發一種電子郵件發送的軟體，可以送給指定的一個人，也可以送給一大群人。」結果呢？幾乎可以想像，這種產品推出以後，不是客戶只用Outlook，就是被現有的廣告發送軟體打爆。

該怎麼做，才能找到適當的市場區隔，根據Marty Cagan一篇文章，提出的十個問題，可以做為我們的初步檢討清單。

Assessing Product Opportunities:

1. Exactly what problem will this solve? (value proposition)
2. For whom do we solve that problem? (target market)
3. How big is the opportunity? (market size)
4. What alternatives are out there? (competitive landscape)
5. Why are we best suited to pursue this? (our differentiator)
5. Why are we best suited to pursue this? (our differentiator)
6. Why now? (market window)
7. How will we get this product to market? (go-to-market strategy)
8. How will we measure success/make money from this product? (metrics/revenue strategy)
9. What factors are critical to success? (solution requirements)
10. Given the above, what’s the recommendation? (go or no-go)

1. Value Proposition
首先，要清楚定義我們解決客戶了什麼問題，我認為這是所有產品設計的起點，也是絕大多數人都不想碰的地方，當然，前面已經提過了，過小或過大的描述，會產生出不同種類的產品。由於定義問題的影響力非常大，也可以說，解決問題的能力是產品的價值所在。有趣的一件事，混淆的問題定義，經常會被老闆和主管所接受，為什麼呢？其實這是人性的問題，能不要負擔決策的責任，能閃就閃，不管是政府政策還是公司年度經營策略，總是可以發現這種現象。

但累的是誰？還不就是那些環繞在產品四周的職員，因為客戶對價值的評價不一，業務不知道該怎麼賣；產品規格變動快速，產品經理不知道哪些功能應該先做；規格不清，研發工程師不知道哪些功能應該加強。最後所有的結果，轉變成產品銷後績效，又落回到決策者身上。如此一來一回，浪費的時間，還不如拿來好好定義問題是什麼！

2. Target Market
其次，問題是為誰解決的，也就是所謂的目標客戶群，經常在設定目標客群時，常發生客戶認知錯誤的問題。什麼是認知錯誤，舉例來說，就是將使用者和消費者混淆了。當我們錯誤分辨不同的族群，會讓產品銷售模式發生問題。使用者是應用產品解決問題的人，而消費者是購買產品提供給使用者，有時候這兩類是屬於同一個人，但更多的時候，是分開的不同單位。例如IT部門購買電腦設備，提供給公司員工執行商用流程，那公司員工是使用者，而IT部門是消費者。

生產電腦的廠商該怎麼定義目標客戶群呢？如果同樣是生產品筆記型電腦，那消費型和商用型筆記型電腦又該有什麼差異呢？是該將使用者定義為目標客群，還是IT部門？可以想見，產品的長相就會完全不一樣了。其中一個答案是這樣，商用筆電是一種比較可靠、穩定的系列，
目的是讓IT部門能夠降低維護硬體故障的負擔，避免故障維修時間太久，影響了公司營運。
如果你是IT部門的成員，你會買哪一種產品？

3. Market Size
接著，我們要評估市場的規模有多大，這也是老闆們最關心的議題，不管是新創事業，或是產品經理，除了告訴創投公司或老闆能做什麼產品之外，還必須要說服金主，這個市場是很大的，就算現在不是很大，但是以後一定會走向主流，例如說電動車，客戶群有爆發性的成長。這時候我們可能會陷入二分法的陷阱，現有的市場很明確，規模和模式都已經底定了，可是競爭對手多，產品種類複雜，反而不容易進入市場；未來潛力性的市場模糊不清，客戶群也還沒確定，要明確界定出可能的銷售金額，可以說是不可能的事情。因此，預估產品市場規模是一門藝術，如何在可信度和未來性之間，取得一個平衡點，是從事產品開發的公司，必須不斷進行修正的工作。

4. Competitive Landscape
許多人有寫論文的經驗，準備的工作，總是要找來一大堆的背景資料，漏了幾個重要的角色，教授還會K你個半死，因此詳細了解競爭對手，包括現有的商品，潛在的替代方案，以及客戶如何評估廠商產品，是產品開發中的基本。不過，這件事情其實遠比想像中還要困難，可能我們會知道，或已經知道，目前市面上有多少的商品，但玲瑯滿目的種類，以及不同針對性的功能，並沒有辦法讓我們很確定，真正的競爭對手是誰。更多的情況是，害怕競爭的心態。

我看過許多老闆，一聽到市場上已經有其他競爭者存在，就嚇得趕忙放棄手中的開發案，寧願選擇其他方式進入市場，好聽一點叫做「藍海市場」。差異化是對的，但為了逃避競爭而差異化，絕對不是一件好事情。

5. Our Differentiator
第五個評估是我們怎麼說服顧客，我們是不同的。透過有名的電梯模式，產品負責人應該要有辦法，在電梯從一層樓上升到第十層這麼短的時間，告訴你的客戶，或是你的老闆，產品有什麼不同。和其他產品的差異，也就是產品的競爭力，決定了客戶怎麼看待產品，以及對產品有什麼新期望。就像前面說的，市面上的商品種類太多了，隨便就能找來一大堆可以解決問題的東西，一個新商品出現在眼前，平均只有30秒，客戶就要決定這個商品能夠用來解決什麼問題。

最有名的大概就是這句：「30分鐘，不然免費」，應該所有人都聽過這句外送披薩的著名口號吧，這句話解決了甚麼問題？有沒有人知道？對～肚子餓的問題，如果你現在餓了，有很多選擇，可以花一小時到外面出，也可以花兩小時自己在家煮，不過如果有人告訴你，只要30分鐘，就幫你送到家，而且還是熱騰騰，你心不心動？更好的是，沒有在時間內送到，還是免費的！這真是太棒了！事實上，披薩還是披薩，並沒有改變，但在短短的幾秒內，就讓客戶清楚了解，這個產品的差異性了。

順帶一提，因為趕著送披薩而造成的交通意外，讓這句口號提早結束了。

6. Market Window
第六，為什麼是現在？這個問題顯現出許多太早進入市場的產品，共有的經驗和所面對的問題。例如現在已經很熱門的電子書。我想有許多前輩應該有印象，倉頡輸入法的作者，朱邦復先生，早些先年就已經開發過電子書了，當時的產品應該是電子書包吧，就現在來看，一點也不遜色，甚至中文的支援性，還遠遠高過目前的商品。但是並沒有很成功，這是大家知道的故事，為什麼沒有辦法造成流行？時間還沒到，是大多數人的評論。就我的看法，我認為是商業模式還沒有出現，是主要的關鍵點。電子書最重要的使用過程之一，是透過網路下載書籍，
在當時，網路才剛開始，還談不上應用，更不可能有人能夠接受網路下載電子書籍的做法，因此，閱讀器也許是完成了，但是電子書籍的流通平台還沒跟上來。因此，我們在評估產品的時候，也必須要再想一想，產品適合現在出現嗎？環境成熟了嗎？客戶能夠接受嗎？如果這些都沒有問題，就可以看第七項。

7. Go-to-market Strategy
再來，我們要評估，將產品送到客戶手中的通路，是否已經掌握住了。許多因為通路不良，而造成產品失敗的例子，屢見不鮮。可能會有人覺得，只要客戶覺得產品很好，很合用，打個電話，下個訂單，就可以拿到手了。實際上，沒有那麼容易，大多數的問題，就出在產品公司有沒有考慮過「經銷商」的需求。特別是新創公司，很直覺就會把經銷商給忘了，造成當需要經銷商拓展業務的時候，不管是在利潤分配，還是經銷說明文件，極度的缺乏，套一句好友的話：「這些人連怎麼死的都不曉得。」有些經銷體系，由來久遠，甚至有所謂通路為王的現像，這已經不是一個產品很好，就能夠出現在消費者眼前的環境了，如何打通經銷商這個環節，有時甚至比產品本身更重要。

想一想，我們負責新飲料的開發，該怎麼讓新的茶飲料，取代純喫茶出現在7-11的飲料貨架上？

8. Metrics/Revenue Strategy
還有一項評估是大多數人會忽略的，但是非常重要，那就是知不知道，產品怎麼做才算是成功。大家都愛成功，喜歡當勝利團隊的一員，不過「成功」這個定義不太好解釋，可能是只要賣給第一個客戶，就算是成功了，許多新產品是這樣定義的；也可能是搶占市場的佔有率，達到10%以上，或者要超過損益平衡點，才算成功。成功的意義來自於產品的成本投入，以及市場的接受程度。普遍來說，成為市場區隔中的第一名，是大部分成功的標準定義，但如果將目標訂太高，很可能會讓團隊自信心受創，造成永遠達不到成功境界的錯覺。比較適合的方式，是訂一個需要相當努力才能達到的目標，然後讓團隊成員知道，只要大家齊心，目標就能達成。

9. Solution Requirements
第九項比較是偏向產品的功能面，就是要評估產品是不是需要某些特定的功能。舉個例來說，手機要能夠打電話，因為通話的功能，就是必要性，不然就會變成PDA了，市場也就走偏掉。我們提出來的產品是不是滿足了這些基本的需求，也就是大家常說的Must-to-have功能，說來有點Tricky，很多產品的功能，可能連Must都沒有，就要推出市場了，會造成這樣的現象，可能要歸咎於產品規格沒有針對目標客群，為了解決太多客戶，而什麼功能都加上去，結果對真正的客戶來說，實際必要的功能，反而沒有出現，難怪許多Sales會抓狂：「這叫我怎麼賣？」

10. Go or No-go
最後，經過上面九個分析評估之後，在我們向老闆或金主報告之前，我們要先問自己，這個產品，可能成功嗎？行得通嗎？我們願意為了這個商品，投入寶貴的資金，自己和團隊的青春，
就為了看到產品最終成功。如果答案是肯定的，那當別人問起，為什麼要開發這個產品，我們就可以很有自信的告訴對方，為什麼要這麼做，以及成功的甜美果實會長得如何。因此，不要試圖為了完成工作而去欺騙自己，給自己一個肯定的回答，做起事來才會更有成效。

做完了十項基本的產品評估，是不是產品就保證一定能夠成功，當然不是，因為市場的變化非常快速，客戶的需求也跟著改變，可能上個禮拜的評估，到了下個星期，就失去大部份的可信度了，因此產品開發公司，必須隨時觀察市場和調整步調。開發一個產品的理由可能有很多種，但是成功的意義只有一種，那就是讓客戶覺得我們的產品是有幫助的。

我認為從客戶的商業面思考是更有效的做法，想像我們是目標客戶群的完美合作夥伴，我們的任務是讓夥伴能夠成功，但我們不了解夥伴怎麼營運他們的公司，從事哪種商業行為，那我們怎麼提供好的服務，讓客戶能夠能成功呢？理想的狀況是，公司有原本是目標客戶群的員工，如果沒有，也要想辦法透過關係，獲得這些資訊，深入了解目標客戶的需求，透過熟悉運作流程，加強產品的功效，讓目標客戶更相信使用產品能獲得好處，那麼，產品開發也就成功了。

譯：推倒高牆

Knocking Down Walls 
Marty Cagan 
February 9, 2010 
翻譯：Tony Lu
 
創業中有一件很棒的事情，那就是公司非常的小，幾乎沒有組織結構可言。基本上每個人只是希望做出人們真正想要的東西。

但隨著組織的成長，人們開始花更多的時間和過程管理所有的人，而不是創造，很快的就開始進入典型功能型專業組織，例如技術，產品和營銷部門。

不幸的是，這種組織的後果，經常讓這些群體產生出高牆般的壁壘。人們往往覺得比起實際產品開發團隊，自己的部門更具有緊密的親和力。只要看看一起去吃午飯那群人，或誰在討論下班以後去哪裡喝啤酒，就很清楚了。如果產品經理通常與其他產品經理混在一起，那就是另一 個牆壁出現的訊號。

當產品經理和開發人員沒有在同一艘船上，或者他們不明白對方在想什麼，這又是另一個牆壁的訊號。

我喜歡Scrum(譯著：一種軟體工程方法)的一件事是，它打破相當多的牆。但即使是一個標準Scrum團隊，有時後產品經理不是實際的產品擁有者，或者他可能只是在技術上是產品擁有 者，但他並不是真正與他的團隊一起共事。

還有其他的牆，例如產品和營銷之間，或產品和用戶體驗之間，但最糟糕的牆，我會說是產品和技術之間。開發團隊和產品經理沒有一個有效的工作關係，幾乎是不可能完成什麼好東西。

對我來說，一個有效率的工作團隊是基於個人之間的關係所促成。

產品發現是一個真正的產品合作例子，整合用戶體驗和技術，真正的合作成功，取決於這些關係。
 
只是簡單的讓產品經理和開發人員坐在一起，就可以產生巨大的影響力。不久，他們就會開始共進午餐， 一起玩桌上足球，最後一起分享觀點。

我先前有寫過，開發團隊開發出軟體，產品經理也不過只獲得一半實際的價值。如果你想達到那個另一 半，就必須開始建立這種人際關係。 

如何讓設計開發更加貼進顧客需求

有人反應，希望能多看到一些有關專案管理的文章。
                                                                               
這個嘛，小弟管專案大概四、五年經驗，要說熟練或者精通，恐怕言過其實，剛好曾經讀過一些文章，談的是專案管理（Project Management）和品質機能展開（QFD），雖然有點冷門，如果大夥不怕被寒流來襲冷到，就且聽小弟一點經驗談，當作小品故事，權作經驗分享。
                                                                               
---
                                                                               
專案Review會議，專案經理Eson、設計部門主管Will和產品經理Mendy一起討論產品品質的問題。
                                                                               
產品經理Mendy：「不是我在說，我們產品部門辛辛苦苦將客戶需求找出來，功能規格也訂出來了，怎麼回事，做出來的東西，功能還是輸給其他同業，完全沒有高品質的樣子，這種東西，客戶能接受嗎？」
                                                                               
專案經理Eson：「你怎麼這樣說，功能規格也只是說需求是什麼，實際上要怎麼做，也沒有說清楚啊～況且我們在時間截止就完成了，也沒有延誤到。」
                                                                               
設計部門主管Will：「就是說啊，我們的人，可是每一樣功能都做出來了，完全符合產品開出來的規格，沒有漏到哪一項，客戶不能接受，跟我們有什麼關係，如果說功能有Bug，當然是我們的問題，但是功能沒有任何問題，客戶不接受，當然就是規格有問題。」
                                                                               
產品經理Mendy：「這還需要我們說嗎？功能就算做出來了，和客戶的需求還差那麼多，反應速度和方便性都不如競爭對手，這樣的產品怎麼賣？能說我們做出高品質的產品嗎？」
                                                                               
設計部門主管Will：「那就是產品開的規格，沒有足夠明確的說明，當初產品只有說要盡快開發出來，可沒有說倒底要哪一種品質，是要比同業快，還是要更容易使用，現在做出來，才說不符合品質要求，這太過分了吧！」
                                                                               
一陣鬧哄哄的會議，在沒有共識的情況下，草草的結束了。產品經理Mendy向Boss反應狀況以後，Boss非常困擾，又找來Conic，討論專案開發的品質問題。

Boss：「唉，Conic，我知道你很久不接專案了，不過你有經驗，這種事該怎麼處理比較好？」
                                                                               
Conic：「嗯～這是『專案品質認知落差』，算是老掉牙的問題了，不過總是會不斷的發生。」
                                                                               
Boss：「其實我也知道，專案經理非常努力了，在這麼趕的壓力，總算是在Deadline前完成，只是品質不如預期，推出市場也只是被打槍的份，這該怎麼和大老闆交代呢？」
                                                                               
Conic：「在專案啟動（Initiating）和規劃（Planing）時期，有沒有做過品質機能展開呢？」
                                                                               
Boss：「品質機能什麼的，那是甚麼東西？」
                                                                               
Conic：「品質機能展開，指的是將客戶的需求，轉換成開發技術需求的一種專案發展工具。」
                                                                               
Boss：「竟然有這種東西，我怎麼都不曉得？真有那麼神奇？」
                                                                               
Conic：「其實也沒那麼神奇啦，只是一種工具，通常我們會用『品質屋[1][2]』規劃出客戶的需求，和技術開發的關聯性，然後給予權重以及評估，用來讓專案經理和開發部門更加清楚了解，客戶需求的來龍去脈。」
                                                                               
Boss：「品質屋？那又是什麼？」
                                                                               
Conic：「所謂的品質屋其實是一種表格，經過設計，可以用圖像表達的方式，一眼看出顧客需求和技術需求之間的關係。」
                                                                               
Conic：「您稍等一下，我上網列印一張範本給您看。」
                                                                               
Conic：「報告Boss，這就是品質屋的範本」
                                                                               
Boss：「這個表格還真有趣，確實長得有點像是個屋子。」
                                                                               
Conic：「是啊，這個屋子裡面，主要有六個項目，按照順序分別是(1)客戶需求、(2)需求評估、(3)技術需求、(4)關係矩陣、(5)技術需求關連矩陣以及(6)技術目標。」
                                                                               
Boss：「這六個項目是怎樣讓客戶需求和技術需求產生關聯呢？」
                                                                               
Conic：「是，很簡單，只要按照(1)到(6)的順序，走訪一次就行了，但是思考的範圍要盡量全面性。」
                                                                               
Conic：「我舉個例子，(1)客戶需求就是產品部門訪談客戶之後，認為客戶所需要的功能，也許有幾十項，經過分門別類以後，整理下來，例如針對效能的需求，可能就會有一項需求是反應速度要在50ms完成。」
                                                                               
Conic：「接著是(2)需求評估，也就是對客戶需求內容的分析，有些需求其實沒有必要理會，而有些是非常重要的，在這邊可以用分數寫出來。」
                                                                               
Conic：「(3)技術需求就是我們能夠提供的各種技術方法，例如針對效能部分，可以提供快取功能，用來加速反應，當然還有其它的技術方法可供參考。」
                                                                               
Conic：「第(4)關係矩陣就很重要了，這個地方要寫下，客戶需求和技術需求的關係，例如是非常相關，還是一點都沒有關係，有些是強相關，而有些是弱相關，這裡就可以讓我們決定，我們提出的技術需求，是不是都有滿足客戶需求，或者是在做白工。」
                                                                               
Conic：「然後是(5)技術需求關聯矩陣，技術本身可能存在矛盾現象，例如要加速，但是會造成運算負擔加重，這樣會和降低運算的技術需求衝突，我們就寫在屋頂，用一個減號表示，到時候開發部門就會注意到這個問題。」
                                                                               
Conic：「最後是(6)技術目標，是將前面的分析，加總之後的結果，用來找出最重要的幾個需求，顯示出要讓客戶滿意，應該先完成的項目，同時，我們可以和競爭對手比較，看看是不是具有競爭力，如果需求的優先權很高，但是我們的功能卻遠低於對手，那就必須趕快提醒設計部門，應該要加強這些功能的改善，讓客戶獲得最大的滿意。」
                                                                               
Boss：「哇～這看起來還滿複雜的，不過你這樣講解以後，我可以理解，確實可以從一張圖表中，就發現產品應該發展的目標，和該注意的地方，而且要解釋給設計開發部門也相對容易得多。」
                                                                               
Conic：「是，這就是品質機能展開最主要的目的。」
                                                                               
Boss：「那只要在專案初始的時候完成就行了嗎？」
                                                                               
Conic：「當然不是，品質這種事，是隨著專案的發展，必須不斷的進行監控（Monitoring），然後適當的調整。」
                                                                               
Boss：「所以，在EVT（Engineering Verification Test）的時候也要檢查一次的意思嗎？」
                                                                               
Conic：「不只是EVT，最好在DVT（Design Verification Test）也檢查，確保開發出來的產品，有按照品質規劃在走，才不會大家辛苦一場，結果只是做白工，最後還賣不出去。」
                                                                               
Boss：「你這樣說也有道理，我這就叫產品和專案經理試著做一份品質機能展開，讓他們好好有個共識，再趕快將品質調整回來。」

---
                                                                               
我們真的瞭解顧客的需求嗎？不只是專案經理或設計部門的問題，有時候就連產品部門都沒辦法很明確定義，一樣的客戶需求，可能會有幾十種不同實做的方法，哪一種方法稱得上是高品質，其實是很難界定的，市場面上就已經很難決定了，更何況實際施工的專案團隊，要弄清楚品質目標，更是不容易。
                                                                               
品質機能展開是專案管理工具的應用，這類型的工具還有很多，像是Triz或是DOE等，都是有助於專案管理開發的有用工具。但工具畢竟只是輔助的道具，重點還是專案管理的主事者有沒有用心在經營，尤其成功專案的定義，仍在「如期、如質、如成本」這三角打轉，即使專案努力趕工在時間內完成，但做出一個品質讓客戶無法接受的成果，這個專案仍然是失敗的。
                                                                               
因為先天上，客戶和開發部門本來就是講著兩種不同的語言，除非必要，老死不相往來。客戶說的，通常是很功能性的，模糊不清，而且灰色地帶很多；而開發部門講究精確，凡事都要可以衡量，死板板硬梆梆。沒有誰對誰錯的問題，卡在中間的產品和專案經理，就必須負擔起溝通的責任，讓大家能在相同的共識下通力合作，利用工具可以讓生活好過一些，至於什麼時候該用，該怎麼用，沒有一定的答案，只能說是「存乎一心」而已。
                                                                               
                                                                               
                                                                               
                                                                               
Reference:
[1] 品質機能展開（QFD）與品質屋（HOQ）.
[2] Quality function deployment.
                                                                                                                                                               

讀書心得：如何成為問題解決型領導者

領導的技術：如何成為問題解決型領導者

傑拉爾德．溫伯格
出版社：經濟新潮社








這篇是幾年前寫過的讀書心得，經過了這些年的歷練，對於專業型領導者的這個議題，我又有了新的體會，將這篇文章重新調整過，更新發布。

領導能力是不是與生俱來，是許多剛升任領導職務的專業人，內心中的疑惑，本書提到，領導就像性一樣，面對這類議題，許多人都不願意正視它，甚至覺得難以啟齒，以為領導是與生俱來的能力，求助於他人是一件很丟臉的事。事實上，領導是可以經由學習習得的。

"領導的技術"分析了不同的領導風格，但將重點放在「問題解決型」領導風格，因為它是成功領導者最常採用的。這類領導者有一非常獨特的共同點，亦即，他們都兼具三個特定領域的技能：「創新」、「動機」及「組織」。

依據本書的建議，分析自己在此三個領域的領導現狀，並採用一些實用步驟改善缺失，幫助此三項技能發展得更成熟。書中，溫伯格提出不少關於領導的智慧箴言，搭配故事性的引導，使人反省、思考再三，且獲益良多。
例如：　　
1. 領導者的工作對象就是人。除了人以外，領導者並無其他工作。　　
2. 領導是一種環境塑造的過程，在此一新環境中，人們覺得自己獲得充分授權。

傑拉爾德．溫伯格的系列書籍，包含大家耳熟能詳的軟體管理學，從事專案管理或系統分析工作的人，都應該買來看看。"Becoming a Technical Leader" 的英文版，我在很早以前就已經讀過了，不過受限於英文能力，無法很確實了解書中的內涵，知道由經濟新潮社翻譯成中文，很快的就買回來，囫圇吞棗以後，對於身為技術型領導者的困難以及有趣的地方，有更一層的體會。

溫伯格以MOI的主體貫穿全 書，所謂的MOI即是動機（Motivation）、組織（Organization）以及創意（Ideas or Innovation）。剛開始，溫伯格以一個電腦程式設計小組為例子，說明傳統領導觀念的模型，以及說明在有效影響力行動的觀察，並不能代表團隊中領導者真正的作用，解釋世界上還有其他的模型，可以表達不同的領導者在系統化思考中，如何接觸數百種可能的因素而達成有機模型的概念，這種以人為本的解釋，在許多專案領導的書籍中屢見不顯，但是溫伯格以"程序"為領導對象，來闡明領導者應該允許人們能夠做選擇，因而激勵隱藏在人們內在的潛能。

許多剛由技術職位轉任管理職的專案領導者，在領導能力上經常不足，甚至要花很多時間，才感覺到自己才從事領導工作，因為自尊心作祟，不敢請教其他人或尋求上課機會，甚至連提都不敢提，以為領導能力應該是自己本身的一種能力，帶領團隊的效果不佳， 一定是自己能力不足，造成對於自信心的懷疑，結果更加綁手綁腳，因此陷入惡性循環。

溫伯格認為，沒有人天生就具有領導能力，領導能力需要依靠環境跟學習而 來，尤其在領導者的養成，溫伯格以彈珠台遊戲作為例子，當得分到達一個階段，單純只靠努力的練習，沒有辦法讓得分進入另一個高分階段，要能跳階到另一個高點，遊戲者必須仔細觀察遊戲的規則，尋找得高分的訣竅，勇敢的嘗試不同的方法，或許剛開始會讓得分降低，但是只要方法得宜再加上多次練習，遊戲者往往能夠在不知不覺中將得分提高，並且開始邁入新的得分高點。

另一種專案經理職所擔憂的問題，是原本的技術能力因為領導管理的工作而大幅下滑，甚至害怕失去原有優勢，誠如書中溫伯格說道，向上攀爬需要很大的勁，但要狠下心腸，一個人才能做出放棄攀爬的決定。專案經理必須要能從原本的超級明星變成眾多領域的專精通才，才能夠與不同領域的專家對話，學會如何輕易發現真偽，從中尋找出可能發展的潛力方法或機會，專案經理要能認知技術能力只能對工作有所幫助，但是領導能力則能讓組織邁向提升與大幅獲利，溫伯格認為這是非做不可的取捨決定，也許是技術明星一生中最難做的抉擇。

回到原點，產品開發的本質在於解決客戶問題

新產品開發不是件容易、簡單的事情，未必是技術有多麼困難，亦或者需要花費多少成本，而是該如何判斷最適合的方法，該採用哪種策略。也因此，許多新產品開發案，都是工程師自己先做出了一些東西，再由產品行銷部門，想辦法找到可能的客戶，然後經過幾輪的修改，變成能夠帶來利潤的商品。這種時候，伯樂就很重要，有時候只是老闆的一句話，就可能讓產品翻案，一旦成功了，就是老闆的決策英明，就算失敗，也不過和其他產品的下場相同而已，隨身聽（Walkman）就是在這樣的環境中誕生的。
                                                                               
然而，還有一種情況是我們常見的，就是先有構想，再來找產品。最常發生在大老闆去參加了某個研討會，突然有了個靈感，然後要產品部門想出可行產品的樣貌，在這種含糊不清的情況下，產品部門該怎麼規畫出適合的提案，成為許多公司面臨的挑戰。幾乎所有的教科書都會這麼說，仔細思考客戶的需求，再分析出可行的方案。其實就是「原點」思考法，剛好今天是2010年的第一天，非常適合這個主題，我們就以「原點」來討論，怎麼從「概念」變成初步可以達成「共識」的產品提案。
                                                                               
在有著豪華裝潢，三面採光，景觀遼闊的氣派辦公室，大老闆和Boss正在討論年度產品計畫。
                                                                               
大老闆：「上次我去參加那個雲X研討會，我覺得雲X絕對是個趨勢，公司的產品不管是商品還是行銷，都要跟上這個潮流！」
                                                                               
Boss：「報告大老闆，雲X只是個行銷口號而已，實際上我們要做的也不多，頂多就改改文宣就可以了。」
                                                                               
大老闆：「這你就不對了，雲X是個趨勢，所有的大公司都在看，如果我們也有雲X的產品，客戶就會認為我們和大公司的路線一致，也比較會相信我們是走在時代的先驅。」
                                                                               
Boss：「(OS:唉～)那請問大老闆，雲X的分類很多，我們該走哪一種？」
                                                                               
大老闆：「我怎麼會知道，所以才要你們產品部門去想一想啊，你們要根據產業的特性，其他競爭對手的動向，以及大公司的路線，再參考公司的研發和銷售能力，提出一個最能讓公司獲利，又可以在最短時間達成的提案！」

Boss：「(OS:唉、唉、唉～)可是我們手邊也沒有甚麼資料，該怎麼開始呢？」
                                                                               
大老闆：「最近很多單位都會開研討會啊，看那是工X院還是IXC或是MXC產業分析，你們就去多看看吧。」
                                                                               
Boss：「(OS:ㄟ～最好是這樣)是，那我們先去調查看看，甚麼時候要有結果呢？」
                                                                               
大老闆：「當然是越快越好啊！離年底還有一個月，在年底前一定要搞定，明年開案，我才好和董事會說。」
                                                                               
回到辦公室，沒有採光，只有一堆隔間組成的普通辦公區。Boss和Conic找了一間比較小的會議室，討論大老闆天行空的想法。
                                                                               
Boss：「大致上，我說的就是大老闆目前的想法，Conic，你有沒有甚麼好的Idea？」
                                                                               
Conic：「嗯～這確實很棘手，一來我們現有的產品，要掛上雲X的字眼，本來就已經很牽強了，這下子還要生出一個完全符合雲X概念的商品。」
                                                                               
Boss：「就是說啊，大老闆也未免太強人所難了吧，而且還要列入明年產品開發的主軸。」
                                                                               
Conic：「也沒辦法，總是要做出點東西來，光抱怨也是沒用的。」

Boss：「那你說該怎麼開始比較好？」
                                                                               
Conic：「總之，先要定義雲X在產業的有哪些種類，再看看我們目前的定位，連參加研討會，這大概要一個星期的時間，我先整理，到時候我們再討論吧。」
                                                                               
過了一個星期，Boss找來Conic繼續討論產品提案。
                                                                               
Boss：「研討會我們參加了幾場，也找了一些顧問聊過了，現在有結論了嗎？」
                                                                               
Conic：「大體上有結論了，我和一些資深同仁討論過，看來我們的定位應該是在XaaS，我列了幾種可能的技術，Boss您先看看。」
                                                                               
Boss：「我也是這麼覺得，看來我們有基本的共識了，這幾種技術方案好像都不錯，我先和大老闆談談看。」
                                                                               
過了幾天。
                                                                               
Boss：「Conic，大老闆不太滿意我們提的這幾種方案耶。」
                                                                               
Conic：「呃～為什麼呢？」

Boss：「他認為這幾種方案都沒有辦法完全解決客戶的問題。」
                                                                               
Conic：「那是當然的啊，哪有一種方案完美無缺的，可以一次解決全天下所有的問題。」
                                                                               
Boss：「這我知道，但是他就是這樣認為啊，我也告訴大老闆了，請他選一個他認為最適合的方向，我們再深入研究和分析市場的情報。」
                                                                               
Conic：「那大老闆怎麼說呢？」
                                                                               
Boss：「唉～他說提出一個最適合的方案是我們的責任，他覺得滿意，就會告訴我們。」
                                                                               
Conic：「這...顯然我們有很大的代溝呢，總之我們先想辦法多做點客戶訪談，以及尋求一些專業人士的建議吧。」
                                                                               
Boss：「也只好如此，我們分頭進行吧。」
                                                                               
又過了幾天。
                                                                               
Boss：「這是我想辦法和朋友聯絡到的內容，我問了他們有關這類型產品的用途，還有一些常見的想法。」
                                                                               
Conic：「我也有一些，包含我們的客戶和公司內員工的意見。」
                                                                               
Conic：「結果，可能的方案又多了一些，大概已經有幾十種可能性了。」
                                                                               
Boss：「可是我們還是沒辦法決定，是吧？」
                                                                               
Conic：「是啊，可行的技術和方法，顯然是太多了，似乎已經有點失控的感覺，不過這些資料應該足夠和其他部門的同事做些討論，找出更可行的方法吧。」
                                                                               
Boss：「至少我們的圖表和內容還滿豐富的，發給大家，請大家一起幫忙想想看吧。」
                                                                               
又經過一個星期。
                                                                               
Boss：「Conic，我們只剩一個星期了，可是不但結果還沒產生，反而又多了更多的可能方案。」
                                                                               
Conic：「怎麼會這樣呢？」
                                                                               
Boss：「每當一個新方案解決了一個問題以後，就會有人提出，這個方案無法解決另一個問題，因此不斷的在這個討論循環中來回，最後變成大家都沒有更好的想法了。」
                                                                               
Conic：「我們還需要訪談更多的用戶嗎？」

Boss：「我認為應該不用了，這些訪談內容也夠多，我們該了解的也差不了多少。」
                                                                               
Conic：「那我們究竟出了甚麼問題，導致無法擬定一個方案呢？」
                                                                               
Boss：「我想過所有的可能性了，但總是欠缺一些東西。」
                                                                               
Conic：「顯然我們需要更好的靈感了。」
                                                                               
最後一個星期。
                                                                               
Conic：「Boss，我終於知道問題在哪了！」
                                                                               
Boss：「咦？真的嗎？是什麼？」
                                                                               
Conic：「不要急，聽我慢慢說。」
                                                                               
Conic：「其實很簡單，我仔細思考了一下，在那麼多方案中，沒有一個方案能解決所有的問題。但是，再深入考慮一下，『所有的問題』指的是什麼，這個部分，我們沒有具體的答案。」
                                                                               
Boss：「這我知道啊，就是我們要解決客戶什麼問題都沒有確定下來。」

Conic：「啊哈！這就是問題點，我們在還沒有確定要解決客戶什麼問題，就開始下解決方案，當然就是各說各話，即便有再多的專家學者、資深人士，一點都幫不上忙，因為每個人解決的，都是不同問題。」
                                                                               
Boss：「嗯～你這麼一說，確實是這個樣子，那你知道我們要解決什麼問題了嗎？」
                                                                               
Conic：「我也沒辦法決定，所以我們必須忘掉技術層面，將重點放到原點，也就是客戶的問題是什麼，我將和客戶訪談的資料，歸納之後，列出了這幾條客戶普遍的需求和問題。」
                                                                               
Boss：「我看看，嗯，其實這些都是我們常見到，也常聽到客戶反應的問題，但是我們並沒有針對這些問題討論實際的方案。」
                                                                               
Conic：「是的，如果可以先從這幾點需求開始，先確定我們可以和想要解決的問題，那麼技術和方法，也不過就是評估過程的產物。」
                                                                               
Boss：「好，我知道了，我馬上和大老闆討論，並決定最適合的切入點。」
                                                                               
最後幾天前。
                                                                               
Boss：「Conic，大老闆確定我們應該解決哪種客戶問題了，那就是XXX的問題，他非常有興趣，我也和研發部門主管談過，幾個解決方案他們的把握度還滿高的。」
                                                                               
Conic：「那太好了！事情應該解決了吧？」
                                                                               
Boss：「還沒，我們還需要將雲X的觀念加入客戶問題的解決方案中。」
                                                                               
Conic：「這個容易，因為我們想要解決的客戶XXX問題，其實是屬於雲X裡面OOO的層面，我們只要將OOO的技術引入開發環節，並且對外宣稱我們開發的是OOO架構，這樣就行了。」
                                                                               
Boss：「嗯～雖然感覺還是很牽強，不過至少邏輯是對的，也很難挑毛病，我這就和大老闆報告。」
                                                                               
最後一天。
                                                                               
Boss：「Conic，這件事搞定了，我們的提案，大老闆和董事會都很滿意。」
                                                                               
Conic：「真的嗎？總算是結束了。」
                                                                               
Boss：「並沒有喔，接下來我們要開始真正的規劃，產品具體的規格了，明年應該是非常忙碌的一年。」
                                                                               
Boss：「別抱怨了，總比沒頭沒腦亂做來的強吧。」
                                                                               
                                                                               
                                                                               
                                                                               
後記：
這篇算是總結小弟的年度工作記事，僅供參考，祝大家新春順利！
Happy New Year!