產品心得：不存在的需求不要亂接

Photo by Katerina Holmes: https://www.pexels.com/photo/women-taking-piece-of-pizza-with-tomatoes-and-cheese-5907901/

上週剛完成了 Q3 的 performance review，回頭看看對產品的 domain knowledge 更加熟悉，對資訊承接、sprint management、IC 的部分更加上手，不過對產品管理能力的考驗才正要開始。

我所處的工作環境，比較不是將產品從 0 到 1 地打磨，而是從 1 擴張到 n。這個階段，產品已經上市，對外要面對線上環境的真實抱怨、內部則有無限的產品發想與機會點。這時候 issue 跟 feature request 同時進來 kanban，很容易陷入「我主動去解決了一張票，我很棒」的虛假生產力狀態。

故事來自於其他部門發來的需求：

目前會員資料少搜集了一個資料，讓我們難以認識消費者輪廓，需要在資料庫多加一個資料欄位。

去年的我會像個總機一樣，開票，問工程師何時完成。

現在的我不一樣了！我看著那張票，心想自己對產品前後端有更多的認識，我有能力把需求轉化成更完整的規格：

1. 詢問需求方需要這個資料的原因（對方答：想分析 A 市場分隔下消費者的消費行為）
2. 從現有資料庫提供有可能回應對方需求的間接資料（比如想分析活躍使用者，有可能藉由不同的行為資料去 query 得到相似的結果）
3. 規劃資料應該被存在哪個 table，會在哪些 use case 下 post、put 這個資料，甚至使用者在哪個頁面有機會 get 資料。

但即使殷殷切切把規格的後路鋪好，文件展示給主管時，只收到淡淡的接連詢問——這個需求，真的存在嗎？

• 這個資料得到了，能夠如何幫助我們認識使用者輪廓？
• 我們預期會針對這個使用者輪廓，在產品上做什麼更動？
• 這個產品的更動是基於對什麼商業目標的假設？
• 這個商業目標在公司目標中的優先序為何？

只有第一題答得上來，其他都是空白，才發現自己陷入的虛假的生產，太專注於回應需求方，而不是與需求方一起從商業目標回推產品問題、從產品問題回推需求。

等對產品問題有具體想像時，我們再來看這張票吧。