Thay vì ngay lập tức đưa ra tính năng khi đối mặt với một yêu cầu sản phẩm, CIRCLES ép PM đi theo một hệ thống tư duy tuyến tính: Nắm rõ mục tiêu -> Chọn đúng người -> Đào sâu "nỗi đau" -> Ưu tiên -> Đề xuất -> Đánh giá -> Kết luận. Khẩu quyết ở đây là: Luôn làm chủ Problem Space trước khi bước chân vào Solution Space.
1. CIRCLES Method là gì? (Định nghĩa & Thành phần)
CIRCLES là một framework được thiết kế bởi Lewis C. Lin, đặc biệt hữu dụng trong các tình huống yêu cầu sự sáng tạo và tư duy thiết kế (Product Design / Product Sense). Thay vì hoảng loạn trước một đề bài quá mở (VD: "Thiết kế một chiếc đồng hồ báo thức cho người khiếm thị"), CIRCLES chia bài toán thành 7 bước có thể kiểm soát được.
Bảy thành phần bao gồm:
C - Comprehend the situation (Hiểu bối cảnh): Xác định chữ "Tại sao" (Why). Mục tiêu kinh doanh cốt lõi ở đây là gì? (Growth, Engagement, Monetization, hay Retention?). Rào cản là gì?
I - Identify the customer (Xác định khách hàng): Xác định chữ "Ai" (Who). Vẽ ra các User Persona cụ thể, không dùng tập khách hàng chung chung.
R - Report customer's needs (Báo cáo nhu cầu khách hàng): Trả lời chữ "Cái gì" (What). User cần gì? Vấn đề/Pain point hiện tại của họ là gì? Thường được viết dưới dạng User Story.
C - Cut, through prioritization (Sàng lọc và Ưu tiên): Đánh giá xem pain point nào là đáng giá nhất để giải quyết trước.
L - List solutions (Liệt kê giải pháp): Trả lời chữ "Như thế nào" (How). Brainstorm ít nhất 3 giải pháp từ thực tế đến đột phá (Moonshot).
E - Evaluate trade-offs (Đánh giá rủi ro/đánh đổi): Phân tích điểm mạnh, điểm yếu của từng giải pháp để chứng minh bạn có System Thinking, không bị "yêu thiên lệch" giải pháp của chính mình.
S - Summarize your recommendation (Tổng kết đề xuất): Đưa ra phán quyết cuối cùng một cách gãy gọn: Chốt làm cái gì, mang lại giá trị gì, và làm sao để đo lường (Metrics).
2. Khi nào nên áp dụng? (Use Cases & Target Audience)
Phỏng vấn Product Design & New Product: Khi nhận được các câu hỏi dạng "How would you improve X?" hoặc "Design an app for Y". Đây là bối cảnh mà CIRCLES tỏa sáng nhất.
Khởi tạo dự án (Project Kick-off): Khi team bị sa lầy vào việc tranh luận về UI/UX hoặc các tính năng vụn vặt mà quên mất mục tiêu kinh doanh ban đầu.
CIRCLES Method: Framework Thiết Kế Sản Phẩm Chuyên Sâu | Product Decode
Phân tích Yêu cầu (BA/PO): Khi nhận được yêu cầu từ Stakeholder (ví dụ: "Tôi muốn có nút chia sẻ lên mạng xã hội") và bạn cần lùi lại để "decode" nhu cầu thực sự phía sau.
3. Hướng dẫn từng bước (Deep Dive)
Để thực thi CIRCLES hiệu quả, đừng coi nó là một checklist vô hồn. Hãy coi đó là một mạch truyện (narrative) bạn đang kể.
Bước 1: Comprehend (Khai mở bối cảnh) Không bao giờ assume (mặc định) bất cứ điều gì. Hãy đặt câu hỏi ngược lại cho interviewer hoặc stakeholder:
"Mục tiêu của chúng ta ở đây là tăng doanh thu (Monetization) hay chiếm lĩnh thị phần (Acquisition)?"
"Chúng ta có ràng buộc nào về thời gian hay công nghệ không?"
Bước 2 & 3: Identify & Report (Tìm người và Đào sâu) Liệt kê 2-3 persona. Ví dụ: Thiết kế app đặt xe cho sinh viên. Persona 1: Sinh viên bận rộn cần xe nhanh. Persona 2: Sinh viên nghèo muốn ghép chuyến để tiết kiệm. Phác thảo User Story: "Là một sinh viên ngân sách hạn hẹp, tôi muốn chia sẻ cuốc xe với người cùng trường để giảm 50% chi phí di chuyển hàng ngày."
Bước 4: Cut (Ưu tiên tàn nhẫn) Đây là bước tách biệt một PM giỏi và PM xuất sắc. Bạn không thể giải quyết mọi pain point. Hãy chọn 1 hoặc 2 pain point dựa trên ma trận Impact vs. Effort hoặc sự phù hợp với mục tiêu ở Bước 1.
Bước 5: List Solutions (Bung xõa giải pháp) Áp dụng quy tắc "1 Safe, 1 Stretch, 1 Moonshot".
Safe: Giải pháp an toàn, dễ làm, đối thủ đã có.
Stretch: Giải pháp tận dụng thế mạnh lõi của công ty.
Moonshot: Giải pháp ứng dụng công nghệ tương lai (AI, AR, IoT) tạo sự khác biệt.
Bước 6 & 7: Evaluate & Summarize (Chốt hạ có cơ sở) So sánh các giải pháp dựa trên nguồn lực hiện tại. Trình bày rủi ro và cách mitigate rủi ro đó. Cuối cùng, nói rõ: "Dựa trên mục tiêu ban đầu là X, để phục vụ người dùng Y, tôi đề xuất triển khai giải pháp Z vì..."
4. Ví dụ thực tế (Case Study Application)
Đề bài: Thiết kế tính năng mới cho Spotify nhằm phục vụ tệp người dùng lớn tuổi (60+).
C (Bối cảnh): Mục tiêu giả định là tăng User Acquisition ở tệp lớn tuổi, do tệp GenZ/Millennials đã bão hòa. Nền tảng: Mobile App.
I (Người dùng): Nhóm 1: Người già gặp khó khăn khi thao tác cảm ứng (mắt kém, run tay). Nhóm 2: Người già thích hoài niệm, muốn nghe cải lương/nhạc xưa nhưng không biết tìm kiếm. Lựa chọn: Nhóm 1.
R (Nhu cầu): "Là một người lớn tuổi, tôi muốn nghe lại các bản nhạc thập niên 70 mà không phải nhìn vào màn hình để gõ phím."
C (Ưu tiên): Chọn giải quyết pain point cốt lõi: Giao diện tương tác và khả năng tìm kiếm (Accessibility & Discovery).
L (Giải pháp):
Senior UI Mode: Giao diện đơn giản hóa, text khổng lồ, chỉ có nút Play/Pause. (Safe)
Voice-only Mode: Tích hợp nhận diện giọng nói siêu nhạy, kích hoạt bằng "Hey Spotify, mở nhạc xưa". (Stretch)
Nostalgia AI Radio: Spotify tạo kênh radio giả lập giọng phát thanh viên thời xưa đọc tên bài hát và chuyển bài. (Moonshot)
E (Trade-off):
Voice-only Mode rất phù hợp, nhưng rào cản là nhận diện phương ngữ địa phương của người lớn tuổi rất kém.
Senior UI Mode dễ làm, chi phí thấp (Low Effort), nhưng chưa chắc đủ hấp dẫn để lôi kéo họ cài app (Low Impact).
S (Tổng kết): Đề xuất triển khai Voice-only Mode kết hợp Nostalgia Radio dưới dạng MVP ở một số thành phố lớn. Đo lường thành công thông qua: Tỷ lệ Voice Search kích hoạt thành công (Voice accuracy rate) và Time spent listening.
5. Anti-patterns & Những cạm bẫy cần tránh (Trade-offs)
Dù CIRCLES rất mạnh mẽ, việc lạm dụng hoặc dùng sai cách sẽ tạo ra các Anti-patterns (tác dụng ngược) nguy hiểm:
Hội chứng "Robot Framework": Quá cứng nhắc đọc tên từng bước trong lúc phỏng vấn ("Bây giờ tôi xin chuyển sang chữ C tiếp theo..."). Điều này khiến bạn giống một cỗ máy học thuộc lòng. Thay vào đó, hãy chuyển ý tự nhiên: "Giờ chúng ta đã biết đối tượng là ai, hãy cùng xem vấn đề lớn nhất của họ là gì..."
Mất cân bằng Thời gian (Kẹt ở Problem Space): PM thường có xu hướng phân tích User Persona quá say sưa (mất 25 phút) và khi đến phần cốt lõi là Đưa ra giải pháp (Solution) và Đánh giá (Evaluate) thì chỉ còn 5 phút. Hãy canh thời gian: 40% cho Problem, 60% cho Solution & Trade-offs.
Thiếu tính "Cruel Prioritization" (Ưu tiên yếu ớt): Liệt kê 5 vấn đề, rồi... chọn giải quyết cả 5 vì "cái nào cũng quan trọng". Bản chất của chiến lược là sự đánh đổi. Nếu bạn không dám loại bỏ (Cut), bạn đang làm sai framework.
"Quên" Evaluate Trade-offs: Rất nhiều PM đưa ra ý tưởng tuyệt vời (như dùng GenAI) nhưng lờ đi việc server cost (chi phí máy chủ) sẽ tăng vọt hoặc response latency (độ trễ) cao khiến UX tệ đi. Thiếu E (Evaluate) là điểm trừ chí mạng về System Thinking.
Sẵn sàng làm chủ Product Sense? Đừng chỉ học thuộc lòng framework. Kỹ năng thiết kế sản phẩm đòi hỏi sự linh hoạt và phản xạ thực tế. Hãy thử sức ngay với các mock-interview câu hỏi Product Design tại Product Decode để rèn luyện cách ứng biến với các biến số kinh doanh thực tế!
