近幾年，產品經理崗位火熱的一塌糊涂，受到了越來越多的應屆生和互聯網其他崗位朋友的追捧。好的產品經理在企業中的重要程度不言而喻，他是需求的發起者、項目的推進者、團隊溝通的橋梁、企業發展的舵盤。

然而，由于產品經理崗位沒有行業認可的準入機制，產品經理技能也沒有很好的量化考核標準，所以對于相當一部分產品經理，他們并不知道自己該如何發展，或者是該重點培養哪些特質。一般來講，從業時間長了，產品經理們自然就會形成一套自己的方法論。

但是，在最初、最迷茫的前兩年，初級產品經理應該主要把精力放在哪些軟實力的提高上呢？或者說產品經理崗位要求千千萬，應該優先做好哪些呢？

結合個人經歷，我覺得有如下幾點。

1. 學習

知識是無止境的，要學的東西也有很多，做到了學習這一步，至少能夠給自己養成一個很好的習慣，并且在陌生環境下，可以迅速切入，而不至于前幾天傻傻的不知道干嘛。

• 學習業務邏輯

不論是應屆生，還是社招的產品經理，快速的學習、熟悉新公司的業務邏輯都是必須經歷的過程。作為產品新人，一定要學會從產品文檔出發，快速準確的理解產品上層和底層邏輯、產品架構、人員分配等一系列相關問題。在使用的過程中發現“改進點”，初步了解完業務之后，再搞清楚這些所謂的“改進點”背后的原因。并不是其他產品都是傻瓜，不能發現問題，可能是這樣或那樣的限制使然，搞清楚歷史原因、弄明白上下文，才更容易有的放矢。

作為一個新人，能深入了解自己負責的部分、吃透里面的邏輯和規則是基礎中的基礎。足夠了解業務后，自己的意見和建議才更有說服力。盡量不要出現下面這樣的情況：

“我覺得XX功能應該這樣這樣優化”

“這個由于系統限制，現有方案是討論當前出來的最優解”

（或者“這個是因為怎樣怎樣的數據存儲，導致只能用這樣的方式，否則改動起來成本太大，得不償失”）

“哦……”

• 學習優秀的特質

不是每個新人都會有導師帶的，也不要指望有人能夠像老師一樣一點點指導你。如果你在你看來，周圍的人都不如你，那么趁早離職（我不奢望這種情況下，你還能去發現“美”）。如果在你看來，周圍有更優秀的人，他身上的某些特質你希望擁有，那就去學。

別人的特質可能是做事態度，可能是思考的過程，可能是看問題的角度，可能是說話的方式，等等。這些東西能學多少就學多少，只要你覺得你學來了之后對你有好處就行。

2. 執行

大多數產品新人都是從產品助理或者專員做起，這時候的主要任務就是執行。所謂執行，不光指別人讓你做什么就做什么，也包含了你做了類似改進需求之后不敢做主，需要老大確認才能做的事。

當老大交給你工作的時候，他要的是結果。但過程怎樣決定了你能收獲多少東西，你是呆萌的老老實實去完成，還是自己思考其中的原因，而且嘗試在心里提個B方案，這都是由你決定的。

有時候，雖然結果都是加了個彈窗，但你既可以理解為就是加了個彈窗，也可以理解為需要考慮為什么加這個彈窗、彈窗的場景合不合適、會不會造成打擾、能不能滿足需求、有沒有其他彈窗會同時出現、出現之后是怎樣的優先順序、為什么彈窗就要比Toast好、為什么文案要這么寫、為什么按鈕要這么擺，想過一遍之后，還是加了一個彈窗，但對你個人的成長卻是不一樣的。（當然，大多數情況，老大也沒想后面的東西，就是加了個彈窗而已，但對你有任何影響么？）

產品經理的工作內容本來就很雜，作為助理會更雜。你可能會接到很多莫名其妙、亂七八糟的事情需要執行。我建議盡量去執行，將執行做到極致。

比如一個公認的歷史遺留的老大難問題，完全沒有文檔、之前的開發離職了，只能拜托另一個開發從代碼層面重新梳理文檔。這時候的你肯定是頭疼不已、叫苦不迭，這種工作既費時、又費力，而且是梳理現有邏輯，完成之后老大也未必覺得你優秀，還可能遭開發大哥的白眼，但還是要要求自己執行好，只有完成一件事情，才有可能承擔更多的事情。

比如讓你去收集、整理、答復用戶反饋，解決用戶問題，這看上去好像是運營的工作，但還是要要求自己執行好，傾聽用戶聲音、挖掘用戶需求，才能更好的理解產品、改進產品。

