第一階段：產(chǎn)品執(zhí)行&用戶體驗
0-2歲的產(chǎn)品er大部分處于這個階段，執(zhí)行上面的想法，推動產(chǎn)品方案上線落地。這個階段對于產(chǎn)品的好與壞的評判標準，基本是基于自己作為小白用戶的視角。
如何避免在這個階段被開發(fā)吐槽：
1.1 想清楚
方案idea可能是上面拍的，但方案細節(jié)是你自己定的，想清楚每一個交互細節(jié)和異常流，不要說想不全，可以拿著方案先和架構(gòu)開發(fā)測試簡單聊聊。
1.2 寫清楚
寫清楚的意思是每一個流程每一個步驟都寫的條理清晰。拿一個普通的展示頁面來說：
流程說明，主流程、分支流程、異常流統(tǒng)統(tǒng)寫明；
跳轉(zhuǎn)說明：點擊返回/編輯/保存/取消等，分別觸發(fā)什么。彈框是怎么進入怎么消失的。toast顯示幾秒，停留在當前頁還是返回上一頁；
顯示規(guī)則，這個頁面包含哪些元素，都是哪些字段，格式大小要求是什么，是否換行全部展示，過長或過短怎么展示，異常輸入怎么顯示、空態(tài)頁顯示什么等等；
排序規(guī)則：第一排序優(yōu)先級是什么，第二排序優(yōu)先級是什么，正序還是倒序排列等等；
分頁規(guī)則：一頁最多展示幾個，一次拉取幾個。下拉還是上滑刷新，是全頁刷新還是半頁還是指定區(qū)域刷。
等等等等………這還只是一個普通的前端展示頁面，涉及后臺邏輯的細節(jié)可以寫的更多。建議：把評審會上被開發(fā)問住的點都記錄下來，整理起來，以免下次寫文檔有所遺漏。同時可以多看看身邊優(yōu)秀的產(chǎn)品經(jīng)理寫的文檔。
1.3 講清楚
每次開發(fā)評審少則7、8人，多則30多人，緊張怯場一次兩次可以諒解，長此以往就要反思自己。聲音是否洪亮，是否照顧每個聽眾的反應，是否準備充分，把該強調(diào)的細節(jié)都強調(diào)了？文檔要寫的條理分明，評審要講的邏輯清晰。例如：這個頁面涉及哪幾個功能，需要哪些開發(fā)支持，主流程是什么，異常分支是什么，特殊的規(guī)則和要求是什么。建議：自己講完可以邀請關系好的開發(fā)復述一遍，就知道哪些地方要著重再講一遍。另外，多觀摩觀摩別人是怎么評審的。
1.4 溝通溝通
溝是方式，通是結(jié)果。結(jié)果不對，方式肯定錯誤。那什么是好的溝通方式？不卑不亢。產(chǎn)品經(jīng)理和項目組所有人都是平等的，你不是指揮他們干活的，也不用刻意討好。平等的意思是，發(fā)自內(nèi)心的尊重，耐心聆聽的理解，相處自然舒服不添亂。
剛?cè)胄袝r，向技術(shù)提需求也會買零食請吃飯撒嬌賣萌。后來漸漸發(fā)現(xiàn)，最佳的“討好方式”是成為一個靠譜的產(chǎn)品經(jīng)理。
第二階段：產(chǎn)品架構(gòu)&技術(shù)實現(xiàn)
之前有個同事，是清華計院畢業(yè)的產(chǎn)品er，他曾笑言，某次提需求時，開發(fā)說實現(xiàn)不了，他當場指導開發(fā)怎么去寫代碼 = =！
聽得我好生羨慕，吭哧吭哧跑去學html學python，走了不少歪路。
產(chǎn)品需要寫代碼很牛逼么？不需要。產(chǎn)品需要懂技術(shù)實現(xiàn)嗎？需要。
這是兩回事，一個優(yōu)秀的產(chǎn)品經(jīng)理不需要會寫代碼，但要清楚技術(shù)的實現(xiàn)方案，以及，能夠從業(yè)務角度，專業(yè)的回答很多個為什么為什么。
建議：
每次需求評審完，技術(shù)們都會私下再碰定下接口。產(chǎn)品er為何不索性再拉個技術(shù)方案評審會，聽下前端客戶端服務端是怎么商量確定接口，一來了解各自分工，二來了解數(shù)據(jù)流轉(zhuǎn)。別覺得開發(fā)定接口和產(chǎn)品沒關系，這直接關系到產(chǎn)品實現(xiàn)的交互細節(jié)。
大公司的產(chǎn)品er估計拿不到線上數(shù)據(jù)庫權(quán)限，但可以私下找開發(fā)要開發(fā)環(huán)境或測試環(huán)境的數(shù)據(jù)庫權(quán)限。要了數(shù)據(jù)庫權(quán)限，不是用來裝逼的= =！ 請看下你所負責的項目，共涉及哪些表哪些字段，這些數(shù)據(jù)的調(diào)用、流轉(zhuǎn)、更新是怎么樣的。
以上，簡單來說：看看API文檔