我發(fā)現(xiàn)身邊許多產(chǎn)品經(jīng)理工作時間長了后，很少有一部分人會總結出自己的方法論，反而就是一個需求又一個需求的做，變成了一顆產(chǎn)品研發(fā)中的螺絲釘。

其實我們在完成一個產(chǎn)品設計到研發(fā)上線，許多錯誤都是會重復犯的，這些錯誤會影響直接自己在產(chǎn)品工作團隊的影響力甚至是所尊敬程度，比如你是否就有遇到過一些同事因為你的產(chǎn)品經(jīng)理工作方法，被吐槽你不專業(yè)。

恰好，作為一個小公司的老板和產(chǎn)品負責人，把我經(jīng)歷過那些影響產(chǎn)品經(jīng)理靠譜、別人尊敬程度分享下

1.不重視需求文檔

如果想避免自己被研發(fā)團隊說是一個嘴炮，那么就得十分重視需求文檔，首先就把需求文檔的格式、排版以及結構都要羅列寫出來，不能少。

需求文檔的字數(shù)不需要太多，同時我們不能為了字數(shù)而寫需求文檔，但是需要把一個功能設計、系統(tǒng)設計將清楚，包含里面的業(yè)務流程、系統(tǒng)功能模塊數(shù)量、各個功能模塊是干什么的講解出來。

2.原型一定要有，而不是胡亂畫

在有的公司，產(chǎn)品經(jīng)理會坐在設計師旁邊，通過口述的形式，指導設計師幫忙完成自己的產(chǎn)品設計DEMO方案；還有的公司因為沒有標準，就導致原型設計變成了高保真原型，直接跳過了原型設計圖的概念。

這就會大大降低產(chǎn)品經(jīng)理的專業(yè)度、和產(chǎn)品設計環(huán)節(jié)存在感。因為一個好的產(chǎn)品設計方案，一定要經(jīng)過和業(yè)務、技術、老板等多方面確定溝通后輸出的，所以不能是因為競品長什么樣子，我們就馬上做，產(chǎn)品經(jīng)理需要去找到對應的同事評估，同時原型設計圖一定要漂亮，包含在排版、布局、色彩使用上。

布局：

布局應該符合用戶在實際場景的操作習慣，比如移動端的APP原型設計應該符合安卓、iOS的系統(tǒng)交互規(guī)范，導航欄位置、返回按鈕、放大、縮小操作等應該一致。

排版：

需要和實際上線所達到的排版一致，比如信息流是列表式，那么原型設計方案應該是列表式

色彩：

顏色不超過3類顏色，比如可以通過黑色、淺黑、灰色來表達頁面里面的按鈕、功能入口和交互操作。

原型設計應該可以在幾乎沒有產(chǎn)品經(jīng)理講解的情況下讓開發(fā)、設計師等閱讀者看到后即可理解原型表達的什么功能， 產(chǎn)品是用來提供什么服務的，同時里面的文案、排版都要和實際上的產(chǎn)品數(shù)據(jù)一致，不要用XX、或者省略號等來代替。

如果想增加產(chǎn)品經(jīng)理自己的信服力，能夠得到工作同事的尊重，原型、文檔的能力是一定要達到以上面的標準的。

因為實際工作里，產(chǎn)品經(jīng)理工作和大家都是平級，只有自己再工作中投入了時間、精力，大家能夠認可你的工作價值，而這兩點是你工作結果的展示。能夠給出一份實實在在的需求文檔、和原型設計方案，至少降低了實際開發(fā)過程中需求的偏差，同時還增加了需求的可行度。

3.具備產(chǎn)品經(jīng)理的owner意識

提到這一點，有可能產(chǎn)品經(jīng)理會說：“我自己很負責呀，從產(chǎn)品設計到需求上線我都跟著的，有什么問題我都會及時收集需求，并且進行規(guī)劃?！?/strong>

