Mr PM – 產品經理看設計與行銷

今天筆者看到30雜誌，裡面有篇關於兩代創業CEO的專訪，是citiport的CEO陳衍翰和巨大捷安特的老闆劉金標的對談紀錄，裡面有段對話非常令人深思。
「我越走到後面，越覺得人對了，事情就對了，經營企業是人比錢還重要」by 陳衍翰。
「跟事業夥伴相處，第一是要欣賞對方長處，並且互相尊重，第二是兩人要有互信的基礎，第三則是用心溝通，達成共識」by 劉金標。
其實有太多的成功人物傳記，裡面都提到上述兩句話，不過這兩句話都只是結論，其背後代表的意義，卻不是那麼容易令人明白。譬如說：什麼叫做「人對了」？或是有一天，你覺得你們公司就是「人不對」，所以「事情才不對」，那是「你不對」還是「其他人不對」呢？
其實在公司的運作中，同事都來自於四面八方，各自有各自的背景與原罪，要碰到「人對了」的機率其實不高，不可能團隊成員中全部都是EQ超高、能力超好、見解獨特又虛心傾聽；反而比較多的是超多毛病的同事：拖拖拉拉、言語帶刺、情緒控制不良...等。而且最重要的是，其實你自己也不一定是那個「對的人」，你也會有文人相輕的毛病、你也會有心思不細密的缺點、你也會有言語不簡潔扼要的短處。
所以劉金標這段話就非常重要了，怎麼說呢？筆者對劉董事長的話語做了以下的補充解釋：

最令PM扼腕的事情就是，明明已經知道市場的機會就在眼前，好不容易在會議中做了新產品構想完整簡報，結果被同事和上司做了以下無情的批評：

認為市場規模預估模型有缺點，對於新產品的未來太樂觀。

認為很多時候產品要放到市場上才見真章，焦點團體或問卷調查只在封閉環境內測試，外部效度不夠。

舉市場現有類似設計的產品做為反例，來佐證這樣的產品不會大賣。

上司以自身過往類似驗來作為反駁，說明新產品並不會有市場。

專注於找出新產品的缺點和問題，但是給的支持卻很少。

(本篇轉自筆者發表在另一個blog的文章)
想Domain name真是個超級困難的任務，一群人鎖在辦公室裡面一籌莫展，有時候好不容易想到個名字，但是卻早已經被人家註冊了。
英文畢竟不是我們的母語，要想個好名字，自己在那邊空想是沒用的，得需要有一些Input，除了翻字典外，或許可以借助一些英文名字產生器來幫忙。
 

bug report，這是產品經理在做完User Accepet Test（簡稱UAT）後的產物，就是根據產品經理手上的Test Case，一樣一樣測試，然後把測到的問題整理成一份報告（格式或許是Excel檔），然後給研發部門參考，也可以當作產品經理與研發單位之間的Tracking List。
看起來很簡單的事情，不就是按照Test Case上的操作步驟，一個一個做，然後把結果不正確的找出來，就這樣而已。雖然僅僅只是如此，但是加上一些辦公室政治與人性在其中的話，那事情就會變得「不簡單」了。
在產品經理發的bug report上，bug項目太多的話，這對研發這項產品的小組，是為讓他們在部門中很「黑」的。因為常常bug list項目的多寡，都會變成部門間的交戰工具，行銷單位的經理內心可能想著：「研發單位之前都藐視我們，或是一直說XX規格做不到，甚至批評起我們的business model，態度非常差。現在bug report上bug項目這麼多，該是好好轟殺這些這些人的時候了」。
但俗話說，冤冤相報何時了，這樣雙方處在緊張的環境當中，合作起來當然也是效果打折扣。若是能夠「以德服人」，讓研發單位好像欠了產品經理一個「人情」，這樣的做法才是高招，未來PM做起事情來也才更方便。
要讓PM能寫出「以德服人」的bug report，最根本的關鍵就是，就是在上頭的老闆通常不會細細的看每一個bug是什麼，老闆只會看到一大篇的bug list，就會覺得系統好像根本不能用，進而推論研發人員沒有認真研發。以下是會造成老闆誤會的bug list格式：

項目	敘述	測試人	發現日期	bug修正負責人	修正日期	備註
--	--	--	--	--	--	--

筆者將這個表格修正一下，增加兩個欄位。

項目	bug歸類	敘述	測試人	發現日期	bug修正負責人	修正日期	root cause	備註
--	--	--	--	--	--	--	--	--

大家很明顯可以看到，這兩個表格最大的差異點在於增加了「bug歸類」和「root cause」兩個欄位。「bug歸類」是產品經理寫，而「root cause」是歸研發人員撰寫。
而「bug歸類」的分類法，可以依照產品經理自己的定義，可以分成如：

