起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品經理成為原型人的七大跡象
編輯導語：產品經理的工作內容之一，就是實現需求方的需求，將假設的功能變為現實。然而，對于不少產品經理來說，隨著工作日復一日的推進，逐漸變成了完成需求，開發新功能的“原型人”，產品經理成為原型人的七大跡象都有哪些呢？你是這樣的產品經理嗎？
發現很多初創互聯網公司都是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 協議
66666
nn