編輯導語：產品經理的工作內容之一，就是實現需求方的需求，將假設的功能變為現實。然而，對於不少產品經理來説，隨着工作日復一日的推進，逐漸變成了完成需求，開發新功能的“原型人”，產品經理成為原型人的七大跡象都有哪些呢？你是這樣的產品經理嗎？
發現很多初創互聯網公司都是Feature Factory（功能工廠），很多產品經理都是Axure People（原型人），需求方任意提“需求”，產品經理負責“需求”的實現，胡亂堆砌功能。
最典型的特點是“上線即完成”的心態（PS：一個版本上線了，交由需求方確定後，就什麼都不管了，緊接着開始新的版本開發）。就像只是坐在工廠裏，做出新功能，在流水線上傳遞下去。
John列出了7種“功能工廠”團隊的跡象（或者説產品經理作為原型人的跡象），讀友可以看看，你中槍了麼？
一、沒有業務規劃會議有些產品經理從來沒有參與業務OKR規劃和拆分會議，這其實是非常有隱患的。
因為產品需求的來源大部分來源於業務需求，而業務需求絕不是業務同事拍腦袋產生的，而是基於整體的業務規劃。產品經理需要非常清晰接下來業務OKR，基於業務的方向制定有效的產品迭代計劃。
能達成OKR，整個團隊一片祥和，一旦偏差較大，團隊凝聚力指數下降。所以制定版本迭代計劃絕不是產品經理拍腦袋的，每一步都必須做好追溯。
再絮叨下OKR制定的步驟（建議定季度OKR，做月度拆分）：
- 季度最後一個月的月初（比如6月初），需要和業務負責人溝通下一個季度的業務OKR，在月中進行業務OKR述職；
- 會議中敲定下一季度OKR，並在會後做好郵件確定；
- 產品組依託於業務OKR做產品版本計劃形成產品路線圖並內部宣講確定；
- 並在月底之前同參與確認存檔。
產品版本上線是一個非常重要的節點，標誌着該版本在內部是可用狀態，是否被用户接收？能否達到預期效果？尤其對於主版本號①調整是非常重要的問題。
需要注意兩個方面：
- 一方面是在普測時，邀請核心用户來測試體驗（尤其是B端產品，一定要讓客户試用），如果有條件的話，做下可用性測試②，遇到問題點可以作為接下來優化的版本；
- 另一方面在上線後前三天做好數據整理和分析，看看是否有異常狀況，持續在種子羣/客户羣做好吐槽點收集。持續1周反饋看效果，看後續優化動作。
C端產品做好用户“可用”後，後續通過優化做到“易用”和使其產生“傳播點”。B端產品做好客户“可用”後，後續通過優化達到真正為B端“降低操作難度”和“提高工作效率”。
這才是產品經理需要持續去做的，也是產品經理通過項目能快速成長的（PS：如果是外包呢？如果外包交付後，建議可以後續跟進下效果，並提供下你認為比較好的運營策略和迭代方案）。
①版本號劃分，John給了一張圖説明：
項目覆盤的目的是產品上線一段時間後或者某個活動結束後，項目部都需要有針對性的對項目覆盤。看看項目執行過程中的得分點和失分點，來實現向過去學習，達到能力的提升。
覆盤分為兩個方向，針對產品迭代過程中團隊協作的覆盤、針對產品上線後產生的效果覆盤。
再來把這兩個點贅述下：
- 團隊協作：在協作過程中遇到了哪些問題？哪些可以形成溝通流程並固定下來……（長時間用下來就形成了產品開發流程方案）；
- 線上效果：通過數據看線上的效果怎麼樣？用户對產品的使用怎麼樣？其中反饋在模版的活躍度、使用人數和對核心流程的影響。
不知道大家有沒有遇到這種情況——“哼哧哼哧的把功能清單、流程和原型梳理出來，反饋給業務方，發現業務流程並非如此？”
這個問題80%在於產品經理，主要是這幾個原因：
1. 業務確認環節：深挖業務方提出的需求- 業務方實際的目標是什麼？（通過目標看看方案是否切實可行，證明不是拍腦袋出來的）
- 業務方實際的流程是怎樣的？（按照實際操作場景一一説明，能夠形成實際流程的閉環，看看是否有簡化流程的可能）
- 競品是如何做的？（看看競品的解決方案是怎樣的？效果如何？是否有優化的空間？）
這兒John想再次重申的一點是：抄襲競品不丟人，上線沒有效果才丟人，所以多去拆解下競品。
2. 業務反饋環節：提出初步產品解決方案通過業務流程圖模擬路徑，和業務方確認業務流程圖（二次澄清非常有必要）；通過競品解決方案梳理初步的用户操作路徑並指出和其他模塊關聯的點。
至此，起碼很清晰的瞭解業務方為什麼這麼做？背後的原因有哪些？產品經理應該如何有效的做解決方案。有了業務的確認和自己的專業理解，起碼產品的方向不會有太多的偏差。
John之前和團隊小夥伴聊過：執行永遠只佔49.765%（不到一半），所以前期的梳理和思考很重要，建議多去挖掘下核心。
五、極少正視“失敗”的結果主動背鍋是極需要勇氣的，當產品多方位嘗試始終未產生明顯效果時，還在不停的疊加功能，而未回頭看原因是什麼？
在John團隊中一直遵循這幾個原則：
當投入50%的開發資源來做這個事情時，一定會去想好後手，萬一沒有產生效果，應該如何做補救方案，產品負責人和運營負責人同時背鍋。C端產品當使用該模塊用户少，且不牽涉核心業務，該砍掉就砍掉；B端產品只要有1個人用，就需要想好迭代方案並優化。
當投入少於30%的開發資源來做這個事情時，產品經理應該對這個事情付全部責任。
雖不及項目流產這麼重大的失敗，但是取決於效果反饋，產品經理背鍋不僅僅是流程邏輯等產品工作流沒清晰，更多的是知道做哪些模塊更有意義。正視“失敗”的產品產生的數據，防止更大的失敗。
再一個學會給產品做聚焦和減法——短時間內專注讓重點業務長板更長。當重點業務增長後，再圍繞重點業務建立壁壘。
六、執着於排優先級我們對優先級其實有一個誤區——優先級應該決定當前做最重要的事情，而不是用來安排可以做的事情。優先級也應該是實時需要調整的。
比如在源需求池中，已經規劃了部分優先級的功能清單，產品經理去撈需求做版本計劃時，應該重點根據業務方制定的業務需求來重新整理產品規劃側需求和優化需求，緊急重要程度只是針對於當前階段需求排期來制定的。
儘管業務同事做了緊急重要程度，但是後續的二次確認和澄清是非常有必要的。同樣再説一個點：除了胡亂的提需求外，其實需求是沒有真偽的。只有當前階段是否需要做和緊急程度。所以建議產品經理還是制定源需求池。
七、一次性迭代計劃做產品模塊切記別制定一次性方案。至少要做兩次迭代計劃，便於開發提前做技術預研和給後續迭代方案留坑。否則等業務發展到一定階段，就需要做重構和換技術債的工作了。
再一個想説的是防止做重複性工作，相同屬性的模塊進行有效整合，統一管理。比如拼團和免費領統一收納至營銷管理中。
以上7個方面只是John覺得和產品經理關係很大的點，以上都是需要產品經理去驅動的。尤其是互聯網團隊，產品經理應該扮演最重要的角色，擺正自己的位置，做起工作會得心應手。
作者：John，產品狗一枚，微信公眾號：產品狗聚集地。
本文由 @John 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議