本文作者：MH（做過公關、數位行銷，2020 年轉職成為產品經理，在台灣工作的第 8 年飛到新加坡當外籍勞工，希望能在 2022 年藉此玩遍東南亞。）
會想寫這篇文章，是因為自己剛好是從「需求端（行銷）」轉移到現在的「實作端（PM）」。被同為需求端的人問過：「到底要怎樣跟 PM 提需求，他們才聽得懂？」，也被 PM 問過：「為什麼那些需求端怎麼講都講不聽？需求不是這樣提的！」既然發現兩端在溝通上有點落差，那就寫篇文章分享一下個人經驗與想法吧！
這篇文章有點貪心，想要同時滿足 2 種需求的人：
- 對於接需求的 PM，最在乎的應該是「該怎麼評估一項新需求？」
- 對於提需求的需求端（如業務、行銷、BD、客服等），較重視的則是「該怎麼提（一個不會被 PM 打槍的）需求？」
文章主軸會從 PM 視角出發，先介紹 PM 通常會如何評估一項需求的緊急度、可行性與必要性，接著則會分享需求端該如何「正中下懷」，根據 PM 評估標準去描述自己的需求。
0. 需求的資訊充足性
「提需求」看似簡單，但不同人有不同作法。我遇過有人把提需求當作許生日願望，只說「我想要做一個 XXX 功能」，也有人把提需求當作寫日記，鉅細靡遺載明人事時地物，還會附加說明自己目前遇到的難關以及對於這個需求的迫切心情。至於需求到底該怎麼提呢？
其實提需求沒有一個固定格式，每家公司都有不同作法，每個 PM 與需求端也都有各自的習慣。但即使沒有範例文件可以參考，提需求時，可以先想清楚以下幾個背景因素：
- 目前遇到什麼問題？
- 可能可以有什麼解法？
- 這個問題解決後，會帶來什麼好處，或者解決哪些困難？
💡 要注意的是，做為需求端，有時可能只能盤點出目前遇到的問題，不一定能想到解法。這也沒關係，別擔心！因為想解法是 PM、設計師和工程師等實作端的任務，作為需求端，只要把問題與目標闡述清楚，讓實作端找到連結問題與目標的橋樑就行。
而且，只要回答出上面這 3 個問題，PM 就可以寫出一個很粗略的 user story 了，最典型的 user story 公式就是：作為 {某種使用者}，我想要 {做到某件事}，這樣我就可以 {達到什麼目標}。
比如：
- 作為 {數位行銷}，我想要 {讓消費者有優惠}，這樣我就可以 {吸引更多人來購買公司產品}。
- 作為 {業務開發}，我想要 {收到更多潛在客戶名單}，這樣我就可以 {在每天打出更多陌生開發電話}。
這個公式看來簡單，但其實很多人在提需求時，往往會直接落到「解法」，比如上例的數位行銷會直接說：「我想要做折價券功能」或「我想要做客戶消費點數回饋功能」、業務開發則會說：「我想在網站上放一個『請留下 email』的彈窗」。
「忽略目標，直接落到解法」的問題是，因為沒有好好聚焦目標、沒有好好思考問題的根源，所以想出的「解法」跟「目標」之間雖有相關性（correlation），但沒有因果性（causation），且這個解法也不一定是最佳解，反而限縮了實作端發揮的空間（後面再詳述）。
總之，作為需求端，只要用上述公式把需求提給 PM 即可。
當 PM 接到需求後，則可以透過以下幾個元素評估這個需求該不該做（是否受理）、該怎麼做（解法為何）、該什麼時候做（優先級如何）：
1. 區分必要（非要不可）vs. 想要（有了更好）
通常最容易的就是先看這個需求是必要（must-have）還是想要（nice-to-have）。簡單來說就是「完成不了這個需求的話，我們會怎樣？」
比如有用戶抱怨網站上的字太小 vs. 有用戶反映用手機打不開網站首頁的某個連結。前者是「事情能完成，但不太能順利完成（用戶依然看得到字，只是嫌字很小）」，後者則是「事情根本無法完成（連結進不去）」，這樣一比，通常後者需求就會比前者更優先處理。
不過也有很多時候，需求端會覺得這個需求是「必要」，PM 卻覺得只是「想要」，那這時該怎麼辦呢？或許可試試後面的步驟，逐一分析這項需求。
延伸學習：《優先級方程式：用量化公式帶你決定產品開發順序》
2. 商業價值與目標：解決這個需求，將帶來哪些價值
對工程師或 PM 來說，「產品能順利運作、被用戶使用」就是一個產品的最低標，所以需求若與此無關，很容易被 PM 視為「想要」而非「必要」，也就是所謂的「有了會更好（沒有也不會死）」的功能。
然而，這些被視為可有可無的功能，很有可能會帶來極大的商業價值。這時，就仰賴需求端的銷售功力了。
💡 即使都是同個公司的同事，大家的目標應該是一致的，但畢竟每個團隊有不同方式達成同個目標，所以很多時候，仍需要透過各種「手段」（遊說、死纏爛打、內部 pitch、找主管…etc）才能說服其他團隊用你想要的方式達成目標。
作為 PM，產品的好用固然重要，但產品能幫公司帶來價值也非常重要，所以當一個需求很有價值（不論是為公司帶來名還是利），通常優先順序也會比較前面。
比如有用戶抱怨網站上的字太小 vs. 有用戶希望網站舉辦優惠活動時，作為消費者，不用手動複製並輸入優惠碼，可以一鍵領取並抵用。兩者都是「想要」而非必要，那該怎麼比較？
可以思考的是：做好這些需求，他們各自帶來的價值是什麼？或者換個角度思考：不解決這些問題，用戶會怎樣？會繼續抱怨而已？還是會從此離開、不願使用這個網站？還是營收會有顯著影響？
如果用戶反映的頻率和件數差不多，解決「網站上的字太小」能帶來的商業價值應該遠小於「一鍵領取並抵用優惠」，畢竟後者跟付費流程有更大的關係。
💡 作為需求端，也可以在提需求前多找點資料，比如：用戶多常來抱怨這件事？這件事情造成哪些影響 — — 比如會影響客單價、DAU、跳出率嗎？如果有數字佐證，通常就能夠更快推動實作。
3. 相關性與因果性：這個需求與解法之間的關係
若依照上面的步驟，現在已經完成了 why 的部分，包含：釐清需求、確認需求的必要性、確認需求有其對應價值，再來要思考的就是 what & how，也就是需求的「解法」。
延續上面說的，作為需求端，其實大可不必直接給出建議作法，而是提供足夠的背景資訊與需求脈絡即可，比如目前遇到什麼問題、為什麼想要做，至於「要怎麼做」，需求端當然可以給建議，不過也要留給實作端一點空間。
原因主要就是前面說的：如果直接落到解法，有可能會出現「該解法不一定能真正解決原本的需求」的窘境。比如業務團隊發現某功能的點擊率很低，直覺推測是因為該功能的入口不夠明顯，所以直接要求設計師把入口的文字顏色改得更顯眼、文字變得更大。
然而，這個「點擊率低」的問題背後可能有很多原因，比如：用戶有看到入口，但覺得這功能沒什麼用，所以不想點、用戶其實有點擊，只是內部數據異常、用戶根本沒有看到這個入口、用戶有看到，但甚至不知道這是一個入口。
上述每一個原因都會導致「點擊率低」，但有趣的是，每個原因的解法都不同，所以這就是前面說的：如果沒有跟產品、設計或工程團隊好好討論，而是從需求直接落到解法的話，很有可能出現「需求與解法之間無因果性」的狀況。
事實上， PM 在跟設計或工程團隊討論需求時，也不太會直接說：「這個需求我想好解法了，你們就照做即可」，而是會跟團隊說：「關於這個需求，我有想出幾個解決方式，但不確定有沒有更快或更適合的解法，我們可以討論看看」。
因為 PM 通常最在乎的是商業目標與整體產品的走向，而設計師更具有 UX 和 UI 的專業，能更全盤地思考並顧及使用者動線與整體操作流暢度；工程師則是實際要去解決這個需求的人（畢竟他是團隊裡負責寫程式碼的人），他通常會較在乎這個解法的通用性與可擴充性，比如這個解法會不會太過客製化，進而影響運作效能？這個解法能否也運用到其他情境，達到通用性？如果未來流量和用戶變高了，這個解法是否依舊有效？
💡 團隊中的每個職能對於同一需求的思考角度不同，所以想出的解法也會不同。總之，作為需求端，會建議給團隊多一點思考與發揮空間，即使最後每個人對於「最佳解」的看法不同，但至少能找出一個折衷解法，有時甚至會有更好的想法出現，最後便能在「大家都覺得這樣可以」的狀況下，完成該需求想達到的目標。
延伸學習：《數據大揭秘：從使用者數據找產品優化的決策》
.jpg)
4. 技術可行性：這個需求的解法要花多少成本才能達成
現在又接到了不同的需求：行銷團隊想要做團購功能、業務團隊想要做購物車功能，兩者都跟付費流程有關，且預期帶來的收益都差不多，那怎麼辦？
作為 PM，這時通常會先跟設計師與工程師討論，先和他們做些前情提要，並說明大概的解法、會影響到的部分（比如這些功能需要新增哪些對應的頁面與資料庫欄位、這些功能大概的操作流程），讓他們做出初步的評估。
即使沒有 wireframe 和 user flow，實作單位通常掌握上述基本資訊後，仍能評估出一項需求是「很快可以搞定」、「有點難，因為之前沒做過，但研究一下就可以」、「因為涉及到 #$% 問題，所以會蠻複雜」。
當收益相同，決定優先序的主要變因就是人力與時間成本了。如果一個需求需要花三個月、另一個只要一個月，那「通常」會先選後者，畢竟可以較快看到成效。
💡 某些狀況下，需求端會跟實作端商量「分批交付」，比如原本要做到 100% 的話，需要三個月才能上線，但因為團隊預期該需求帶來的效益驚人，或者老闆真的把死線壓超緊（這可能是更常見的原因吧），需求端希望能早點上線，所以可能做完 30% 或部分功能就先上線，如此一來，可能只要一個月就可以先驗收需求了。
5. 副作用：這個需求的解法是債留子孫還是讓後人乘涼
延續上一段提到的「如果一個需求需要花三個月、另一個只要一個月，那『通常』會先選後者，畢竟可以較快看到成效」，這裡強調了「通常」，代表絕非定則。
有些需求的解法是一勞永逸，有些則是短期的折衷作法，可能是被時限所逼、也可能是當下沒有更好的方式、或者當下的各種環境，所以會採用所謂的 workaround，代表這只是「暫時性」的解法，終究有某天會需要找到真正能解決這個棘手問題的辦法。
workaround 有時候會變成技術債或產品債，技術債就是未來接手的工程師看到時可能會生氣的東西，比如不合邏輯、沒有依循原本模式的程式碼，或者太客製化的處理方式等；產品債也是類似的意思，可能是未來產品迭代時，都要為了這個功能去設想對應的使用情境，或者根本會因此而無法迭代，需要砍掉重練。
總之，雖然大家很常把「反正之後這個功能也不一定是我來優化」掛在嘴上，但秉持著基本的良心（？），還是會建議在提需求與排序需求時，都要考量到完成這些需求後，會帶來哪些正面與負面的效益，不要因為有時限壓力或主管施壓等外在因素，而太輕易做出飲鴆止渴的決定。
以上大概就是 PM 接到一項需求後會開始思考的問題，也是 PM 在評估、排序需求時會參照的點。
不過畢竟產品跟團隊一樣都是有機、不斷變化的，所以上述這些也只是個基本規則，比如若是在重技術的公司，商業價值和用戶體驗就不一定是優先考量；相反地，如果產品非常在乎用戶體驗，那或許團隊會更願意付出開發時間或容忍一些客製化情境。
總之還是老話一句：實際要怎麼做，仍是因人而異，也就是 by case 啦！
原文連結：《身為 PM，該怎麼評估一項新需求？身為需求端，又該怎麼跟 PM 提需求？》