但實際上真正的產(chǎn)品經(jīng)理owner意識，我認為一定不僅是完成自己的需求，還要善于接受外部的需求，比如業(yè)務方的需求、運營的需求，在一個已經(jīng)上線并運營的產(chǎn)品里，往往產(chǎn)品經(jīng)理的需求大部分是來自業(yè)務方的，我見過不少產(chǎn)品經(jīng)理為了避免麻煩，會把需求推給別人，許多PM只是在為自己的需求做產(chǎn)品經(jīng)理owner，但是沒有考慮到業(yè)務。

可是只有讓業(yè)務用起來的產(chǎn)品，產(chǎn)品的價值才能體現(xiàn)。

能夠在下班時間，可以為其思考優(yōu)化項和改進建議，這也是非常有少人能做到的，雖然我不是提倡大家加班，但產(chǎn)品經(jīng)理職業(yè)就決定了你要對你工作的產(chǎn)品負責，只要產(chǎn)品上線了，都應該處理，在大廠里每個互聯(lián)網(wǎng)產(chǎn)品都有7*24小時的運維工程師維護，正是因為這些產(chǎn)品隨時都有用戶訪問、和用戶使用，還有大量的訂單交易，如果產(chǎn)品或系統(tǒng)出現(xiàn)問題就會直接影響公司收入，甚至是造成口碑大幅度下降。

4.不重視測試環(huán)節(jié)

對于一個新產(chǎn)品來說，要想極大的提升用戶留存率，那就一定要重視剛剛上線的用戶體驗和基礎操作流程。要是新用戶剛注冊登錄就發(fā)現(xiàn)了產(chǎn)品BUG，那么自然就會快速流失了。

所以PM應該特別重視測試，不要把測試的工作丟給測試工程師，自己只做功能驗收。和前面的產(chǎn)品owner意識相關，這也會導致產(chǎn)品上線效果不好，要么就是功能邏輯有問題，要么就是功能按鈕和文案不對，或者就是數(shù)字和金額對不上。

因為及時通過縝密的需求評審、開發(fā)評審，仍然有一些需求會隨著政策、技術實現(xiàn)等問題無法完成。所以在測試環(huán)節(jié)還能發(fā)現(xiàn)產(chǎn)品設計不合理的地方，可以再測試版本里進行修改，要么就變成新的優(yōu)化需求到下一個版本實現(xiàn)。

還有的產(chǎn)品上線時間長，積累了大量的功能，產(chǎn)品經(jīng)理并不熟悉以前的舊流程和功能設計，只知道對于新功能，所以還應該和測試同學一起評估新版本在以前的主流程是否有影響。

5.業(yè)務未來的發(fā)展和系統(tǒng)的可維護性

產(chǎn)品剛開始立項，我建議一定要考慮產(chǎn)品的業(yè)務是在什么行業(yè)，而找到最佳的技術選型，比如是用單體架構還是微服務的形式，在當前團隊資源下，應該優(yōu)先選擇哪一個產(chǎn)品形態(tài)、用什么樣的技術語言， 這都影響了未來的維護成本。

在這一點我們PMTalk就深受其影響。早期團隊因為只有PHP開發(fā)，導致后續(xù)系統(tǒng)的維護性在沒有PHP開發(fā)后，變得很差，除非招募PHP開發(fā)同學，則沒有辦法完成系統(tǒng)新功能的建設和維護。

還有就是早期選擇了開源系統(tǒng)，以為開源系統(tǒng)會降低開發(fā)成本，結果就導致后期功能迭代變得異常復雜，開發(fā)者需要先查看以前的源碼再定位問題，進行修改，變得非常復雜。

所以互聯(lián)網(wǎng)軟件的產(chǎn)品經(jīng)理， 一定要盡可能把未來的業(yè)務、用戶量、服務體量、用戶使用場景描述清楚，通過和后端開發(fā)或者架構師幫你評估，減少你走彎路，要么就是產(chǎn)品經(jīng)理自己要懂技術自己可以進行修復。

而因為技術選型失敗，導致需要花時間、金錢來重構特別影響士氣，因為功能沒有新增，業(yè)務使用老系統(tǒng)體驗差，還需要花時間等待。

以上，總結了一個靠譜的產(chǎn)品經(jīng)理的5點基礎。希望可以幫助到你，成為一個公司里面受人尊敬的產(chǎn)品經(jīng)理。