我從我們某位PM身上學到一件很重要的事情，凡事不要先說NO，不否定，先想可行性跟解決方案。
今天阿翔跟我說，他希望點歌系統開桌時，桌內候播上限可以自動調高。目前預設店家系統上點擊開桌，輸入該桌的來客數，系統會自動填入可以加入的裝置數、每輪可唱的歌曲數、還有可以點歌的候播上限，候播上限我程式自動寫死，是人數的兩倍，一桌5個人，可以唱5首歌，點歌上限預設是10。
當然這些數字都可以手動更改，欄位先預帶也是方便操作者。但阿翔提出，候播上限可不可以調整，他希望可以乘4，也就是5位客人，候播上限自動帶20。我當下的反應當然是，那你就自己把10改成20好了。
後來想想不對，那就是他每天操作的真實需求，我拒絕很容易，但是站在替用戶思考的角度，我應該要開發一個功能，預設候播數是人數的兩倍，但倍率可以讓店員自由調整。
這其實是觀察我們PM得到的經驗，每次優化會議，客戶提議千奇百怪，PM總是先考慮可行性跟衝突，而非第一時間否決客戶的要求。
以前如果收到點歌系統操作上的反映，我第一時間大多覺得「你適應一下系統就好了」。後來思考了一下為什麼會有這樣的念頭？
根本原因可能是，覺得自己做的東西被否定了，下意識本能的防禦。其實用戶就只是把他們實際操作的經驗、想法、意見真實的反映給我而已，沒有誰在否定我。而且這種真實需求的回饋應該是非常寶貴的。
轉念後我很快的回覆，會把這個功能納入開發排程，其實心裡是開心的。開心收到系統真實的使用建議外，也開心自己心態更開放。
不輕易說不並非當個爛好人，該堅持還是會堅持，只是在下意識開口說不之前，先想想其他可能。真的做不到當然就還是會說不。