最令PM扼腕的事情就是，明明已經知道市場的機會就在眼前，好不容易在會議中做了新產品構想完整簡報，結果被同事和上司做了以下無情的批評：
- 認為市場規模預估模型有缺點，對於新產品的未來太樂觀。
- 認為很多時候產品要放到市場上才見真章，焦點團體或問卷調查只在封閉環境內測試，外部效度不夠。
- 舉市場現有類似設計的產品做為反例，來佐證這樣的產品不會大賣。
- 上司以自身過往類似驗來作為反駁，說明新產品並不會有市場。
- 專注於找出新產品的缺點和問題，但是給的支持卻很少。
參加使用者訪談研究紀錄
筆者參加了手機廠商的使用者訪談研究，有幾個點值得memo一下。
- 一開始主持人會問一些問題測驗程度，也會拿手機給我玩一下，並叫我開機和找撥電話…等基本功能。
- 主持人會問我觸覺、視覺、重量、外型、拿起來的感覺…等，也會拿出一堆手機問我比較喜歡哪一種，和選擇的理由。
易用性演講摘要part II, 透過焦點團體法改善網站易用性
本篇接續上篇，為蔡志浩老師演講的摘要，這次寫的是關於如何透過焦點團體法改善網路服務的易用性。
相對於一般實體產品，網路服務更注重易用性，其理由如下：
- 對網路服務來說，消費者在決定購買前，就會先經驗到其易用性，但是實體產品是在購買後，我們才會經驗到其易用性。
- 消費者在第一次接觸網路服務之前，未必知道其實際的服務內容，但是實體產品在初次使用前，通常消費者已經知道其功能為何。
- 對大部分網路服務來說，消費者的學習動機都較弱，若是網路服務難以學習，消費者也通常不會有耐心繼續使用。
- 功能特定的實體產品，介面相對於網路服務簡單許多，而網路服務所在的Web平台，並沒有一套如Windows的標準使用介面可以遵循。
易用性演講摘要與心得 part I — 衡量易用性的指標
Usability Study該怎麼選擇受測者
關於usability study來說，選擇參與者一向都是非常重要的課題，而從Measuring the User Experience這本書內容來看，筆者摘要如下：
※為usability study選擇參與者要考慮的條件是什麼？
閱讀全文
給PM的寓言漫畫
凡事一定有更好的方法，絕對沒有二選一，而是有更棒的更創新的第三條路，與大家共勉之。
閱讀全文
專案外包的衝突與兩難–delay的成因
這次我們來談談delay。
delay對專案來說，是件非常容易發生的事情，就算是經驗豐富的專案經理與專案團隊，還是很難避免delay的命運。可是當我們參閱許多專案管理的書籍，確實有許多關於專案時程控管的知識，諸如：甘特圖、WBS、PERT、Critical path…等，但卻很少提及應該如何面對delay，又該如何處理delay，這方面的課題確實為一般專案管理書籍所忽略。
電視廣告memo-La new篇
La new之前的電視廣告很有意思，它雖然都是廣告護士鞋或教師鞋，筆者雖然不是護士也不是老師，但是就是對La new留下「這品牌鞋子很像舒適」的感覺。
廣告對PM來說是個很有意思的效法對像，因為PM在設計產品的時候，都會落落長的寫一個power point，來敘述產品的賣點和特色。殊不知當PM開始與通路和業務甚至是消費者溝通的時候，PM準備的溝通素材越多，就會越沒有效果，除了沒有耐心記住這麼多賣點之外，對於產品訊息的傳播，也會有很大的阻礙。
能產生共鳴的廣告範例
一直以來，產品經理在產品上市之際，有一個很重要的任務就是，用行銷訊息使得消費者產生共鳴。注意喔，是要有共鳴，而不單單只把產品的訴求點傳遞出去而已。
最近筆者看了一些廣告有些感觸，同樣都是訴求話費便宜相關的訴求，不同的廠商之間的表達方式差異。以往筆者在擔任PM的時候，跟廣告公司brief過產品的特色和賣點之後，廣告公司回去腦力激盪後的腳本，大概就是下面這個廣告的模樣，有著清楚的訊息傳遞，但是好像少了點什麼。
專案外包的衝突與兩難-引言
過去，Mr PM都是處在發包專案的角色，現在因為自行創業，必須將30%的力氣拿來接案來養公司，所以開始有了些接案的經驗。而同時扮演過發專案和接專案的筆者，或許有些經驗可以來分享給大家。
我們這邊來看看，最理想的軟體接案流程是什麼？
- 客戶很清楚Spec或User Scenario，詳細的告訴接案公司，雙方就依此簽約
- 接案公司設定了Schedule與Milestone，每個Milestone要交付的事項也被清楚且具體的定義
- 完美且準時達成了Milestone交付的事項，沒有拖延或爭執
- 客戶完成專案，而接案的公司也撐到專案保固結束，尾款也順利領到，皆大歡喜
Domain name想破頭嗎? 不妨試試下面網站
(本篇轉自筆者發表在另一個blog的文章)
想Domain name真是個超級困難的任務，一群人鎖在辦公室裡面一籌莫展，有時候好不容易想到個名字，但是卻早已經被人家註冊了。
英文畢竟不是我們的母語，要想個好名字，自己在那邊空想是沒用的，得需要有一些Input，除了翻字典外，或許可以借助一些英文名字產生器來幫忙。
產品經理該怎麼發bug report
bug report，這是產品經理在做完User Accepet Test（簡稱UAT）後的產物，就是根據產品經理手上的Test Case，一樣一樣測試，然後把測到的問題整理成一份報告（格式或許是Excel檔），然後給研發部門參考，也可以當作產品經理與研發單位之間的Tracking List。
看起來很簡單的事情，不就是按照Test Case上的操作步驟，一個一個做，然後把結果不正確的找出來，就這樣而已。雖然僅僅只是如此，但是加上一些辦公室政治與人性在其中的話，那事情就會變得「不簡單」了。
用筆名撰寫Blog的優點與缺點
PIXNET大地震事件，談產品經理如何面對升級或改版
這次Mr PM的部落格，也是PIXNET改版大地震的受災戶。其實很明顯的，PIXNET的站方群，雖然是WEB方面技術的長才，可是卻沒有受過正確的服務規劃訓練。
PIXNET這次服務大地震，在一般在業界有規模的公司，幾乎是不可能發生的。為什麼呢？因為在服務改版或升級前，他們有幾個非常重要的原則會遵守。
產品經理如何面對媒體
這篇的素材大部分來自於資策會的課程，雖然是開給創業家的課程，但是原則基本上是大同小異，筆者輔以改編後就成了這一篇了。給大家參考一下。