【作者丨Buff先生  】

【來源公眾號丨Buff先生】

【編輯丨善小花】

畢業一年從游戲行業轉行直播行業，從游戲運營轉職產品經理，不管從行業還是職業跨度相對較大，不過到目前為止一切都還算順利，從入職到現在兩個月時間，剛好小組有新項目在開展，所以最近兩個月相對比較忙，今天剛好有空記錄下兩個月來的一些想法。

一、不斷去經歷，去豐富自己

扎實的專業知識通過努力還是可以達到的，但是經驗這種東西，如果你沒有真正參與到一件事情中，就像紙上談兵，你永遠不知道前方的路會有什么樣的坑，盡管你做了萬全的準備，還是會出現你意想不到的坑。

一個真實的案例：之前A直播平臺邀請了重量級的明星B入駐直播平臺進行開播，在活動之前，平臺對此次活動做了大量的宣傳，運營經理也對此次活動做了充分的準備，所有能想到的應急措施、補救方案基本都已準備好，正當所有事項都準備就緒開始明星B的直播時，這個時候明星B卻由于家里網絡問題無法進行直播，導致活動過程中技術花了三個鐘在修復網絡問題上，幾十上百萬的粉絲和觀眾干巴巴地見證了這尷尬的場面。

誰都沒想到，在活動開始之前，明星B家里的網絡受到直播平臺競爭對手的惡意攻擊。

過去一年從事游戲運營的經歷，接觸到的工作領域還算挺多的，包括產品調優、活動策劃、用戶運營、社區運營等，甚至有時候由于合作同事忙不過來，還需要幫忙分擔一些分外的工作，雖然我覺得工作分工明確是有必要的，但特殊情況下，為了結果導向，為了一起把一件事情做好，可以在自己的能力承受范圍內適當的幫助團隊伙伴，不要急著劃清界限，讓自己多去接觸更多的東西，這未嘗不是一件好事。

親身經歷一些事情，跟作為一個旁觀者了解到的東西是完全不一樣的，這些經歷也許會在未來成為你不可復刻的優勢，對于職場新人來說，更應該如此，讓自己不斷去經歷，去變得更豐富。

二、學會讀懂上司話中背后的意思

工作中，經常會遇到這種情況，上司跟你說某產品的新出的特色功能做的不錯，然后讓你看看如何在我們的產品中也加入這樣的功能。于是你開始研究這個特色功能，覺得效果確實很不錯，然后開始按照老大的建議加入了差不多的功能，等到功能上線后，才發現得不到預期的效果，最后只能無奈砍掉了辛辛苦苦做出來的東西。

這個時候你應該埋怨老大的建議不合理嗎？當然不是，因為背鍋的永遠是做執行的……在開始執行之前應該先讀懂上司話中背后的意思。

簡單了解下背景情況：一般上司是要背負KPI的，可能是產品的DAU、用戶付費率、營收、營收離散化等等，而且上司日理萬機，主要承擔統籌把控的角色，所以在產品的細節方面上可能沒有我們了解的更深入。

因此上司提出了增加新功能的建議，并不是真的覺得這個功能好玩，可以借鑒一下，而是因為上司看到了該功能在產品某方面，如在DAU上有不錯的表現，對完成我們的產品DAU的KPI可能有所幫助，但是由于上司對自身產品細節的了解并不是很深入，所以有時候提出的建議合理性是需要評估的，所以這個時候就需要我們去仔細分析上司的目的，以及我們如何達到這個目的，即使你最終分析出來的結果完全反駁了上司的建議，提出了完全不同的產品方案，但也好過做出一個沒有價值的產品。

讀懂老大的話能幫助你找到工作的正確的方向，更有目的性地完成工作，避免耗費了大量的精力、資源卻最終卻以失敗告終的情況，先三思而后行，真正優秀的人是花70%的時間在思考問題上，30%的時間在思考方案上，先思考事件的本質意義，然后才開始付諸行動，不要急于一時，特別是在高成本的事情上。

三、關于產品需求

最后想聊聊從事產品經理職位兩個月來對產品需求的一點感受。

