Hội Chứng "Solutionism": Lỗi Chết Người Khi Thiết Kế Hệ Thống
Product Decode
•
Cạm Bẫy Của Những Đầu Óc Nôn Nóng
Hãy tưởng tượng bạn đang trong một buổi phỏng vấn Product Management hoặc Technical Business Analysis. Người phỏng vấn đưa ra một đề bài mở: "Hãy thiết kế tính năng chia sẻ chuyến đi (ride-sharing) cho một ứng dụng giao đồ ăn." Phản xạ của 90% Junior PM/BA là ngay lập tức lao vào chế độ "Xây dựng" (Builder Mode): "Chúng ta sẽ thêm một nút 'Share' ở màn hình Home, dùng Google Maps API để track real-time, sau đó chia đôi cước phí qua cổng thanh toán..." Người phỏng vấn mỉm cười gật đầu. Nhưng trong đầu họ, bạn vừa trượt.
Căn bệnh này được gọi là Solutionism (Hội chứng nghiện giải pháp). Đó là xu hướng đưa ra câu trả lời trước khi thực sự hiểu câu hỏi. Đối với các Senior PM, giá trị của bạn không nằm ở việc nghĩ ra tính năng nhanh cỡ nào, mà nằm ở khả năng chịu đựng sự mơ hồ (ambiguity) và giải cấu trúc vấn đề.
1. Bạn Đang Giải Quyết Sai Vấn Đề (Solving the Wrong Problem)
Bất kỳ đề bài mở nào cũng chứa đầy cạm bẫy về giả định (assumptions). Khi bạn vội vàng đưa ra giải pháp, bạn tự mặc định rằng mình đã biết lý do tại sao tính năng đó cần thiết.
Mục tiêu kinh doanh ở đây là gì? Tăng trưởng lượng người dùng mới (Acquisition) thông qua referral, hay tối ưu hóa chi phí vận hành (Operational cost) cho tài xế?
Nếu mục tiêu là giảm kẹt xe vào giờ cao điểm, thì việc "chia sẻ chuyến đi" có thể không phải là giải pháp tốt nhất so với việc "tăng giá giờ cao điểm" (Surge Pricing). Giải pháp đúng cho một vấn đề sai là một sự lãng phí.
2. Bỏ Qua Giới Hạn Hệ Thống (Ignoring Constraints)
Mọi giải pháp đều hoạt động hoàn hảo trên giấy. Tuy nhiên, thế giới thực bị ràng buộc bởi nợ kỹ thuật (Technical Debt), ngân sách và thời gian.
Bạn đề xuất tính năng tracking real-time (thời gian thực), nhưng bạn chưa hỏi xem hạ tầng WebSocket hiện tại của công ty có chịu nổi tải gấp đôi hay không.
Một PM giỏi sẽ luôn tìm kiếm những giới hạn này trước khi phác thảo giải pháp.
3. Đánh Mất Cơ Hội Thể Hiện Tư Duy Phản Biện
Mục đích thực sự của câu hỏi thiết kế không phải là tìm ra tính năng hoàn hảo (vì không ai làm được điều đó trong 30 phút). Người phỏng vấn muốn xem cách bạn kiểm soát rủi ro. Việc vội vã đưa ra giải pháp chứng tỏ bạn suy nghĩ quá nhanh và thiếu chiều sâu phân tích.
Junior PM yêu giải pháp của họ. Senior PM tập trung vào vấn đề mà họ đang cố gắng giải quyết.
Playbook Của Senior PM: Làm Chủ "Problem Space"
Để thoát khỏi cái bẫy Solutionism, hãy áp dụng tư duy chậm lại để đi nhanh hơn. Khi nhận được một yêu cầu mơ hồ, hãy thực hiện 3 bước "neo" vấn đề sau:
Bước 1: Đóng Khung Vấn Đề (Frame the Problem)
Thay vì đưa ra câu trả lời, hãy đặt câu hỏi ngược lại cho Stakeholders hoặc người phỏng vấn để thu hẹp phạm vi (Scope).
"Tập người dùng mục tiêu (Target Persona) của chúng ta trong use-case này là ai? Khách hàng văn phòng hay sinh viên?"
"Tại sao chúng ta lại ưu tiên tính năng này ở Quý 3 mà không phải lúc khác?"
Bước 2: Định Nghĩa Thành Công (Define Success & Metrics)
Đừng xây dựng thứ gì nếu bạn không biết cách đo lường nó. Hãy xác định North Star Metric cho tính năng này.
"Nếu tính năng này thành công, chỉ số nào sẽ thay đổi? Chúng ta đang tối ưu cho Conversion Rate hay Retention Rate?"
Bước 3: Lên Kịch Bản Đánh Đổi (Evaluate Trade-offs)
Trước khi chốt phương án cuối cùng, hãy đưa ra ít nhất 2 hướng tiếp cận và phân tích sự đánh đổi.
Phương án A (Tốc độ): MVP cơ bản, không có tracking real-time, triển khai trong 2 tuần. Đánh đổi: Trải nghiệm người dùng kém mượt mà.
Phương án B (Chất lượng): Tích hợp deep-link, real-time map, chia tiền tự động. Triển khai trong 2 tháng. Đánh đổi: Rủi ro trễ tiến độ (Time-to-market).
Bằng cách từ chối việc nhảy ngay vào giải pháp, bạn định vị bản thân không phải là một "người nhận order" (Order Taker), mà là một người giải quyết vấn đề chiến lược (Strategic Problem Solver).
Case StudyApr 11, 2026
Bài Toán "Chấm Xanh" Của Slack: Cơn Ác Mộng Kiến Trúc Thời Gian Thực
Việc hiển thị trạng thái online tưởng chừng cơ bản nhưng lại là bài toán hạ tầng khổng lồ ở quy mô lớn. Phân tích cách Slack cấu trúc lại mô hình Pub/Sub để cân bằng giữa độ chính xác realtime và chi phí máy chủ.
