不少其他崗位的同事與產(chǎn)品打交道時，總以為產(chǎn)品的工作很容易做，甚至有人就因為這樣直接轉(zhuǎn)崗。但轉(zhuǎn)過來后才發(fā)現(xiàn)，想做好產(chǎn)品經(jīng)理，其實也不是那么容易的，需要經(jīng)歷這三個階段。

如果你也做過產(chǎn)品的甲方（這里主要指b端），也就是產(chǎn)品業(yè)務(wù)需求方，你是不是常常覺得“好像產(chǎn)品經(jīng)理這個活兒我也能干啊”？

沒錯，我就帶著這個錯覺信心滿滿的轉(zhuǎn)行做了產(chǎn)品經(jīng)理，后來我發(fā)現(xiàn)，從產(chǎn)品甲方到產(chǎn)品經(jīng)理，大概都會經(jīng)歷3個階段：

1. 以為自己什么都能干
2. 發(fā)現(xiàn)自己好多干不了
3. 踏實聚焦干好幾件事

一、以為自己什么都能干

這一階段通常是轉(zhuǎn)行前到成為產(chǎn)品經(jīng)理的前3個月。結(jié)合我的職場心路歷程來說，在互聯(lián)網(wǎng)二線廠做了1.5年的B端產(chǎn)品業(yè)務(wù)Owner后，產(chǎn)品0到1、1到n的經(jīng)驗攢了不少，尤其是如何給產(chǎn)品找bug、如何提優(yōu)化需求、如何驗收需求、如何培訓產(chǎn)品使用，這些經(jīng)驗，基本都可以平移過來賦能產(chǎn)品經(jīng)理的身份。對新接手的1到n階段產(chǎn)品，能很快發(fā)現(xiàn)存在的問題（畢竟是新用戶，對那些初次使用沒看懂的功能設(shè)計，基本等同于交互不清晰），一副磨刀霍霍大展拳腳的架勢。

二、發(fā)現(xiàn)自己好多干不了

這一階段是發(fā)生在作為產(chǎn)品經(jīng)理經(jīng)歷第一個成規(guī)模的迭代時。首先是需求評審時來自研發(fā)的轟炸。復雜的功能，肯定涉及前后端的多重交互，對于中途接手的產(chǎn)品經(jīng)理新人來說，是很難分辨出哪些邏輯是接口實現(xiàn)的，而這些接口依賴的字段又是不是現(xiàn)成的？涉及增改字段的，這個需求的耗時就會拉長。這時會發(fā)現(xiàn)梳理出來1個需求，最終實現(xiàn)能拆分出5個以上子需求來。

就算是評審基本通過了，實現(xiàn)過程中表面上輕易一改，動輒就與歷史邏輯、在先功能沖突，一些藏在代碼中的隱形邏輯就會跳出來阻止，讓人不得不接連感慨“居然還會這樣”。最終為了趕上線時間，不得不接受研發(fā)給出的退而求其次的實現(xiàn)說辭：這次先這樣，下次、下次再說。

三、踏實聚焦干好幾件事

這一階段是發(fā)生在入職一年后。逐漸開始恍然大悟原來過去的邏輯雖然不太符合你自己的習慣，但也確實有存在道理，一些自以為的優(yōu)化點，實際上可能是干掉了一些既有功能。如果說總結(jié)幾條從產(chǎn)品甲方轉(zhuǎn)型到產(chǎn)品經(jīng)理的tips，我認為要做好以下幾點：

1.講好故事。“需求”的英文翻譯是“story”，每創(chuàng)建一個需求，其實就是在講一個故事，包括這個故事的背景、故事發(fā)生的場景“6個W”要素、故事的主人公、故事能升華的意義……作為故事的敘述者，要把故事給研發(fā)講明白，讓他們也能充分認可這個故事的邏輯；要把故事寫清楚，這樣無論何時回顧才能清楚；要把故事給用戶講動聽，相比于“我告訴你這個功能能支持xxx”不如強調(diào)“你在xx時會用到這個功能，你因為要xx遇到不便時這個功能能幫你xxx”，把“我有什么”轉(zhuǎn)化為“你需要什么”的講述。

2.要有邊界感。需求中一個檢索詞的長度、屏幕劃詞的范圍、展示的最大條數(shù)等等，均需要考慮極值情況；需求的實現(xiàn)有邊界，同樣一個迭代的版本也要有邊界，我的經(jīng)驗是，如果新功能點已經(jīng)能在最核心的位置A實現(xiàn)，對于可加可不加的位置B、C，新上線時就盡量不加——這樣才能盡量控制工作量和bug率。

3.懂業(yè)務(wù)、懂業(yè)務(wù)還是懂業(yè)務(wù)。作為B端產(chǎn)品，不論是需求方還是產(chǎn)品經(jīng)理，往往直接對接的人都不是真正的用戶，這也是B端產(chǎn)品工作的痛，總是跟真實用戶有距離，通常是憑借幾個場景的畫面去想象使用場景。問問自己，你真的用過這款產(chǎn)品嗎？你要真的讓自己帶著用戶真實使用意圖去操作一遍，才會感知到這款產(chǎn)品的好與壞，注意：不要用測試數(shù)據(jù)、不要用臆造的使用流程、不要淺嘗輒止的操作。

今日分享完畢，祝愿大家都能順利轉(zhuǎn)型！