Kể về một lần bạn phải cut scope gần ngày deadline. Bạn quyết định cut gì và không cut gì?

Tiêu chí cut của tôi theo thứ tự: cut feature không ai request hay validate với user, sau đó cut feature có alternative workaround, cuối cùng mới xem xét cut feature requested nhiều nhưng không critical path. Tôi không cut dựa trên 'cái nào dễ cut nhất về mặt technical' vì đó là product anti-pattern.

Tôi học được rằng scope cut hiệu quả đòi hỏi conversation với user trước. Chúng tôi có segment user beta và hỏi họ: 'Trong 5 tính năng này, 3 cái nào quan trọng nhất với bạn?' Kết quả thường surprise chúng tôi — những thứ team nghĩ là quan trọng không nhất thiết trùng với user priority. Điều này giúp cut quyết định tự tin hơn.

Hai tuần trước launch, QA phát hiện edge case phức tạp trong module payment mà engineering estimate 5 ngày để fix fully. Tôi quyết định implement temporary workaround với warning message cho 2% users có thể gặp edge case đó, thay vì delay launch. Logic: 98% users sẽ có experience tốt, và chúng tôi có mitigation plan cho 2% còn lại. Launch on time, fix fully trong 2 tuần sau.

Tôi dùng 'three-tier scope': core (phải có, không cut), enhanced (tốt có, có thể cut), polish (nice to have, cut đầu tiên). Khi bị time pressure, tôi làm việc từ tier 3 lên tier 1. Thường 80% scope cut đến từ tier 3 và không ai notice khi launch vì core value vẫn được deliver.