這篇的素材大部分來自於資策會的課程，雖然是開給創業家的課程，但是原則基本上是大同小異，筆者輔以改編後就成了這一篇了。給大家參考一下。
別把觀眾和記者當作和產品經理一樣程度，必須從基礎講起。或是在訪問之前，先問一下記者是否對你的產品相關技術熟悉，確認背景知識足夠後再進行說明。
聽眾在訪談過後，腦海中只會記住keyword，所以善用聽眾已經熟悉的keyword，可以加強聽眾對你產品的印象。
別用任何負面的詞彙敘述產品，什麼產品機制不完全、功能沒完全，這些通通不可以說
遇到機密不方便說的時候，可以說：現在正在進行中，但差不多XX時候，就會完成，到時候一定主動通知。
電視訪問過程中少用「我們」，把「我們」改用公司名字代替，增加公司名字曝光度。
電視訪問過程中，盡量把產品拿在手上
訪談內容有條理，第一、第二...慢慢講，這樣聽眾和記者都很好吸收。
一次訪問中，只講1~2個亮點就好，而這些亮點最好能夠數字化、和最大化，譬如說：營業額四億，產業中第一個量產。其他的亮點在其他次訪談再講就好，不然太多亮點就重點了。
新聞稿撰寫不要超過兩頁
小心不要被其他大新聞吃掉，例如：奧運
辦記者會，不要和與你同產業的大公司同時開，不然記者只會去大公司，不會來你這邊
想想你的產品可不可以利用大新聞搭便車，例如：奧運
可以採用自抬身價策略，自己雖然小蝦米，但是在新聞上卻挑戰大鯨魚，HTC和APPLE就是一例。
在利用媒體曝光的時候，要注意自己的產品是否已經有先積極舖貨準備，或是伺服器有大量用戶衝進來的準備，不要變成曝了光以後，反而對你的產品印象變差
多個小公司之間可以互相聯名找共通點來吸引媒體，譬如說：二家公司都是台大畢業的，記者可能就會想做個台大創業特輯，這樣記者就不會有替特定公司拉抬的印象，記者上頭的總編會比較容易讓這種稿上。
記者會最好都開在台北，這樣記者出席率會高很多。
活動或記者會，最好準備一周的lead time。
若是要發新聞稿，最好能直接找到跑這條線的記者，若是不知道，可以直接打電話到報社問。
在重大事件的前、中、後，都可以分別發新聞稿
不太需要請記者吃應酬飯，記者通常對這種食之無味的應酬飯，興趣不高。只需要保持訊息的交流即可。
Email新聞稿給記者後，或是記者會邀約發出之後，可以發簡訊或是簡短打個電話確認對方已經知道，只需打一次電話就好，不然很煩人的。

筆者最近和一些紡織業的前輩聊天，聊到了他們的新技術發展。就是可以塞在紡織產品裡面的薄型軟性電容，薄薄的一片，可以彎曲，可以忍受高溫高濕，小小一片的面積，就可以儲存足以充飽一支手機的電量。
他們打算做一款「手機充電背包」，這款背包上面有薄膜型太陽能板，背包中的尼龍布，內嵌許多薄型軟性電容，這些軟性電容還接了一個鋰電池用來儲電用。這樣一來，臨時在路上手機沒電了，還可以馬上充電，解決了燃眉之急。
Mr PM聽了皺了皺眉頭，並不是說這個應用不好，或是這個應用沒市場，只是心中嘀咕著，他們的新技術，選擇到了正確的應用嗎？滿足便利性的充電需求，真能說服顧客買下這個背包嗎？
或許有人會想，先有技術再來找應用，本來就是一個錯誤的開始。不過Mr PM對於先有技術再來找應用這件事，卻感覺到這才是業界的常態。那些大聲疾呼「不要先有技術再來找應用」的學者專家，反而是因為不食人間煙火，才會有這種主張，而且這種「不要先有技術再來找應用」的主張，對於產品經理所面對的問題，真是一點幫助都沒有。
既然在產品經理的職涯當中，「先有技術再來找應用」一定不可避免，那不如就找套方法來好好處理這件事情。在這邊，Mr PM也來分享一些自己的心得。

俗話說：一個人的職場競爭力取決於他怎麼利用下班的時間。
說的很有道理，不過筆者下班以後，都是累癱在沙發上，哪還管什麼進修啊、競爭力。難得想打起精神來看點書，發現確常常精神力不集中，看沒兩下子又想回到沙發上，當個不需要動腦袋的人。
很多想增強自己競爭力的人，但是本身的個性有可能跟Mr PM很像，非常不具備Hard working和堅持到底的毅力，只要和職場工作的比較沒關係的進修，通常都會草草了之。到底我們這種人該怎麼辦才好？是否有那些社會上的典範，可供我們這種人一些啟發。
moto不擅長製造，把製造外包給華寶。

產品經理很重要的一塊工作內容，就是溝通。和研發部門溝通、和生產部門溝通、和業務部門溝通，最常見的溝通場合就是會議，但是令產品經理最「OOXX」的也就是所謂的「鬼打牆會議」。
什麼是鬼打牆會議，就是討論個老半天，好像都圍繞在主題上，但是又不算是個會議結論。舉個例子就明白。（以下是真實案例，為保護當事者，人名皆虛擬，案例內容也馬賽克修正過）。

