產品的目的、使用者、價值,如果不知道,產品經理該做的事就就是繼續當個人類學家,好好了解你的場景、用戶。

但即便產品經理要打造一個自己用的產品,時常還是會遇到阻礙,甚至發現「產品不符需求」,為什麼呢?我認為是產品迭代的方法錯了。

為了滿足痛點,在確知產品需求之後,該做的事有三件:

  1. 針對場景展開Brain Storming。
  2. 為需求確認優先級。
  3. 執行工作清單。

針對場景展開Brain Storming

很多人對Brain Storming有很特殊的想像,覺得一定要有很多人參與,但事實上當理解產品目標的人不多、產品簡單的時候,拿出一張白紙寫下產品核心的目標,四周依著直覺寫下相關的想法,檢視一次,再從外圍寫下一圈相關的想法,反覆兩三次,就可以得到許多本來沒有想到的問題。

重新依照主題整理,並且依需求複雜程度決定是否再拿次要的主題發想,就可以整理出一份完整的需求清單。

為需求確認優先級

問自己:「這個需求沒有能不能滿足主要場景?」

如果可以,就不是最重要的需求,先排出非有不可的需求,第一個版本頂多就做這麽多,甚至可以找用戶再確認一次,刪去更多不必要需求。

但沒有排上第一個版本的需求不是真的刪去,列入Backlog,隨著產品發展,Backlog可能很快就可以排出接下來兩個版本的內容,讓產品發展更平穩。

執行工作清單

很多產品經理只做到確認需求,卻無法落地,差異就在有沒有把需求轉換成工作清單,並且一一執行、確認,其中除了需要開發產品的業務,更重要的是成果,例如ERP,需要使用者 + 系統才能真正閉環,就必須把關注的目光延伸到「使用者的線下行為」,如果流程有問題,產品其他設計都是白費、毫無意義。


了解用戶主要場景後,產品經理應該花時間深化需求,發散需求後安排優先序,產品才能有型,而唯有細緻安排工作,反覆驗證實際產品應用場景是否如同推想、訪談,最終才能滿足用戶真實的需求。