產品設計體會（0009）零零散散之四

Ø  職業病一則：當別人要我作某件事情的時候，我總不喜歡直接接受別人的解決方案，但願問問爲何要作這件事？有沒有可能不作？肯定要作了之後，還要想是否是有更好的作法？更合適去作的人？作完了，再想之後怎麼讓提問的人本身可以解決從而得到解放……

Ø  產品經理是一個練內功的好職位 ，內力強大之後，能夠驅動招式，轉行去作什麼都能很快上手，因此我想再作幾年看看，對於用戶體驗，仍然看成興趣愛好。 在我還有不少想法的時候，堅決的走專業路線，以避免被一些不熟悉的工做分散精力。

Ø  經過線上運營提升活躍度的悖論：提高活躍度的空間在於把不活躍的用戶變成活躍的，而能看到運營活動的多數是已經活躍的，經費都花在了最活躍的那部分人身上，顯然違背本意，必定要注意這個問題。

Ø  模板的做用有三：讓常常看同類文檔的人提升效率；讓寫文檔的新人能夠儘快上手，寫出團隊可用的東東；讓寫做者不會漏考慮某些內容。各類結構化的方法論，做用也大體如是。

Ø  保持項目經理對項目團隊的威信相當重要，沒法作出的決策 PM 能夠單獨找老闆溝通，而後再下達，避免和團隊成員一塊兒去找老闆的狀況發生，此外，技術問題不要與開發爭論，而應該去充分得到項目內開發經理的支持。

Ø  亮點應用：「谷歌流感趨勢」能夠比美國疾病控制與預防中心至少提前一週，覺察出該地區是否有流感暴發。數據的價值真的很高，只是不少都挖不出來。

Ø  忽悠的前提：信息不對稱，懂得比對方多，有大局觀 ，因此要求很高。

Ø  內部（偏技術）的大改動每每是外部（偏商業）的小改動，反之亦然，因此去找改動小，收效大的點！

Ø  項目開始以前， PM 作兩件虛事，邀請項目成員所在部門的大老闆組成督導組，不僅爲了督導，更重要的是讓成員們知道他們作的事情有重要人物看到；申請項目經費，或者相關資源。項目開始之後， PM 的事情很簡單，幫你們買夜宵……