分享產品策劃的3大流程 產品策劃的流程有哪些?

本文筆者梳理拆解了自己的產品策劃流程 , 并給出了自己對各流程的思考 , 希望能夠給你帶來一定的啟發 。
記得剛開始做產品出需求方案的時候 , 上來就開始畫原型寫文檔 , 在寫的過程中發現某個交互沒想明白或者漏了一部分邏輯 , 然后回過頭來再修改或者補漏 , 這樣前前后后折騰好長時間 , 終于做完了一份完整的方案 , 等重新檢查的時候 , 發現又漏了某個地方流程有問題 , 于是又改 , 反復折騰之后終于完成了初版 。
然后等到需求評審的時候 , 面對技術爸爸們的各種疑問如坐針氈 , 發現又漏了好多的邏輯和細節 , 等到需求評審結束的時候 , 已經被需求折磨的死去活來 。
出現這樣的問題 , 一是因為剛開始做產品方案設計 , 基礎產品交互規范的熟練度不夠 。 還有就是急于完成任務 , 對于需求或功能的整個沒有思考的很明白 , 太過于專注方案以及功能本身的實現 。
后來做的需求多了(踩的坑多了) , 慢慢的修正自己過去在做產品方案的中一些問題 , 也跟身邊同事交流 , 整理了一套比較符合自己的產品設計流程 , 可能不適用所有的場景 , 是我目前用的比較多的一套流程 。
一、“看”競品說到看競品 , 很多人的第一反應是要抄么?我們一般剛開做需求方案的時候 , 常見的套路就是選幾個相關的競品或產品 , 對著某個功能抄一遍 , 然后形成自己最終的方案 。
這時候我們的注意力還是方案或功能實現本身 , 并沒有深入的思考內在的邏輯以及背后的動機等等 。 就像上學的時候 , 交作業前拿過來同學的作業對著答案直接抄了上去 , 并不會再去想答案背后的演算流程 。 但是也有老師會說 , 同學們你們抄作業可以 , 但是你們一定要弄明白抄的答案為什么是這樣 。
看競品也是同樣的道理 , 在開始策劃一個需求方案的時候 , 我會找到競品功能或者相關的功能 , 深度的體驗相關的功能 , 弄明白整個功能的邏輯以及流程 , 體驗功能交互上手的感覺 , 對功能的效果有個初步的判斷 。
同時要做好記錄 , 對于競品做的好的點以及關鍵點的實現邏輯做好收集記錄 , 然后對同一功能或模塊在不同平臺的實現方式或者關鍵點的差異盡可能的收集資料 , 盡可能作出符合邏輯的思考和解釋 。 做完這一步對需求整體的實現邏輯以及流程有了初步的掌握 , 可以開始下一步 。
舉個簡單的例子:策劃登錄注冊功能 , 同樣的登錄注冊功能可能在不同的產品上具體實現的業務邏輯或流程都會有不同 , 注冊門檻的差異、注冊流程的不同、注冊信息的、登錄場景的不同等等 , 都跟具體產品的需求場景和特性有關 。
二、理思路做完競品調研后 , 就可以著手開始自己需求的策劃 。 在對業務邏輯以及功能流程有一個大概把握的前提下 , 再結合自己產品當前的現狀以及實際場景從整體到局部開始進行(說到整體到局部的系統化思維 , 推薦一本很多人都看過的書《金字塔思維》) 。
從需求背景、需求目的、功能流程、功能list、關聯需求等等 , 開始整體思路的梳理 。 功能list以及功能流程 , 在競品調研的基礎上是最容易出整體思路的模塊 , 也是產品功能設計本身 , 但是需要注意的是 , 產品功能本身只是需求策劃其中的一部分 , 不是需求全部 。
我經常踩坑是 , 關注需求流程和實現本身 , 而忽略和需求相關聯的其他需求點和事項 。 比如 , 新的需求方案對于已有需求影響、新老版本兼容的問題、涉及的財務、運營等各個流程的變動問題、功能的推廣問題等等 , 以上都是需要根據需求的實際背景事先進行考慮以及規劃的 。
還有經常被忽略的一點就是需求價值以及效果的衡量 , 我剛開始做產品經常有的問題就是埋頭于如何實現整個需求 , 對于需求的價值以及效果很少考慮 , 做了很多東西但是并沒有好好回顧其中的價值 , 對于工作的回顧和產品的認知是很不利的 。
等梳理完框架以及流程之后就可以先跟boss或相關同事提前進行溝通 , 在大方向以及思路一致的情況下再開始擼需求文檔 , 如果在思路框架都沒有保持一致的情況下 , 就直接上手開始畫原型擼文檔 , 后面如果一旦思路或者框架需要調整 , 可以快速的進行修正 。
接上面的例子:關于登錄注冊模塊需求的實現 , 做完競品調研 , 根據自身產品特性可以確定功能模塊以及流程 , 比如內容型產品 , 前期降低登錄門檻 , 可以直接使用第三方登錄 , 同時獲取用戶的基礎信息以及注冊賬號 。

推薦閱讀