1、可行性、可用性、有價值性的產品驗證

這一點也是我最近讀了《啟示錄》這本書后感受比較深刻的，在產品正式開發之前要先進行產品驗證，證明產品的可用性、可行性、有價值性，不要盲目自信地等到產品開發出來再進行測試，產品一旦開發出來進行較大的改動基本是不可能的，所以一定要在產品開發之前就做好產品驗證的工作。

可用性測試：需要交互設計師和產品經理密切合作，設計出符合用戶習慣，或者改良用戶習慣的產品，讓用戶知道怎么使用產品，當然有些公司可能沒有交互設計師只有產品經理，所以這就要求產品經理要多去提升這方面的能力。

有價值性測試：設計出來的新產品是否解決了用戶的需求痛點？是否讓用戶渴望去使用？如果用戶使用了之后仍然選擇使用其他競品，說明產品還不合格，在進行開發之前，可以先提前制作高保真的產品原型，邀請十個左右的目標用戶群體進行測試、驗證，驗證產品的創意、價值，只有用戶真正喜歡并且渴望去使用的產品才值得進一步開發。

可行性測試：在產品說明文檔定稿之前一定不要跳過技術，我自己就吃了這方面的虧，當時在做產品需求文檔定稿的時候，完全就是產品、運營討論確定好就拿去給技術進行排期開發，等到技術看到需求文檔的時候，才發現有一些技術根本實現不了，最終只能重新修改需求，重新定稿，導致進度被迫拖慢。所以在產品需求文檔的評審階段就應該邀請技術負責人或架構師一起進行討論，他們最清楚最新的技術，了解哪些技術存在可行性風險，幫助我們在做產品決策的時候提供更好技術解決方案。

2、如何正確提需求

正好兩個室友也是程序員，上次閑暇時間也跟他們一起探討了關于產品需求的話題。

①需求文檔一定要周全、細致

技術是執行、產品是策劃，技術在開發的時候需要考慮到事件所有可能的情況，不然代碼就很容易出bug，而產品經理的思維有時只關注到他們想要達到的結果，而忽略了其他可能的狀況，比如：

產品可能只關注這項功能需要給用戶展示什么樣的內容，而技術會考慮到網絡穩定、斷網的情況分別給用戶展示什么內容，什么提示。
又或者產品只考慮到用戶的某項數據指標需要做什么樣的處理，而技術會考慮到數據指標有值、空值的情況需要分別做怎樣的處理。

所以在寫需求文檔的時候，多站在技術的角度上思考問題，盡可能詳細地闡述所有可能出現的狀況，并分別給出解決方案。

②讓技術感知到需求的緊急程度

在技術的心中他們有自己的緊急排行榜，可能是按產品經理的性別、顏值進行排名的，也可能是按需求方的職級排名的，所以如果你的需求特別急的時候，要讓技術感知到。

A、跟技術講清楚需求急的原因，是急著上線，還是需要配合其他功能的實現，讓技術明白為什么急。

B、跟技術約定好完成時間，一定是一個確切的時間，而不是“下星期”、“下個月”之類的，只有讓對方做了口頭承諾，才會迫使他們去兌現承諾。

C、多跟進需求的進度，每天上班主動跟技術了解進度，了解是否有遇到什么問題導致開發停滯，技術的日程計劃等等，下班之后再次了解今天一天的進度，你只有多跟進才會讓技術感知你的需求重要緊急程度，當然也要適當跟進，不要讓技術覺得你很煩。

③避免修改需求

中途修改需求是技術的大忌，因為可能意味著做出來的東西需要全部推翻重來，所以能不改需求一定不要改，先思考有沒有其他解決方案同樣可以實現，迫不得已才改需求，很多情況下更改需求的根本原因在于定稿的時候沒有確定清楚，特別注意要在定稿前跟所有相關的人員（尤其是老板）確定清楚需求才開始跟技術排期開發。

同時，需求中待確定的地方要標記出來，不然技術會按照他們的想法去實現，到時候再要求更改也是很不好的。