Double Diamond: Một cách trị căn bệnh thích nhảy vào code ngay.
Product Manager thường quá yêu giải pháp của mình mà quên tự hỏi: Vấn đề thực sự mình đang giải quyết có đáng để làm không?
Đừng bao giờ nhảy từ việc nghe stakeholder phàn nàn sang thẳng việc Design giao diện & viết PRD. Hãy luôn bắt đầu bằng một bước lùi để tìm ra chính xác của vấn đề. Hãy → Discover → Define.
Có một căn bệnh rất phổ biến ở các team làm Product tại Việt Nam tôi biết, mình tạm gọi là chứng Jump to Conclusion hay gọi là Nhảy cóc giải pháp.
Kịch bản thường là thế này: Sếp Sales chạy qua đập bàn: Khách hàng dạo này phàn nàn không tìm được lịch sử giao dịch. Chú bảo Dev gắn cho anh cái nút Lịch sử bự bự ngay mép phải màn hình Home ngay đi. Khẩn cấp để bán được hàng.
Thế là anh em hì hục cày ngày cày đêm, vẽ UI, test qua test lại. Sau 2 tuần release cái nút bự bự đó, số liệu trả về phũ phàng: Chẳng ai thèm ấn vào. Tại sao? Vì hoá ra khách hàng không cần thiết cái lịch sử giao dịch, cái họ cần là : Làm sao để tôi lấy cái hóa đơn nhanh gửi cho bộ phận kế toán hoàn tiền cuối tháng.
Đây chính là lúc phương pháp luận Double Diamond của Hội đồng Thiết kế Anh quốc Design Council phát huy sức mạnh thần kỳ. Mô hình này khuyên PM chia quá trình phát triển sản phẩm làm 2 viên kim cương (2 giai đoạn Phân kỳ - Hội tụ):
Viên kim cương thứ nhất => Khám phá vấn đề
Discover: Đi thu thập càng nhiều data người dùng, phỏng vấn càng nhiều khách càng tốt, gạt bỏ mọi định kiến. → Customer đang cần tính hóa đơn chứ không phải xem giao dịch.
Define: Gom gọn tất cả thông tin lại thành 1 Problem Statement rõ ràng nhất: → Làm sao để SME chủ động xuất hóa đơn tự động cuối tháng?.
Viên kim cương thứ hai => Thiết kế giải pháp
Develop: Cả team lao vào brainstorm. Gửi hóa đơn tự động qua email? Hay tạo một tab xuất file PDF? Gợi ý 10 cái giải pháp điên rồ cũng được.
Deliver: RICE scoring cái mớ giải pháp đó, chọn 1 cái khả thi nhất ví dụ: Effort thấp và Impact cao rồi mới code.
Khi chúng ta dẹp bỏ thói quen nhảy cóc và biết chấp nhận sự mất thời gian ở giai đoạn Viên kim cương thứ nhất, dòng code mà team bạn viết ra sau đó mới thực sự đáng tiền.
Đề xuất hành động cho PM
Từ chối Giải pháp, Yêu cầu Vấn đề: Lần tới nhận một ticket yêu cầu tính năng từ bất kì ai ngay cả CEO, việc đầu tiên của bạn là phải hỏi lại bằng được Use case đằng sau đó là gì? Anh đang muốn giải quyết nỗi đau cốt lõi nào cho End-user?. Nếu họ không trả lời được, tạm backlist tính năng đó ngay.
Quy tắc 3 giải pháp: Đừng bao giờ ấp ủ 1 ý tưởng duy nhất. Bạn sẽ dễ rơi vào Confirm Bias. Trong quá trình làm Discovery, hãy ép bản thân và team phải viết ra nháp ít nhất 3 cách khác nhau hoàn toàn để giải cùng một vấn đề trước khi chốt hạ.
Timeline linh hoạt cho giai đoạn Discovery: Thường team Dev cần Timeline rõ ràng, nhưng Discovery thì đầy bất trắc vì bạn chưa biết vấn đề là gì. Hãy tách biệt Discovery Track và Delivery Track. Bạn có thể tìm hiểu mô hình Dual-track Agile. Việc nghiên cứu cứ nghiên cứu, việc code những thứ đã clear thì cứ code.
T.D
3.2026