Trong một project critical, bạn phát hiện một risk lớn mà stakeholder chưa biết. Bạn communicate thế nào và khi nào?

Tôi học rằng cách communicate risk quan trọng không kém nội dung risk. Tôi tránh language panic và dùng 'đây là vấn đề chúng tôi phát hiện sớm và chúng tôi đã có plan'. Framing tích cực giữ cho conversation về problem-solving thay vì blame. Stakeholder appreciate PM phát hiện risk sớm và come prepared, không phải chỉ bring problems.

Nguyên tắc của tôi: communicate risk ngay khi nó được xác nhận, không phải khi nó xảy ra. Khi Engineering phát hiện một security vulnerability trong third-party library một tuần trước launch, tôi call với Head of Product và CTO ngay trong ngày. Tôi đến meeting với 3 options: delay launch 2 weeks để fix, launch với temporary workaround, hoặc launch và accept risk với monitoring in place. Họ có đủ info để decide ngay.

Tôi frame risk bằng formula: Risk Description + Probability + Business Impact + Mitigation Options + My Recommendation. Ví dụ: 'Third-party API provider đang có instability (medium probability). Nếu xảy ra trong launch week, chúng ta expect 40% degraded experience cho users (high business impact). Options: A) delay và implement fallback, B) launch và manual monitor, C) find backup provider. Tôi recommend A vì...' Clear, actionable, không panic.