不知道怎麼面對各種產品需求嗎?現學現賣的工作方法與溝通術!

Anne Hsiao
Nov 2 · 13 min read

在《【PM夥伴攻略】如何跟工程師合作?》中我曾經分享過一小段「如何擋需求?」的內容,在這裡會分享面對大量需求的處理方法。這篇會以自有產品的情境為主,如果是獨立與各客戶簽約的接案公司,狀況可能大不相同。

產品經理/專案經理/工程師會需要使出「擋需求」的技能,通常是因為老闆、主管、其他部門、重要客戶提出了在原本規劃之外的需求、無預警的靈感噴發 — — 無論是現在正在開發的東西規模變大,或是提出了全新的功能與想法,常讓人很頭痛。

這一答應下去,資源要重新調整、時程得重新安排。有時候被提出的需求與建議對產品很有幫助,但其他某些時候:

  • 這想法很好,但是不是公司目前最重要的目標
  • 這想法很好,但是時程壓非常急,會排擠到其它開發中的項目
  • 這想法很好,但是有這個問題的使用者不是我們的主要 TA
  • 這想法… 很特別(?)…
面對需求方總是欲言又止 …

工程師創造技術債,產品經理創造產品債。

醒醒吧,脂肪不會變成肌肉~

沒有經過規劃地動工、無限上綱地加新功能,就像是想要保持體態卻沒在做飲食規劃,只是一味的大啖美食,吃進去的東西長出來的可能不是肌肉而是肥肉。加新功能不總是加分,移除原有功能也不一定扣分,一切都關乎於團隊與公司目標。


如何面對不斷湧進的需求?

這套目標與方向必須要有明確的優先級(Prioritization),包含首要目標、次要目標、關注的指摽等等,讓自己、團隊清楚了解這個產品規劃背後的原因與邏輯,以及遇到衝突時該怎麼重新排序優先級。

其中「遇到衝突時該怎麼重新排序優先級」就是在面對不斷湧進的需求時,最好的參考標準。光是在自己的產品團隊內部,PM、設計師、工程師本身提出的需求就已經很容易多到資源不足,更何況從團隊外部臨時出現的需求。

在《產品經理日常掙扎:如何制定產品優先級策略(Prioritization)?》中,我提到了這個工作流程:

  1. 確立團隊目標
  2. 蒐集使用者問題、商業問題
  3. 排序問題優先級
  4. 依照資源多寡,選擇高優先級的問題來進行使用者與市場研究
  5. 針對研究結果,發想不同的解法
  6. 排序解法優先級

在接團隊外部需求時,可以請需求方提出明確的「2. 使用者問題、商業問題」,而不要只是提出最終的功能、解法。在欠缺使用者脈絡與商業目標的情況下,直接跳到解法不會是個好主意。

有時候請需求方協助去了解使用者問題、商業問題,就會擋掉大半需求了。有一定的機會他回去研究研究,研究一陣子就沒下文了。這等於是把球丟回去給他,讓他來說服你、團隊、老闆,為什麼現在做這件事情很重要,以及找出真實用戶需求的源頭。當然如果是 PM 自己就認為很值得研究的問題,大家就一起跳下去處理吧!

而通常產品目標與優先級跟公司商業決策息息相關,因此若是本質上的商業策略改變、突然有重要的合作夥伴加入等等,的確有可能直接影響到各個專案的重要性與優先級。

延伸閱讀《給產品經理和分析師:如何用指標框架計算產品改動影響力(Impact Sizing)?》by Nana Chiang


新需求,值得嗎?

  1. 這件事情值得做嗎?
  2. 這件事值得現在做嗎?
  3. 這件事值得排擠掉其他正在進行的專案嗎?

如果只有第一個答案是肯定的,那可以與需求方溝通,將議題排入未來的排程,也許下個 Sprint、下一季的時候能夠開始研究與處理。此時我們在做的其實不是「擋需求」,而是「規劃需求的排程」。

若二或三的答案也是肯定的,從專案管理的角度來說,就是「要資源」、「砍需求」兩條路。如果能拿到更多資源,當然可以全都做啊(普天同慶);但在一般團隊資源不變的情況下,只能調整原本事情的優先順序,將新的需求拉上來,原本進行中的專案暫時擱置。此時當然也不是「擋需求」,而是「重新安排各種需求的處理順序」。

Ref: 宿命之战:程序员 VS 产品经理

處理產品團隊外部需求的小撇步

1. 平時就頻繁溝通產品目標與優先級

2. 提供需求方一個明確的 request template

延伸閱讀《Feature requests that don’t suck》Get a feature request template that works here.

