擔任產品企劃、產品經理時，常常需要向上提案，讓上層知道你的產品規劃是否符合公司策略，同時也需要透過提案來爭取資源，但提案要注意哪些細節？這篇會從「痛點、解法、時程」來拆解提案技巧。
誰適合看這篇文章？
✔ 對產品經理、產品企劃、產品策略、產品規劃有興趣的朋友一、需要產品提案的場景
以我目前參與過的產品團隊，有幾種狀況需要提案：
- 主管訂了數據指標，沒有具體要什麼功能，由產品經理研究如何達到目標（自行選擇要開發哪個功能）
- 主管指出明確功能，由產品經理進行細部規劃（根據特定功能提案）
- 主管僅提出需求情境，由產品經理發想解決方案後，再進行提案（解決問題導向的提案）
但提案可能會遇到失敗，失敗原因通常是跟主管腦海中的解法不同、或是效益不夠明確、解決方法過於複雜等，究竟要怎麼提才能提高成功率？以下我分成「拆解痛點、羅列解法、掌握時程」。
二、拆解痛點
需求者、主管、或主管的主管想要什麼？我的方式就是勇敢問吧！
若要優化一個頁面的架構，我可能會先向主管確認以下需求：
- 確認需求目的：優化此頁面的目的是？是優化特定位置的操作體驗？還是單純視覺介面優化？是重要且緊急的項目嗎？是行銷／業務希望改的嗎？或具體是哪位使用者或客戶提出的需求嗎？
- 確認理想畫面：有沒有預期的成品畫面？或是之前有參考過哪些競品？這次有想特別修改哪些欄位嗎？有希望保留或移除哪些畫面嗎？
- 確認驗收標準：優化有希望達到什麼成效嗎？有希望幾號上線嗎？會需要搭配 EDM、廣告或發布會進行宣傳嗎？
哪一項比較難呢？我認為「釐清目的」是比較重要的一環，因為每個主管著重的點不太一樣，有些主管在意提案內容有沒有確實解決使用者問題（操作體驗），有些是專注在優化後的數據指標（數據改善）。
若目的沒確認好，再怎麼提畫面、提解法，可能都沒有解決到主管心中的期待，有幾次經驗是和主管討論目的後，發現其實有簡單直覺的解法，讓後續提案一次就過。
三、拼湊解法
確認好需求後，解法怎麼產生？我習慣提 2–3 個選項給主管選擇。
思考一個功能要如何製作時，我最常做的一定是先參考競品，在滿足特定使用者需求時，競品的 Userflow、Pageflow 都怎麼設計。
我很少會根據使用者想要的方式就開始規劃，因為最怕遇到個案，我們不一定能立即分辨出該情境是個案還是通案，也不一定能 100% 確認使用者提的方式就能真正解決所有問題。
實際上在拼湊解法時，我的流程大概是：
- 羅列競品畫面：先截圖拆解 5–10 個競品的特定功能，看這些品牌都怎麼解決類似問題。
- 分析功能情境：根據競品、自身產品的介面，思考怎麼設計流程會更好，同時考量自身產品的定位／屬性，看是否要捨棄或新增什麼功能。
- 開始拼湊畫面：在實際畫 Wireframe 前，會先快速拼湊競品的功能，大約拼出 2–3 個初步畫面。
- 不斷來回確認：向利害關係人、需求人多次確認使用場景和預期的成果產出。
- 開始定案畫面：根據需求人的反饋，開始定案畫面，並訂出 2–3 個版本，視功能複雜度可能會有簡易版、複雜版。
四、掌握時程
有了上述的規劃內容，接著需要先確認時程。
根據手上 2–3 個版本，先和工程主管、工程師確認畫面的難易度、工時，確認初步時程。
實際運作時，大約和工程團隊合作 5–10 次，就能掌握工程師們手上的工單及人力分配，也因此可以抓出新的需求什麼時候可以被派單、完成開發（若是隕石需求需要緊急插件，則另外討論）。
但工程師給出的時程，回到產品團隊內，是能被接受的嗎？這個也是 PM 要去協商的內容。
因此我的流程大約是：
- 確認初步工時：先和工程主管、工程師確認構想畫面的工時（有時會需要估簡易版、複雜版的個別工時，方便 PM 提案）。
- 確認期望日期：再回頭和產品團隊、主管們確認上線日是否可被接受，或比較緊急則可以先採取簡易版，若時程不緊急則可以將功能做到完成再上線。
五、正式提案
痛點、解法、時程都確認好，這時就可以安排會議進行正式提案了。
下方先列點我在提案的幾個流程：
- 說明痛點：一開始先強調我們要解決什麼問題、以及這些問題發生的情境、影響人數，解決後有什麼效益。
- 闡述解法：根據痛點提出對應的解法，解法可能分成簡易版（功能簡略，但可以解決急迫的使用者問題，且快速能上線）、複雜版（功能完整，但製作工時較長）。
- 提出時程：根據解法給出對應的工時讓利害關係人判斷，同時 PM 也要有自己理想的解法，若自己希望功能完整一點再上線，我就會不斷爭取時間。
六、總結
上述的產品提案心得來自於我在工作中經驗，若對這系列有興趣也可以持續觀看：
