產品的迭代 or 產品路線圖?

在 MVP 的初步測試完成後，我原先的計畫是模擬一份產品路線圖 (Product Roadmap)，綜合使用者的回饋、競品分析、風險評估等結果，來確定產品的發展方向，和各個階段要完善的目標與功能，顯示對產品長期規劃的考量。

不過，經過了解後，我發現產品路線圖更適合於資源充足、發展穩定的中大型產品或專案。對於草創階段、充滿不確定性的產品來說，並不那麼適合，特別是它作為個人 Side Project。

因此，這次我選擇以模擬「產品迭代」的方向來取代路線圖，目標是透過持續的迭代，更靈活地調整產品策略與功能設計，快速驗證每次改動帶來的效果。

迭代的兩個方向

在產品的迭代上，我理解它有兩個主要的方向：與開發團隊合作的功能迭代，以及與管理團隊合作的產品策略調整。
前者主要針對產品測試中發現的問題進行修正，或補全尚未完善的功能。如果產品策略發生變更，並需要新增特定功能來配合，也會納入功能迭代的範圍。
後者則是依據使用者回饋、外部資訊（如競品、風險、品牌等）的持續分析，對產品的整體策略與發展方向進行調整，以提升產品競爭力，使其更符合使用者需求。

基於這兩個方向，以下是我對於吃吃記帳迭代的規劃：

功能的迭代

根據上篇的使用者測試結果，我將待修正的問題依照對體驗和流程的重要程度進行分級，等級越高，越需要盡快解決。分級的定義如下：

• 高： 影響整體流程的穩定或核心功能的正常運作。
• 中： 影響部分流程或功能的體驗，但不會造成流程中斷。
• 低： 屬於次要問題，對流程體驗影響較小，或是可以考慮將功能移除。
  

產品策略的迭代

在功能之外，我在測試過程中也詢問了測試者對產品的看法，並從中得到了許多啟發。

1. 飲食紀錄之外的功能
在進行競品分析時，我對 MyFitnessPal 的運動消耗記錄和 FatSecret 的社群功能感到驚艷，並發現大多數飲食 App 都會提供飲水、熱量、體重等記錄功能。因此，我詢問了測試者是否期待未來吃吃記帳也能新增這類功能，但他們大多表示並不期待。

測試者 A 表示，由於 LINE 本身是對話的型態，他更希望保持簡單，不要複雜的功能。測試者 B 也表示她目前只需要飲食紀錄，暫時不考慮其他項目。

因此，我認為短期內不應考慮加入其他額外功能，而是要優先將「飲食紀錄」的體驗做到最佳，這樣才能與競品拉開距離。

2. 查詢歷史飲食紀錄是一個明確的需求嗎？
這個問題先前困擾我很久，在詢問之後，我發現測試者對於 「查詢歷史飲食紀錄」的需求並不明確，大多表示僅會「偶爾需要」，這與我原先預期的「需要頻繁查看」有明顯的落差。

因此，我會根據這個回饋重新調整使用者故事，將「查看歷史紀錄」的優先順序延後，並後續安排更深入的訪談，例如：偶爾是多久一次？理想的查詢方式是什麼樣子？等到有更明確的需求再來做進一步規劃。

3. 成本的計算
另一個重要的觀察是，我發現很難準確地評估每位使用者所需的訊息數量。
測試者 C 很擅長與吃吃記帳互動，除了飲食紀錄外，還會詢問食譜和營養搭配的問題，因此一天訊息量可達 20-30 條；相對地，測試者 B 只需要 5-8 條，測試者 A 則是 15 條左右。

因此，我認為成本評估需要進一步的分析與觀察，甚至可能需要設計一個能容納不確定性的方案，來更精準地預測使用者的行為及成本波動。

結論

總體來說，我認為目前的產品策略大致正確，但是需要先鞏固核心功能的體驗，讓使用者可以立刻感受到吃吃記帳的便利性，才會吸引他們使用。
而如果想要更凸顯吃吃記帳可以客製化、親切的對話體驗，我還需要更多的引導和教學，確保使用者理解如何和 Bot 互動。並且對於成本和定價，還需要更深入的研究。

至此，我的第三部分「產品規劃與管理」的內容已告一段落。
接下來，我將進入第四部分，總結這次 Side Project 中的工具應用與學習過程，並分享我在過程中所遇到的挑戰與收穫。