3. 建立統一的需求搜集流程

更多回饋蒐集與整理方法,請參考《【PM夥伴攻略】如何與客服團隊合作?了解使用者與提升產品信任的好幫手!

4. 將「做好產品」的重責大任分享給需求方

5. 態度專業、即時回饋

有的時候需求方只是想要了解產品團隊的想法,不一定非常強硬地認為一定要現在就開始進行,因此即時回饋對雙方都好,別因為不想面對成千上萬的需求而拖了又拖。

延伸閱讀《我在新加坡旋轉拍賣擔任產品經理學到的十件事(上)》by Nana Chiang

擁有堅定的觀點,同時保有最大的彈性
摸索過後,我現在常會用類似這樣的方式去回覆還有爭議的話題:「我認同你說的 ____,但我不同意 ____,根據我目前了解的 ____,我的看法是 ____,但這可能是對也可能是錯,我會去蒐集/驗證 ____ 資料,再讓你知道我們的下一步。」
「Strong opinions weakly held」是我和我的 PM 夥伴都很喜歡的一句話,保持極大彈性,但一當情況/資訊改變就要快速適應與調整。PM 也是人,我們無法做出百分百完美的決策,只能清楚知道自己正要做哪些決策,決策中又包含了哪些假設,考量各種資訊之後,選擇已知狀態中最好的選擇。

