Bạn cần quyết định KHÔNG build một tính năng mà team engineering đã excited và đã research nhiều. Bạn xử lý tình huống này như thế nào?

Đây là một trong những tình huống PM cần nhiều courage nhất. Tôi sẽ không announce quyết định cold—tôi sẽ setup một session để team engineering present findings của họ, tôi present research data của mình (user need evidence hoặc thiếu), và chúng tôi cùng evaluate theo criteria đã agree từ trước (impact, effort, strategic fit). Khi criteria không được meet, quyết định 'no' trở thành kết quả của shared framework chứ không phải PM veto. Team có thể disagree về decision nhưng không thể argue với process.

Tôi đã phải nói không với một tính năng gamification mà developer làm 2 tuần research và excited. Lý do: A/B test với 10,000 users cho thấy gamification elements không tăng retention nhưng làm tăng UI complexity. Tôi present data trung thực và added: 'Research của team về gamification mechanic là valuable—chúng ta sẽ apply nó khi reach next scale milestone khi user base đã lớn hơn.' Turning 'no now' thành 'not now'—và để cửa mở cho idea tốt được revisit trong context phù hợp.

Tôi học được một lesson cứng: đừng để team build quá xa trước khi có checkpoint về product viability. Hiện tại tôi bắt buộc có 'Go/No-Go gate' sau mỗi phase research—trước khi engineering invest significant time. Khi xảy ra situation này, tôi sẽ honest: acknowledge work đã làm, explain criteria và tại sao feature không pass (không phải về quality of work mà về user need validation), và re-direct energy sang highest priority item tiếp theo với enthusiasm. PM's job là protect team's time, not just user needs.