酷播亮新聞
產品經理是什麼？ 產品經理其實跟醫生一樣，眼光一定要全面，而不是局限在某個地方。 那本文主要與大家談談，新人產品經理常見的十種錯誤。
大家好，我是何喵喵，是在復旦讀研的一枚小產品，寒假應學長的邀請，在頭條負責某產品線。 四個月左右的時間，上海北京來回奔波，最後獲得了國務院某部的某牌照，有兩個項目成功上線。
在這過程中，一直想寫一些經驗和感悟，也有想叫上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作為後來的參與者對上一期項目或者這一期的功能總會有不清楚的地方，而產品經理才是熟悉產品功能細節和業務全流程的人。
此外，當面溝通還有促進感情的作用，畢竟“熟悉產生好感”（侯玉波《社會心理學》），只有好的研發兄弟，才會在周六來公司和年輕的產品經理一塊加班。
最後，以上就是喵喵為新人PM準備的十條經驗，喜歡的話，點個贊哦~
本文由 @何喵喵 原創發佈於人人都是產品經理。 未經許可，禁止轉載
題圖來自Unsplash，基於CCO協議