人民的聲音,我都聽到了!只是還沒回應而已啦~(Ref: 聽到了 網友諷已讀不回

加分題:Anti-Roadmap


走出團隊外,何時不該聽客戶的意見?

不只是 PM 本人,客服、行銷、AM、業務等直接面對客戶(B2B產品)、使用者(B2C產品)的角色也很常會收到用戶提的需求。說到底,很多從其他部門提出的需求,最源頭也是從用戶來。

我崇尚使用者中心的設計、也喜歡了解使用者需求,但在這些時候也許不該以客戶的想法為依歸:

  • 這個客戶提出的意見與公司目前的目標無關
  • 這個客戶提出的意見是解法,而不是問題或需求
  • 這個客戶不是我們現在主要服務的 TA
  • ……

說來說去跟一開始外部團隊提想法的問題是大同小異的,最根本的差異就是客戶只能為他自己負責,而無法為公司與團隊負責,因此 PM 身為團隊一員,本來就更應該謹慎面對這些建議。客戶提需求只是個單方面的動作,若能讓它變成雙方有互動的「使用者研究」,這個資訊就會變得很有價值。

回顧一下《【PM夥伴攻略】如何與客服團隊合作?了解使用者與提升產品信任的好幫手!》的舉例:

如果我當年問顧客他們想要什麼,他們會告訴我:「一匹更快的馬」 — — 亨利・福特

以「更快的馬」為例,背後的原因可能是完全不同的:

  • 移動速度太慢,來不及見病危家人最後一面(人)
  • 移動速度太慢,食物貨物送達時已經過期(物)
  • 通訊速度太慢,無法即時傳達重要訊息

更快的馬是其中一種解法,但不是唯一解,若完全按照客戶的想法執行,就喪失探索更多更好解法的機會了!

講的很容易,但與大型客戶(Key Accounts, aka KA)溝通總是最困難的,尤其當他對公司來說是非常重要的客戶(付最多錢、成效最好、可以對外拿來公關與提升品牌印象),他直接向團隊提出的問題與需求就會格外重要。

把老闆搬出來

個人認為這是典型的老闆需要去煩惱的事情,這包含投資人的想法、公司整體策略(其他商業模式、產品線)、客戶結構、營收結構等等,已經不單單是產品層面的問題。因此當發生這類型的衝突,可以讓所有利益關係人跟老闆一起開個會討論,搜集更多資訊。


拒絕客戶的小撇步

1. 我們現階段無法做___,因為___。

  • 我們現階段無法做,因為這不是產品這一季最重要的發展方向。
  • 我們跟工程師討論之後,發現因為某種技術限制,所以現階段無法做。
  • 因為我們目前對這個議題比較不熟悉,所以現階段無法做。
  • ……

2. 我們現階段無法做___,因為___,但是___。

  • 我們現階段無法做,因為這不是產品這一季最重要的發展方向,但是我們也正在開發你也很期待的 ABCD 功能呀!我們把焦點都放在那了!
  • 我們跟工程師討論之後,發現因為某種技術限制,所以現階段無法做。雖然無法直接解決你的問題,但是我們團隊想到了另一個方法來協助你們!(可能是一些奇特角度的 workaround;或可能不是從產品角度去處理,而是需要手動人工處理。)
  • 因為我們目前對這個議題比較不熟悉,所以現階段無法做。但是如果你們願意的話,是否能夠與 PM、設計師安排一個使用者訪談,讓我們做更深入的研究呢?我們先來徹底瞭解這個問題對你們造成的困擾,再看看未來我們能如何協助你們解決。
  • ……

3. 我不管!我就是不做!有種你就不要用我們產品啊!

Lecture 16 — How to Run a User Interview (Emmett Shear) — 25:30 開始看

Emmett Shear 在這個課程中分享到 Twitch 收到的很多用戶回饋,這些很熟悉產品的使用者提出了非常細節的產品建議與功能需求,他的回應卻是「如果你以為我們會優先處理這些需求,那你就錯了!

他認為會花時間列這些問題、甚至主動跟產品團隊分享的用戶,通常是死忠用戶,而他們提出的問題其實也沒讓他們那麼痛苦,否則他就不會繼續在這裡用產品!甚至還苦口婆心地請你優化產品!反之,他們會直接一走了之,成為你產品中 churn 數據裡面的一個微小數字。

這個答案雖然不太正向,但撇開死忠用戶的案例,從另一個反面的角度看,若是該客戶真的離公司想要服務的對象太遠,需求跟其他客戶差太多,適時放棄一些客戶也是一種決策。

❤️ 是 SAY NO 不是 せーの(SE-NO)唷 ❤️(Ref: 慢慢說樂團【SE-NO】

而我們曾經遇過的情況是,過去我們都服務中小型客戶,有些跟著我們很久的客戶已經漸漸長得很大、有自己的品牌、養了很多員工、租了倉儲與辦公室,因此他們的需求才會跟我們原先服務的對象大不相同。當時我們的想法是,我們希望其他現階段還是小客戶的人,未來也有機會成長茁壯成為大客戶,因此儘管這種大型客戶才有的特殊需求數量不多,但提前去打造適合大型客戶的產品環境會是一個我們想去嘗試的策略!

因此這一切還是回歸到公司目標、商業策略、產品規劃上。

但無論如何,當用戶給予回饋時,記得表達感謝 — — 謝謝他們願意使用這個產品、重視這個產品,並願意主動提出他們的想法給團隊。


教科書之外的世界總是知易行難

延伸閱讀《【PM夥伴攻略】老闆到底要什麼?如何有效地向上管理?》by Yolanda Chiu

公司老闆要願意賦權、同事都很願意理性溝通、而且大家都要能夠了解問題解法是不同階段的東西,有了這些前提,才有辦法推動理想的產品目標與產品團隊。

延伸閱讀《Why-How-ladder:產品需求探索的思考練習&工具》by Yolanda Chiu

從 PM 的角度來說,我也還在練習將心態從「鑽研拒絕的藝術」變成「如何有效率的處理需求」來不卑不亢的面對其他部門的需求。這不是一場攻擊與防守的戰爭,結論不永遠只是 YES 或 NO,我們追求的不是一個標準答案,而是團隊間一連串討論的過程。

延伸閱讀《Product strategy means saying no》by Inside Intercom

延伸閱讀《How To Say No — Gabrielle Bufrem on The Product Experience

謝謝你的閱讀!如果有任何回饋或有興趣的主題,歡迎留言給我們 📒如果單純想給我一點鼓勵,請給我 1–10 個拍手;
如果覺得文章對你有點幫助,請給我 11-20 個拍手;
如果想看更多團隊合作的文章,請盡情長按拍手(50個拍好拍滿也沒問題)讓我們知道 👏🏻
想要持續追蹤我們的最新文章,請記得追蹤「產品三眼怪實驗室」(◉◉◉)!
我們每週末都會認真更新文章唷!千萬別錯過了~

3PM LAB

產品三眼怪實驗室 (◉◉◉) - 來自網路圈的三位 PM ,分享網路產品經理實務、產品開發案例、趨勢、新知。歡迎訂閱三眼怪加入我們的實驗室,每週末定期更新,別錯過最新文章!ooohh!

Anne Hsiao

Written by

[ Software Project / Product Manager] 江湖人稱蕭大哥,曾在設計、電商、軟體產業擔任專案/產品經理。LinkedIn: annehsiao 👩‍💻; Buy me a drink: annehsiao.eth 💸

3PM LAB

3PM LAB

產品三眼怪實驗室 (◉◉◉) - 來自網路圈的三位 PM ,分享網路產品經理實務、產品開發案例、趨勢、新知。歡迎訂閱三眼怪加入我們的實驗室,每週末定期更新,別錯過最新文章!ooohh!

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade