品牌行銷策略，產品行銷與設計，各類型行銷推廣案例分享-品牌行銷點點讚
編輯導讀：隨著越來越多人從事產品經理，這個職業的規范程度也在不斷提高。而面對復雜的工作，跨部門的溝通，產品新人應該如何成為一個優秀成熟的職場人士呢？本文作者將從認知、習慣、協同、決策、項目、帶人六個方面進行深入的分析，希望對你有幫助。
本文是作為跟誰學產品團隊新人指南的一篇文章，來自于日常的團隊管理和經驗習得，通俗易懂。如果你覺得自己在產品工作中遇到了成長的阻礙，那么以下內容在認知、習慣、協同、決策、項目、帶人六個方面做了要點的梳理。首次公開，供你查漏補缺，希望能幫到成長中的你。
一、認知篇
1. 產品經理是一個高杠桿工種
一般來說，產品經理和研發的合理配比是1：5。不難看出，產品經理本身就是一個高杠桿的工種。那么高杠桿有啥特性需要我們關注呢？我想最最重要的就是少做錯誤方案，因為一旦方案做錯了，5個研發陪葬，這里損耗的成本讓人心疼，也是行業內研發經常吐槽產品的關鍵所在。因此，不是人人都是產品經理，產品經理的專業度和成功率將決定整個產研的基礎效率。
其次，產品團隊不適合一下招太多新人，至少要保證在一段時間內，有值得信任的“老師傅”們能一對一帶才可以，從而避免新人大量不成熟的方案產出，讓研發跟著受累。
2. 產品設計師到產品經理最大的蛻變在于是否敢決策并承擔決策后的結果
產品設計師和產品經理最大的差別就是，產品經理會把自己當老板來進行決策，并且愿意承擔自己決策的后果。當然，我們知道后果有兩種，一種是出問題了，需要背鍋，一種是取得了不錯的成績，那么榮譽也自然歸屬于這個人的。
在這樣一個氛圍之下，很多小伙伴不敢去承擔結果，怕出錯。而這道坎，如果你邁不過去，那么你永遠只是一個產品設計師。事實上，大可不必畏手畏腳，任何產品經理的最終決策，團隊leader都會過目且會承擔連帶責任，因此在有人幫你撐著天的情況下，你更應該大膽決策，鍛煉自己的決策能力和強化自信心。所以趕緊變身為老板去推進項目，那么你能收獲更多，成長更快。
3. 不盲目崇拜技術，但需深刻理解“異步”、”解耦“、“抽象”等計算機思維及其應用場景
很多文科出身的產品經理沒有學過計算機相關的課程，會對計算機方面的知識產生不可越過的敬畏，然后去學某門具體的編程語言。但事實上，產品經理和研發溝通經常不在一個位面的問題和編程語言本身一點關系都沒有，最重要的是計算機思維。比如，“封裝”是指一種將抽象性函式接口的實現細節部分包裝、隱藏起來的方法，這就像我們產品經理和技術的協作，我沒必要知道你具體怎么做的，只要你告訴我啥時候開始，啥時候完成就好，開發過程可以對我不可見。
比如，“異步” 是指計算機多線程的異步處理，與同步處理相對，異步處理不用阻塞當前線程來等待處理完成，而是允許后續操作，直至其它線程將處理完成，并回調通知此線程。那么類比來看，在溝通的時候，有些事情我如果只需要一個答案，且時效性沒有要求很高的情況下，我沒必要跟他打電話或者面對面，而是在企業微信上留一段信息，等到對方看到并回復之后，我再進行處理和下一步動作。這就是“異步”的溝通。除此之外，“解耦”、“抽象”、“實例化”、“接口”等概念及背后代表的一種思維方式確實在很多場景下有其價值。比如所謂的“中臺能力”，其實就是把一些通用的、基礎能力進行“抽象”，當哪個業務部門需要使用的時候調用“實例化”即可。
4. 產品經理除了邏輯和數據，還要懂文案和設計：優秀的產品經理本身就是一個感性和理性的綜合體
往往工科出身的產品經理在邏輯、數據層面都是很好的，也知道溝通和協作的重要性。但經常忽視一個“軟實力”，文案及審美。這個真的是在某些產品經理身上是一個非常嚴重的問題。文案倒不是指要寫出多優美的文章，而是在標識、通知、海報、商業長文等不同使用場景、不同字數要求下，能否專業地表達，讓用戶能迅速明白你的意思，不會覺得別扭。
說白了，底子還是語文能力，但可以通過多模仿、多琢磨來達到效果。而設計這事兒，在原型方案及設計溝通方面，因為對設計的認知差異將會帶來特別大的溝通差異，不專業的表達比如“你這個方案差點意思啊”，“這個圖標太丑了”，“整個排版我不太喜歡”，只有情緒化、形容詞化的表達，而專業的表達是“這兩塊文字之間的間距是否合適，看起來有點擠”，“這個按鈕對于產品方案是非常重要的元素，能否在視覺上強化一下”。
二、習慣篇
習慣篇的大部分內容都是你說的對，但是我不能堅持做下去，所以持續的“自律”本身就是一種核心競爭力。
1. 不能忙于輸出，忽視輸入；需要持續學習，持續精進自己
大量的有效信息輸入，才能有卓越的輸出。連國家領導人都需要智庫來做決策支撐，我們作為一個普通的個人，如果沒有外界信息的攝入，靠著自己的一個大腦去決策，那么自然不用多想，不會有很高質量的決策結果。因此，系統讀書、競品分析、用戶調研等各種有效輸入信息的方式都需要我們融入到日常工作中，我們才能有更高階的輸出能力。這種能力俗稱“站在巨人的肩膀思考問題”，樸素但極度有用。
但往往我們沉迷于那些短時見效的技巧，而忽視了費時費力的積累。這也是我把“習慣篇”單獨拿出來的原因，因為這些“習慣”即使你知道是對的，但大部分人因為心力有限或自控不足，導致無法做到這一點，從而沒有辦法成為一個優秀的產品經理。
2. 均衡輸出是產品經理高效工作的關鍵
很多產品經理會炫耀，“我昨晚擼了一版原型，擼到3點”，從而顯示自己在短時間出活能力很強。當然， 這本身是一種能力。但放到產品經理一周的工作，一個月的工作，一個季度的工作，一年的工作中，這只是一次不持久的峰值輸出。而優秀的產品經理應該是能持續均衡地、高質量地持續輸出，比如每天工作量都穩定在0.8，而不是今天特別雞血做到1.2，第二天狀態不好變成0.4。
之前我和新人小伙伴有這樣一個節奏要求，“至少一個項目在開發中，一個項目在確定需求下的原型方案中，一個項目在前期的需求調研及討論中”，這樣有節奏地、持續穩定地內容輸出慢慢也能會讓設計、技術的節奏共振，大家就都能均衡輸出，避免瞬時負載過大或者空轉，因為后者一定會帶來資源的浪費。
均衡輸出對于產品經理來說，還有一個需要關注的重點工作是提前計劃，因為產品經理是一個需要大量協作的工種，比如需求調研和業務部門溝通，方案設計在產品團隊內部溝通，設計評審和設計溝通，需求評和研發溝通等等，一個項目做下來要開N多會議。高手和低手之間最大的差別就在提前計劃和事先準備上，優秀的產品經理會結合對方的時間安排，盡量把協作方時間提前占上，避免臨時約會由于和其他會議沖突導致無法安排上。
比如今天老板安排了一個項目，需要和業務部門調研，然后你突然想起今天和明天業務部門休息，導致只能約后天時間，這種因為時間節奏沒踩好的情況下會讓一些周期較長的項目晚一周到一個月上線是非常正常的事情，而且一般人還看不太出毛病，覺得每個環節都跟上了啊，怎么還有浪費。事實上，如果提前把時間節點更好地進行設計和規劃一下，會讓很多環節的銜接更加緊湊，從而節省時間。
3. 學會使用高效的溝通方式進行協作，并達成目標
產品經理要對低效的溝通保持敏感度。但有時候大家在忙碌過程中會失去對時間的感知，導致某一個會議已經明顯偏題了，沒人叫停，或者陷入不必要的爭執，沒有中止。
一般的溝通方式有IM群、IM點對點、電話、面對面討論、會議、郵件等方式，要學會區分這些方式適用于哪些場景，比如IM群適用于時效性不太強的異步溝通；郵件適用于結論同步，而不適用于討論，面對面討論適合一些臨時突發的緊急問題，把大家拉在一起迅速達成結論；會議適合相對較長的講解和溝通，以及復雜問題的討論。大家可以在實踐中把握不同溝通方式的精髓，學會組合使用他們，為自己的溝通目標服務。
4. 發現問題到正確實踐之間存在一個巨大的GAP：工作必須復盤，復盤必須落實
自己想清楚某一件事情，并且意識到自己在這方面存在問題，到自己完全能克服這個問題并且保證未來在處理類似的事情不會再犯同樣的錯誤，我們需要意識到，這之間有巨大的落差，夸張一點，和左撇子掰成右撇子是一樣的。
具體兇險點如下，第一是我們在復盤看待整個過程的時候，是否能不留情面地認知到自己當時在某些方面確實存在不足，這是違背人性的，一般人都會給自己找借口，找外部原因，這是阻礙發現問題的“攔路虎”，因為你要客觀意識到一定有人在當時能比你做出更好的決策，而這樣的復盤才是有意義的，找到自己真實的短板。第二個兇險點就是復盤結束不落實，意識到了問題，但是行動上還是之前的慣性，一般糾正錯誤動作是需要專門訓練的，然后才能形成新的肌肉記憶。
三、協同篇
1. 資源限制是常態，而產品經理需要習慣這個常態，但依然保質、按時推進高優項目
資源限制是常態，無須抱怨研發資源不夠，因為一旦資源充分到沒有任何阻礙，那么要么產品經理人少了，要么研發資源多了，這都是公司的損耗。而資源限制能更好倒逼產品經理權衡項目之間的優先級，在有限的資源下找到高杠桿的項目。除此之外，好的產品經理會把資源視野放到更大范圍，比如我們的中臺部門、兄弟部門等，在共贏的情況下去推進自己的關鍵項目，也是在資源限制下的有效手段。
2. 多思考一步，多行動一步
多思考一步的好處是讓事情的成功率變高，原因在于在協作過程中，一般思維是負責好自己邊界內的事情就好，但事實上任何協作都會存在一些模糊地帶，且有時候這些模糊地帶還很關鍵，如果沒有處理好會達不到預期結果。因此，任何項目的推進，希望大家都多思考一步，比如產品上線之后需要運營、客服等其他團隊配合哪些動作。Take one more step，是鍛煉大家思考深度和全面性的關鍵，只有主動多邁出這一步，才能讓結果大概率地被命中，減少“黑天鵝”事件。
3. 各司其職比相互補位更重要
既然互聯網公司造就了各個職位及相互協同，那么每個職位的第一要素是完成自己職位對自身的要求。有時候，有些產品小伙伴會被運營的各種問題或者研發的各種建議所“迷惑”，主動去做運營問題解答（目前我們一般是有值班QA團隊負責跟進線上問題并定位）或者和研發討論一些優先級并不太高的建議，那么導致自己職位需要完成的需求調研、原型設計等工作被擠壓，然后你去和他argue的時候，他一臉委屈說，我也很忙的，每天要應付各種事情。
那么，關于這樣的問題，第一是大團隊層面要建立標準流程及動作，該誰負責就誰來解決，沒必要好心去幫忙承擔。第二是作為個體，要對這些非本職位的事情盡快牽線給對應負責人，認為不重要的的事情直接回絕，不糾纏 。 只有各司其職，協同才是最高效的，否則本來到了你環節該處理的事情，沒有第一時間響應，反而去幫別人去做事情，自然團隊的整體協作效率更為低下。有小伙伴可能會反駁，你看你這態度是不是太不積極了，非得給自己的事情劃邊界，不是一個好的合作態度嘛。這里有明顯的偷換概念，合作本身是基于崗位對自身的要求協作，如果在本職工作做完的情況下你愿意幫助別人，那是很好的事情，但是一定是本職工作優先。
4. 平等參與一切協作，特別是和比自己高階的人更要鼓起勇氣
很多產品新人在和業務部門溝通需求的時候，如果遇到比較強勢的合作團隊，容易出現畏手畏腳的情況。主要原因是怕自己的思路錯了，或者對方是很高階的人（比如有些需求會面對運營管理層），不敢質疑，所以更多寧愿選擇安全地跟隨別人的想法和需要，不經思考直接復制。
在這種場景下做事會出現兩個問題，一是失去自己的判斷和決策力，二是從結果上可能還會出現偏差。既然出現了產品經理這個職位，他沒有被運營合并，也沒有和研發放在一起，自然是有其價值。產品經理的價值往往是站在第三方角度客觀冷靜地去看待過程中的人和事，從中去梳理流程，抽象業務。所以，這個時候基于長期溝通和調研形成的常識，是應該大膽地去主導一些方案設計的，不需要太亦步亦趨地配合業務，甚至有時候因為競品的調研和對比，還能發現業務中當前模型的問題。因此，請大膽一點，和合作部門進行一場“勢均力敵”的協作。
四、決策篇
1. 可做可不做的，堅決不做
如果要類比產品經理的職能的話，產品經理更像醫生，而不是畫家。優秀的醫生在面對病人的病癥時，一定是“如無必要，不用猛藥”的邏輯去處理病癥，產品經理也是一樣。經常看到產品新人在方案設計上做得特別復雜，特別是在一些二八原則下的20%場景的處理，會加上很多小策略、小細節顯示自己的完整邏輯及細心，但事實上優秀的產品經理會想辦法用盡量簡潔的方案去覆蓋大部分場景，相對忽略那些低頻、不重要的場景的體驗，從而讓整個方案便于用戶理解，開發成本也能得到很好的控制。
要知道，按照互聯網產研團隊的常規配置比例 1：5，產品經理的杠桿是很強的，多設計一個新策略平均都需要5個研發來配合，所以一旦策略不靠譜，后果就是研發會對產品經理產生信任崩塌。所以，如無必要，堅決不加！
2. 工作中的大部分事情應該是通過條件反射來解決的
我們會遇到很多事情，糟糕的產品經理會把每件事當做一件新事來做，而優秀的產品經理會把這些事情進行歸類，用解決這一類問題的歷史經驗來處理，類比健身來說就是“肌肉記憶”。如果發現是一個新的事情，無法通過歷史經驗解決，那么才會思考新方案。在這樣的做事邏輯下，才能保證在限時條件下的高質量的、穩定的輸出能力。把大部分事情通過條件反射來解決，少部分沒處理過的事情費心思進行思考，而不是每件事情都投入相同的精力來處理。
3. 不追求每個細節都符合要求，但對關鍵細節不做絲毫妥協
糟糕的產品經理會為了上線在很多產品細節上進行妥協。優秀的產品經理也會妥協，但只在不關鍵的細節上，但凡在關鍵的、能對結果產生絕對影響的細節，即使有各種技術阻礙、上線時間壓力都會死咬不放。因為他們知道，一旦妥協這個項目得不到預期的結果，縱然上線也是枉然的。換句話說，面對目標決策，而不是面對困難決策。困難不值得妥協，非目標相關的問題隨便妥協。
4. 圍繞有效目標出發，動作不變形
站在行業來看，我們都很在意日活躍用戶這個指標。假設老板定下關注這個指標之后，我們是否需要努力做些促進日活躍用戶的事情呢？關于這個問題很長一段時間是我的心魔，一方面希望達成這個在行業達成共識且老板十分在意的指標，另外一方面發現我們有些動作如果去做了，數據層面上是會提升的，但是不能給用戶帶去真正價值。比如引導用戶簽到兌換學分、加強push策略等，從短期來看數據一定會提升，但我們都知道一旦這么做了，就基本上把自己陷入KPI中，而忽視了客戶的體驗和APP的價值。因此，我們在決策上，要圍繞有效目標出發，動作不變形。
五、項目篇
1. 運營系統在設計上應該先放再收，在沒有邏輯問題或額外較大工程量下盡量滿足業務復雜場景的需要
我們在設計運營系統上，經常會遇到業務部門五花八門的需求，比如以退款為例，可能你為了財務計算的方便和系統的簡潔，希望提供一個建議金額的退款功能即可。但事實上，但當你調研需求的時候，你會聽到希望可以僅退部分款但不退課、退款金額允許超過或者少于建議金額（預收款-確認課酬），退款可以設置哪些課節可以訪問或者整個課程均不可訪問等各種需求。而事實上，當一定的用戶體量之下，以上幾種情況都是合理的運營動作，都需要產品提供支撐。
因此，在規劃運營系統時，建議出發點是盡量開放和支持的，避免過多限制導致在運營過程中的不靈活和不方便，從而無法被運營真正用起來。當然，靈活需要有一個度，如果靈活之下帶來較大額外的技術開發或者邏輯問題，那么我們需要收斂一下，通過限制、隔離去控制需求復雜度。
靈活之下產品經理還需要警惕的是兜底問題，比如退款金額不能大于實付金額，避免底層的數據沖突。
2. 工程量較大的項目需要進一步拆解，把MVP或者當前急需的功能閉環拆出來先推上線
在規劃優惠券功能時，我們最初規劃了三種優惠券（課程優惠券、品類優惠券、平臺優惠券），并認為未來一定都能用得上。但這個時候，研發反饋三種優惠券同時做工作量較大，因此我們重新評估之下，認為當前班級和品類優惠券優先級更高，因此可以把這一塊單拆解出來先評審開發上線，確保項目可以整體提前被運營使用。而平臺優惠券放到了二期或者更后面的開發周期里。
這在大型項目里是一個非常受用的思路，把一個初看無法切割的項目拆出真正的MVP。
3. 重大項目上線前需要知會客服，并和運營小伙伴規劃上線后的運營方案，讓產品能夠有效觸達目標用戶
項目上線前后才是產品真正面向用戶的關鍵時刻，需要為此做好充分準備。重大調整需要知會客服，方便客服在遇到用戶詢問時能第一時間回答。除此之外，需要和運營小伙伴規劃上線后的運營方案，準備運營資源并進行合理推演，保證項目上線后也能按照預期有效觸達目標用戶。這背后依然是協同意識，一個項目的成敗需要不同工種的充分協同。
4. 從投入產出比來看，部分項目考慮用第三方工具支持，不一定需要自主研發
前一陣子看到不少微信場景的功能需求，比如批量回復48小時內互動用戶等，很多微信場景的功能，第三方工具已經做得很好了，如果沒有和業務有強關聯性導致必須自主研發，可以強烈建議或幫助運營小伙伴找到合適的第三方工具。該思路同樣應用于其他需求的判斷，不是所有需求都要自己來做。同樣，在語音評測、敏感詞智能過濾、視頻人臉識別等一些強技術領域，目前都有不錯的第三方公司開放了服務能力，那么這個時候適當使用第三方技術來達成自己的商業目標，從投入產出來說確實性價比更高。除非這項技術對于公司的未來有著非常重要的地位，那么值得做長期、持續的投入。
六、帶人篇
1. 我說你聽，我做你看，你說我聽，你做我看
阿里經典的帶人口訣，但很多老人帶人的時候都忽略了其中的部分步驟，比如第二、第三步。這兩步有啥重要的嗎？第二步很重要，特別是一些復雜的任務，比如做一次技術評審，主持一次需求調研會，完成一份高質量產品PRD，這些事情都是新人沒有經歷過的，老人需要做出示范性演示之后，新人才可以進行學習和模仿。
第三步關注的問題是在溝通的時候，由于接收方能力不夠，不一定完全理解leader的意思，因此在執行層面出現動作偏離。而第三步能通過反向溝通會讓新人更加明確自己的執行要素，所以新人最好的素質就是不懂就問，利用大家認為你是新人小白階段，大膽問出那些自己可能覺得膚淺的問題。因為一旦過了新人期，大家就會按照老人的標準來要求和審視了，那個時候再犯低級錯誤就更不值當了。之后才是第四步，觀察新人的動作并糾錯。
2. 老人做新事，新人做老事；新人要做重要的老事
千萬不能讓新人一來就做新事，失敗率接近100%，特別是老人都不確定該怎么做的事情。新人應該做老事，比如競品已經完成了或者老人把大致思路已經理完并且確定了，這樣的項目適合新人上手。而把一些偏探索或者不確定的項目，安排老人來完成，利用他們豐富的歷史經驗避免掉一些坑。當然，面對新事，老人也不一定成功，只是成功率一定遠高于新人。
除此之外，要培養的新人即使在實習期也要安排重要的事情，千萬不要認為實習就安排一些邊角事情就好，這其實非常不利于新人的成長，而一些重要的老事，在老人的指導下推上線，將會極大增強新人的自信心和工作積極性。
作者：劉雨（訂閱號 小雨哥Rain），跟誰學產品負責人，目前主要負責跟誰學產品線的整體規劃，在社交和教育領域有些研究。
本文由 @小雨哥 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自 Unsplash ，基于 CC0 協議