産品經理是什麼？産品經理其實跟醫生一樣，眼光一定要全面，而不是局限在某個地方。那本文主要與大家談談，新人産品經理常見的十種錯誤。
大家好，我是何喵喵，是在複旦讀研的一枚小産品，寒假應學長的邀請，在頭條負責某産品線。四個月左右的時間，上海北京來回奔波，最後獲得了國務院某部的某牌照，有兩個項目成功上線。
在這過程中，一直想寫一些經驗和感悟，也有想叫上IES（頭條互娛，抖音、西瓜）的産品小夥伴一起，但最後都因為忙碌作罷，今天總算有時間對過往的經驗做總結和複盤，概括出十條經驗，希望對大家有所幫助。
一、原型圖就是頁面
産品經理是什麼？
産品經理其實就是産品的醫生。醫生在看人體架構的時候，眼裡不光是隻有手和腳，還有各個器官和血管。
産品也是，如果你的原型圖中隻有諸如個人頁、 首頁、分享頁等頁面，那UI同學一定會輕蔑的說“你真的好不專業”（當然如果她這麼說還是件好事），如果UI同學因為忙碌或者幹脆懶得管，那麼我們可憐的新手PM就需要在前端和UI之間來回跑。因為對前端來說，隻給主要頁面相當于人隻有手和腳，無數的狀态、跳轉、提示，他都會問你要。
一個典型的例子是：我初次寫的某産品Android端原型圖，有27個頁面，增加了遺漏的部分後，幾乎翻了一番，達到了52個。
對新手PM來說，最容易遺漏的主要是：
（1）彈窗，包括居中式和下拉式。
（2）toast，即一閃而過的提示。
（3）狀态，包括空狀态、編輯狀态、按鈕狀态。
空狀态：即服務端暫未傳回資訊的狀态。
編輯狀态：主要用于文字和圖檔的輸入框。
按鈕狀态：
二、PRD就是原型圖
以某産品的重置密碼頁為例，同樣的頁面。
（1）新人産品經理
（2）富有經驗的産品經理
我們可以發現，新人PM常見的錯誤就是：但見樹木不見樹林，同樣的框，新人看到的是輸入（使用者視角）；老人看到的是置底文案、編輯狀态、報錯狀态和提示文案（開發視角）。
在寫PRD過程中，一個比較好的辦法是：在頭腦中建構思維導圖，就是QA們常用的case，形成思維習慣。
如：
另外，儲存常用的邏輯也是一個很好的辦法。
三、能說會道的程式員一定是好幫手
錯！
實際上對産品經理來說，腼腆的RD更不容易拒接需求。善言的研發同學，很多時候都會對産品功能提出自己的想法，這固然可以起到review需求的作用，但在擁有正規流程的公司，産品的需求都是經過内部讨論、公司評審的。
也就是說，PM如果在研發階段同意了RD的想法，就得退回内部讨論，更不用說公司評審了。是以默默開發的研發同學，對産品經理來說其實更為友好。
四、産品外包做甲方真的很爽
由于開發資源的普遍不足，很多營運需求或是非核心業務都有可能外包，第一次接觸外包的同學在某一刻可能會覺得——“世上隻有外包好，公司的RD像塊寶”。
沒錯，由于甲方的強勢，作為乙方的外包常常是有求必應，但基本上是“有需求必應付”。大型的公司，比如：頭條，都有自己的代碼規範，外包團隊做的産品往往是表面上看起來可以，其實研發接手後基本上是要推倒重做。更多的情況是：表面上也不可以，除了代碼規範，UI也是有規範的。
是以選擇外包真的要慎重，錢不是核心的因素（反正不是PM的錢），重做和修改的時間成本、溝通成本，真的會要了老命。
五、和互動、UI互怼就是浪費時間
大錯特錯。
在這裡我也要檢討自己，很久以前我就是抱着這種想法，很多公司的UI不參加需求評審，她們隻是被動的接受leader配置設定的需求，是以PM常常需要，在需求安排到某個UI設計師後再講一遍産品的使用流程，UI就會提出很多質疑和自己的想法。
這個時候我們PM隻需要堅持一點，功能不變，形式可以聽UI的。術業有專攻，千萬不能覺得UI隻是畫個圖，要知道，央美的畢業生确實是比複旦心理系的同學更懂設計。
我們以我做的一款産品為例：
（1）紅框：閱讀捐時間的入口
産品設計的初衷是弱化捐時間的概念，突出捐款，是以我把它放在右上角，以button的形式展現；而UI的終稿以“＞”的icon呈現，不僅在美觀程度上優于button，同時保留了公益金數量這一重要的資訊，對使用者的打擾也降低到最小。
（2）綠框：感謝卡片的展示
我設計的初衷是榮譽的展示與卡片的收集，而我們的UI同學創造性提出：隻展示最近的一條感謝卡片中的文案，加上勳章的标志，每次捐款都有更新。是不是比我的高明許多呢~
最後，這兩個修改都出自頭條UI規範評審會的資深設計師，如果你産品的UI還是新手，那還是可以怼一怼的…..
六、産品、營運，冤家路窄
我的上一個leader，前百度M級、現vipkid的産品負責人CB，怼的最兇的就是營運，經常是劈頭蓋臉的怼。
确實，營運作為業務方總是會有各式各樣的需求（有些還很奇怪），但這些需求，根據喵喵的經驗，真的是很容易拒絕的。因為營運在流程上沒法直接對研發提需求，要記住，你是産品經理，所有的需求都需要經過你。實際上如果相處的好，營運真的可以成為PM的好夥伴，而且是最好的夥伴之一。
那麼營運同學在哪幾個方面可以有效的幫助産品經理呢？
首先是對外交流，比如：我做的某款産品，線下的支援是産品成功的基礎，同部門的營運同學就很給力的拉到了兩個地方政府和企業的贊助。
其次是開會怼人，是的，總有一些隔壁部門的傻逼試圖挑戰你的底線，一個強執行力的營運（比如：我的好夥伴），完全可以替代你開會怼人；還有是文案圖檔，這是個很瑣碎的活，RD總是需要文案和圖檔，如果産品經理太忙抽不開身，那就交給營運吧（真的開心）。
七、一切以PRD為準
這是說給自己聽的…..以我經驗來看：各部門看的文檔與PM的預期不同是一個常見的問題。
我之前在的望京某公司，互動設計師看PRD，UI看互動稿，RD看UI稿，QA看互動稿，三個文檔稍微有差别就會引起混亂。是以，更好的流程是：PM出原型圖——互動設計讨論修改——UI設計讨論修改——PM根據UI圖修改PRD——前後端根據PRD和UI圖開發。
PM根據UI圖對PRD的二次修改，是重要且不可省略的一步。
八、開發會議不用叫上老大
不是的，無論是自己的leader還是研發的leader，都不喜歡被排斥在開發程序之外，他們可以不參加具體的工作，但絕不能不知曉工作的進度，這不僅是心理上的考慮，更是管理上的要求（研發和UI的老大都需要評估手下員工的工作量）。
我就因為在一次開發會議中，隻叫了上一期的前端、這一期的前端同學，忽略了他們倆共同的leader，後來被這位leader當面怼掉了一個需求，真的是吃了大虧。比較好的辦法是郵件抄送，要開溝通會議時先拉群，對方leader如果不能到場，自然會協調時間或禮貌的回應，是以不管是小頭目還是大上司，都需要進行及時的資訊跟進。
九、沒有說服自己就貿然答應需求
沒有說服自己，就沒法說服别人，産品經理作為需求的中樞、彙總點，會收集到無數的來自業務的需求，當然自己也會産生很多好的點子。
假如你的leader提出一個需求，你很順從的把它添加進功能裡，如果這一需求存在疑問，那麼産品評審會、互動設計、UI設計、前後端開發，每一個過程中都有可能會對這個功能提出質疑。如果你沒有說服自己，又怎麼能面對别人的質疑。
是以對于需求，要不就合邏輯、有場景、或是業務流程的天然組成部分，否則你就必須考慮拒絕或延期。我遇到的典型例子是：老大讓在某個位置加跳轉button，結果UED評審時，幾位UI設計師紛紛質疑，我無法自圓其說，最後反複協商修改了呈現形式，這一功能才得以保留。
十、溝通工具好于當面溝通
錯。
腼腆的同學，如果又是非技術出身，其實不太适合做産品經理，很多開發的細節，RD、UI都需要和産品經理确認。我們這個時候如果太多的依賴溝通工具，實際上會耗費更多的時間——很多涉及邏輯的問題需要在産品上直接展示，在溝通工具上根本講不清。
RD和UI作為後來的參與者對上一期項目或者這一期的功能總會有不清楚的地方，而産品經理才是熟悉産品功能細節和業務全流程的人。
此外，當面溝通還有促進感情的作用，畢竟“熟悉産生好感”（侯玉波《社會心理學》），隻有好的研發兄弟，才會在周六來公司和年輕的産品經理一塊加班。