John：我覺得首頁應該一進去就看到完整的朋友列表，然後顯示朋友動態，這樣才能彰顯我們的特色。
Sam：（表示不認同的皺眉頭）。那是因為你之前看xx網站，被他們所迷惑了，才會覺得將這個功能放在首頁會比較好。
John：（心理有點老大不高興，說我被迷惑了，這是意指我是笨蛋嗎？）我的意思是我覺得，首頁一進來就可以看到所有的朋友列表，也可以看到他們的狀態和暱稱，這樣還挺有社群的fu。
Sam：這樣比喻好了，你覺得MSN這樣秀出個聯絡人清單和暱稱，會讓人有社群的感覺嗎？
John：我是覺得MSN很有社群的fu，因為裡面大家都連結在一起，你可以即時看到別人改暱稱和心情。
Sam：你到路上問問看，有多人人覺得看到MSN會覺得他是個社群，那只是你覺得而已。

 
以上就是個很標準的鬼打牆討論，簡單的說，Sam當了一個純反方的的辯論者，什麼是純反方，就是針對正方的論點架構狂拆，主要目標是要證明正方的論述證據完整性不足。上面例子當中，Sam用了「類比法」和「尋找證據缺失」這兩個方法來當純反方。筆者一直認為拿「類比法」來當做討論的方式，常常會讓人覺得比喻不倫不類，不知道該怎麼樣回應起。而「尋找證據缺失」，尋找證據不是錯誤，但是收集證據的成本有時候過高，所以才會有這種「用邏輯辯論」的會議，所以當別人採用「尋找證據缺失」來回應，有時候還真的令人是挺不爽的。
不過面對的要是純反方的話，還只是次討厭的狀況，最討厭的是「純反方」+「人身攻擊」，或是「純反方」+「情緒激動不理性，開始大小聲」。在上面的例子當中，Sam就做了少許的人身攻擊，這種狀況更是令人嘔在心裡。
面對「純反方」的討論會議，常會淪為沒有結論，這真是再恐怖也不過了。那麼，在不改變Sam的個性和做事方法下，那John該怎麼做呢？以下筆者模擬幾種情境。

要克服幣帚自珍，還可以利用以下幾個自我檢測的問題

我的點子，除了我自己以外，世界上還有哪些單位比我還更適合做，而他們為什麼沒做？是沒想到，還是其實是不可行。要知道太陽底下沒有新鮮事，點子絕對不可能前無古人後無來者，是什麼原因造就你的點子到現在還沒在世界上出現過。

列出一張使用者使用你的產品後的「Gain」與「Loss」，常見的loss有「使用習慣改變」、「重新學習成本」、「重新bulid up使用環境」與「購買新產品的金錢」...等。推敲看看Gain是否遠大於Loss，讓人為了這些Gain而忍受這些Loss。另外在做focus group的時候，要同時讓受測者了解到這些「Gain」與「Loss」，才不會遇到一般市調公司在做focus group時，常常落入的「老王賣瓜，自賣自誇」的偏斜狀態，產品經理也才能得到真正有用的市場資訊。

「唯一亮點」的定義，產品經理構思的偉大產品，可能有非常多「突破性的發展」。但是一次打太多「亮點」，不容易在市場上產生出漣漪來，一次只選一個夠力的亮點，是產品經理必須做的取捨。

讓focus group的使用者，在不看使用說明書的狀況下，就開使用你的產品prototype；不用先簡介產品，也不用來個簡報，直接拿到就開始用。然後再來對focus group的使用者做訪談，並請他們回答幾個問題：

funP大改版，很多不同的聲音出來，筆者相信funP團隊一定做過非常多的測試與研究，希望funP可以順利轉型成功。
但是筆者在這邊要寫的是，猜測funP團隊對於這種會影響到非常多人的策略大轉彎，會採取的「測水溫策略」是什麼。因為對funP來講，這不僅僅只是改UI而已，而是把funP吸引的族群從「想知道特定族群最喜歡些什麼文章」，轉變到一個未知的狀態。
筆者猜測的「測水溫策略」流程大概如下：
從funP的user當中，徵求10個funP的代表性user，再徵求10個中度使用的user，通常Mr PM都管這群人叫做是「VOC：voice of customer」。當然嚕，這20個VOC最好都先面談過，確保VOC團隊之間的異質化能夠大一些，而不會都是同質性高的一群人。
將funP的新改版面貌架設成另外一個test site，不對外公開。並請這20位VOC測試使用1個月，並提供測試獎勵。
測試過程中，funP團隊需經常和這20位user聯絡，尤其是剛開始測試時的頭三天，這三天使用者的想法幾乎天天都會改變，務必得追蹤他們當時是怎麼想的，然後又是怎麼轉變的。
VOC測試結束，來個「測試結束大Party」，大家一邊吃吃喝喝，一邊聊使用心得與改進建議。這階段時的討論帶領者很重要，因為很多重要的想法，都會因為討論帶領者問了一個「有意思但夠尖銳」的問題，引發出非常棒的idea和使用心得。
將新版funP正式上線，接受眾多網友公評。每個禮拜funP再抽出20人，進行試用意見座談，再輔以其他線上其他網友的意見，繼續做出修正，直到funP團隊可以精確掌握住「水溫」為止。