比如讓你找財務幫助部門報銷，或者和法務溝通對外合同，你可能覺得這是運營助理做的事情，但既然落在你頭上了，也只能要求自己執行好。（當時的我嘗試和老大溝通，拒絕執行這件事，因為我覺得超出了產品工作范圍，然而由于老大的強勢和我之前沒有給他留下做好初級產品經理的印象，導致我最后還是執行這件事了。至今我都覺得不該我做，不過類似問題大家仁者見仁智者見智吧。）。

總結起來兩句話，一是只有將執行做到了極致的人，才是最優秀的產品助理，二是不論多難啃的骨頭，能把它嚼碎了、咽下去的人，才能有大發展。

3. 溝通

對一個新人來說，學會有效溝通非常重要。

• 描述需求

有好多新人，描述需求的時候吞吞吐吐，其實也不是因為緊張，但就是無法準確的表達想要說的東西，周圍人聽著聽著就有一種你在說TMD什么的感覺。

這種時候，一定要想清楚了再說，哪怕別人問起來，你回答：我先理一理再說，也好過說一堆不知所云夾雜著明顯的邏輯漏洞的東西好。這也側面證明了剛才說的學習的重要性，先把自己負責的東西搞清楚，看看別人說需求的時候是什么邏輯、什么層次，慢慢模仿，多多練習。

• 交流

產品人員參與頭腦風暴類的會議應該很多，在溝通一件事情時能夠首先發言、拋磚引玉固然好，但是也盡量將問題說到點上。雖然網上好多人都說新人不要怕說錯話，別人會理解你，可是也不要南轅北轍。有時候新人的出發點本身就錯了，如果團隊里糊涂的人居多，那就會把一件事“成功”的帶歪，所以先想想事情的前因、背景、大環境、可行性，再表態。一方面多學學別人看問題的角度，另一方面也在大腦中提煉自己要表達的東西，然后爭取說個八九不離十。

組內開會如此，與人小范圍溝通也是一個道理。想明白自己的立場和要說的東西，再進行溝通，清晰、簡潔的把問題描述清楚，可以給雙方節省不少成本。

溝通，無它，多想，多說。

4. 積累

• 別人的亮點

積累在產品生涯初期能顯出更大的效果。0~2歲的產品經理看看競品、寫寫報告是常有的事，在看其他產品的時候，把能夠打動自己的東西記錄下來，它可以是個文案、登錄窗樣式、交互方式甚至是一段更新日志，將來它們有可能成為你需求的背書。

比如你提了個什么需求，開發說沒有這樣交互的，你就可以說誰和誰是這樣做的。比如你提了個什么需求，開發說沒法實現，你就可以說為啥別人能實現。說白了，積累別人的亮點，可以讓你隨時都有的抄，但是積累的多了，運用的熟練了，這就是你自己的東西了。

• 需求文檔

需求做多了就發現腦子越來越不好使，明明自己做的東西就是死活想不起來邏輯了，這時候就需要翻閱之前的需求文檔了。

我個人的建議是，每一版做了什么改動要記錄下來不論對外更新還是對內說明，每一版對應的需求文檔好好保存（包括原型、效果圖等等）。

假如某個功能模塊迭代了4、5版，要定期回顧需求改動，反思自己前幾版為什么沒這么做，或者為什么把之前的改動又回滾了，中間發生了什么、原因是什么。這種定期回顧和反思，有助于讓你明確之前出現的漏洞，容易總結各種各樣的坑。

總結

除了上面說的之外，我個人覺得“向上匯報、管理上級、積極主動、良好心態、項目管理、發散思維、行業理解、數據分析”這些也都很重要，但并不普適，所以也就不加在這篇文章里了，有機會可以單獨再說。

這篇文章里的好多“比如”都是發生在我或者我周圍的例子，雖然我寫出來了，但并不代表我做的很好。同樣道理，大家看完了也未必真的有用，但是可以當作迷茫時的一個參考。有太多人知道很多道理，但依舊過不好這一生。

做到并且做好了上述幾項，一定能成為優秀的產品助理甚至產品經理，但是后面的路還有很長，希望大家可以一起進步。

PS 1：寫的主要是宏觀維度，具體如何做寫的不多，大家參考即可。切記，別把手段當目的。

PS 2：文章圖片來源于Pixabay，一個很好的免版權網站。

PS 3：謝謝閱讀。

總結

以上是生活随笔為你收集整理的如何做好一条0~2岁的产品狗的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。