挖、判、定,三步做好產品迭代(內附需求確認單、迭代發布單)
經常有人說“產品就是自己的孩子”,作為產品經理,我們確實要把產品當成自己的孩子,不僅要負責孩子的“出生”,更要負責孩子的“成長”。對于一個產品來講,迭代是產品成長的必經之路。接下來,筆者分享一下自己的經驗,希望對大家有幫助,感謝支持!
為什么要迭代?(1.0版本–2.0版本)
解決遺留問題(1.0版本)
產品經理不是萬能的,產品首次上線(即1.0版本)不可能是完美的,譬如功能缺失、前后端不能很好的銜接等問題,但往往受時間、KPI等因素影響,產品又必須上線。一般而言,產品1.0版本的上線會留下諸多問題(未修復的bug、未滿足的需求、未開發完成的版塊等),這些問題要通過小版本迭代來解決。
新增需求或功能點(1.1–1.N版本)
因為每個公司的架構不同,在這里我針對我們自己公司的實際情況為大家舉例說明。產品1.0上線后除了解決遺留問題,其他相關部門的需求會“接踵而至”,運營會提運營需求、業務會提業務需求、財務會提財務需求,這些需求需要通過迭代來實現。
產品本身迭代(2.0版本)
在1.0版本到2.0版本的過程中,產品要配合運營、業務等其他部門做很多工作,譬如用戶調研、需求調研、市場調研等。在做完這些工作之后,產品要把整個環節中遇到的問題解決掉,迭代。而在整個產品的發展周期中,市場在變化、思維在變化、理念在變化,我們要保證產品與時俱進的同時,大膽創新。
如何迭代?
流程:各部門提出需求→產品匯總需求→發起需求評審會→確定需求,判斷優先級(簽訂需求評審單)→產品設計原型→原型評審→UI評審→開發
在整個產品發展過程中,做好迭代其實并不難,關鍵是迭代流程一定要規范,作為產品經理需要“挖–判–定”
挖:挖掘用戶對產品的真實評價及建議,挖掘讓用戶“爽”的爆點等。
我們在產品1.0發布后做過一次問卷調研,雖然很多用戶沖著獎品完成了問卷,但是收效甚微,很多用戶敷衍了事,最終只收到了一堆毫無用處的建議。后來我們就采取線下一對一的溝通,先從線上(QQ群、微信群)選擇了一批較為活躍的用戶,然后一對一的面談,了解用戶的真實體驗及感受,針對產品分析問題,然后解決。
除了用戶,還要做好與其他部門的溝通,找到各個渠道反饋的問題,共同商討解決方案。
判:判斷所有需求的可行性、明確性。
很多用戶會提出一些“奇葩的需求”,而這些需求我們無法滿足或者很多需求是不合理的,在這個過程中,我們要學會過濾。在得到需求后進行需求可行性判斷,明確此需求確實有必要并對產品發展有建設性作用。
定:確定需求,評審會。
在整個1.0–2.0的過程中,我們經歷最多的會議是“需求評審會”,這個會議需要公司相關部門的領導及核心人員參與。各部門提出需求,由產品經理匯總需求、發起會議,共同評審。需求評審的目的在于不同部門、不同人對同一需求的看法和見解不同,站的角度也不同。如果一個需求提出后,各個部門一致通過,那么這個需求就是可行的。
在我得個人經歷中,關于產品迭代有很多經驗與大家分享:
- 做好用戶溝通,多種方式、多渠道了解現存問題,篩選有價值需求。
- 做好迭代規劃,根據時間節點,確定需求優先級,跟進研發排期及上線。
- 做好需求評審,確定需求后簽訂需求確認單,最大限度避免需求變更,降低開發成本。
- 做好原型評審,確定原型設計與需求相符,符合需求方要求。
- 做好上線驗收,確保功能的準確完善,無bug、無遺漏,符合上線要求。
整個大流程已經分享完,在產品迭代的過程中,產品經理應該始終站在全局的角度對待問題,產品的完善需要迭代,一個成功的產品背后必定有一個敢于探索、善于學習、勇于創新的主導者、先行者、開拓者,這個人就是你。
附:產品迭代發布單
作者:王照宇 ?同策房產咨詢股份有限公司產品經理,坐標上海。曾先后從事過教育類、社區類、房產類APP的研究設計。
本文由 @王照宇 原創發布于人人都是產品經理。未經許可,禁止轉載。
學習了,真的很規范。
作者個人微信公眾號:王照宇(ID:QQvipstar)
對版本迭代的控制,確實有學習之處,點贊
感謝支持
作者能不能留個聯系方式啊
微信:13333886718
流程很清晰,謝謝分享
感謝支持
很不錯,值得去學習。 ??
感謝支持
很需要發布單這種范本,感謝!
??
很不錯的分享,需求確認單和迭代發布單超贊
建議自己根據實際情況、不同場景而定