APM 上路啦 | 需求被工程師挑戰了怎麼辦？！
談談 PM 必備的假設驗證技能 & 說服藝術
距離下專案正好過了一個月，離 PM 真正工作情境又更近了一步。之前培訓更偏向理論式學習，了解 PM 會用到哪些工具；而下專案後會遇到的問題更複雜難解，且沒有正確答案。
這系列〈APM 上路啦〉中會紀錄我在實際執行專案時遇到的事情，一次會著重分享一個主題，內容主要紀錄比較詳細的實例與想法🧠 Then let's go!!
目錄📕
1. 專案簡介：產品的目標與課題
2. 需求被工程師挑戰了，怎麼辦？！
3. 缺乏資料證據時有辦法決定需求方向嗎？
4. 不斷的自我靈魂拷問，才能帶來說服力專案簡介：產品的目標與課題
目前我參與的專案是新產品兒童有聲書 APP，我們的目標是創造故事創作者跟爸媽小孩都喜歡的平台，並幫助爸媽輕鬆育兒、陪伴小朋友成長。
這個專案定位比較特別，雖然是新產品，但因過去已有成功先例（相等於已做完市場驗證），所以團隊被預期的產出需要比 MVP 更成熟，但又要比照推行新產品小步快跑的 Scrum 模式。因此，如何在「速度」跟「使用者需求」間找到平衡成為一個很重要的課題。
需求被工程師挑戰了，怎麼辦？！
大約進專案後第二週，專案 PM 就開始請我在 pre-refinement 中負責報告。Pre-refinement 的目的是先跟 RD 溝通下期想前進的需求方向，一方面討論可行性、是否需要再把需求切小；另一方面也讓 RD 先有心理準備，能夠估算需要的時程。在這個會議中至少要準備好下期需求 PRD，以便清楚傳達需要完成的事情。
這個專案預計四月中上線，我加入時最基本的功能都已經建制完成，接下來就是要思考更高層次的需求（如同馬斯洛的需求層次的金字塔）。當時專案 PM 提供我兩個思路，並希望我用假設驗證來評估該往哪裡前進。CMoney 的產品開發文化非常迅速，公司設計了假設驗證卡，透過制定目標、需求假設、如何評量三個面向來幫助規劃產品方向，以節省慢慢做研究的時間。
撰寫實驗卡過程中能夠很有效的幫助釐清思路，在跟專案 PM、產品顧問討論後，決定下期需求要朝我提案的方向前進（抖）很讚嘆公司願意給新人機會的同時，感覺自己也在專案中逐漸擔起了一些責任。然而，決定下期方向只是第一步，還要先跟 RD 們開會確定沒問題才會正式前進。
在新一期的 pre-refinement 會議中，專案 PM 很放心的把會議交棒給我就去開另一場會了（？）由於我對專案整體了解還不夠深，也缺乏有聲書領域的 domain knowledge，所以在做文件規劃時就覺得不太有把握。果然報告結束後 RD 也產生了幾個疑問，最主要糾結點在於目前還沒有驗證 A 功能，那把 A 功能又新增到一個新的 B 頁面中是合理的決定嗎？我當下幾乎快被說服了，來回的討論也讓我重新檢視做出這個決策的原因。
缺乏資料證據時有辦法決定需求方向嗎？
過去，我通常習慣握有充足證據再做出決定。所以當資料不夠時，容易讓我感到信心不足，連自己都無法說服，更遑論去說服他人。
因此在會後，我帶著滿滿疑問去請教了專案 PM，以及另外兩位資深 PM：當沒辦法接觸使用者、二手資料少的情況下，要怎麼確認自己前進的需求方向是正確的？而三位 PM 也各自提供了不同的想法。
首先，在做產品時本來就很難等到證據足夠、想得夠清楚才開始做。
人腦想法有限，通常我們想到的東西別人也想的到，所以不太可能做到「想得完美」，通常想完競爭對手也已經做完了。所以公司文化認為與其花很多時間想，不如趕快推進市場驗證迭代。
再來，不要害怕做白工，重點是想清楚、講清楚為什麼要做。
其中一位資深 PM 分享，其實他以前常常碰到做白工的狀況，這令我很驚訝。我因為擔心浪費團隊資源、浪費 RD 們的時間，所以一直會害怕決策方向錯誤；但這樣容易導致只能想出及格的想法，而非突破式的創新。所以在做決策時，應該是事先做好假設驗證，至少確定這個方法值得一試的理由，就能在足夠的信心基礎下去實驗。
例如我們專案中下期想做一個特殊專區，雖然尚未驗證需求，但要做的目的主要為了跟其他類似平台做出差異化。所以在跟 RD 溝通時，應該要把這部分的原因講清楚，還有列出嚴謹的假設驗證，讓工程們知道不是在做無謂的白工，如此一來才是有效的說服方法。
不斷的自我靈魂拷問，才能帶來說服力
在與三位資深 PM 的對談中，讓我最有感的一句話是「PM 需要很擅長自我靈魂拷問。」PM 在想任何事情的時候都要不斷自問自答，釐清決策的理由。
例如有一次需求會議中，顧問給了我們許多數據呈現的設計建議。因此在跟 UI 開會時，我原封不動的轉述了顧問的話：「XX 建議應該要這樣做…因為大家都這樣做，所以我們也這樣做…」
會議結束後專案 PM 給我回饋，如果想成為讓人信任的 PM，提出的任何想法最好是已經自我反芻多次的觀點。就算是別人給的建議，也要先內化成自己的想法再提出來，才會更有說服力。
這也呼應產品長 Kerwin 最近才提到的，某個主管說要做什麼不是重點，重點是這樣做的原因為何？如果主管說他不想要產品這樣做，那麼不喜歡的理由又是什麼？我們要在乎的不應該只是上層主管提出來的「建議」，而是去深挖背後的思路以及提出想法的原因。
以上就是這次的〈APM 上路啦〉，在缺乏資料證據的狀態下要做出需求決策真的是一件讓我很困擾的事情，而且還樣拿著這件事去說服團隊的其他人，簡直是難上加難🤯🤯
不過這是 PM 一定多少會遇到的狀況，所以只能想辦法接納這種不確定感，最重要的還是好好把現階段的目標、決策理由清楚傳達給 RD 們！最後也在這邊告白團隊內的 RD 真的很像天使，謝謝他們都願意耐心的來回溝通，讓團隊能夠順暢運作🙌
看完文章的你有任何類似的經驗嗎？歡迎留言分享，讓我們在職涯新人的路上一起努力前進吧！
