problem-statement

Tổng quan về skill problem-statement

problem-statement giúp bạn biến một yêu cầu sản phẩm mơ hồ thành một problem statement đặt người dùng ở trung tâm, nêu rõ ai đang bị cản trở, họ đang cố làm gì, vì sao điều đó quan trọng và cảm giác của họ ra sao. Đây là skill hữu ích nhất khi bạn cần tạo sự đồng thuận trước khi bước vào giải pháp: discovery, ưu tiên hóa, PRD và review với stakeholder.

problem-statement dùng để làm gì

Skill problem-statement này được thiết kế cho việc định khung vấn đề, không phải thiết kế tính năng. Nó giúp bạn mô tả vấn đề từ góc nhìn người dùng để các team có thể đánh giá liệu công việc đó có đáng làm hay không trước khi tranh luận về cách triển khai.

Phù hợp nhất với ai

Hãy dùng skill này nếu bạn viết product brief, technical spec, bản tóm tắt nghiên cứu hoặc ghi chú roadmap và cần một câu chuyện vấn đề rõ ràng, gọn hơn. Đây cũng là lựa chọn rất hợp cho workflow Technical Writing khi bạn cần chuyển đầu vào lộn xộn thành một problem statement ngắn gọn, có tính đồng cảm.

Điểm khác biệt là gì

Skill này đặt trọng tâm vào khung định hình vấn đề: I am, Trying to, But, Because, và Which makes me feel, kèm theo bối cảnh và ràng buộc. Cấu trúc đó hữu ích cho quyết định hơn một prompt chung chung, vì nó buộc bạn phải nêu cả điểm nghẽn về chức năng lẫn tác động lên con người.

Cách sử dụng skill problem-statement

Cài đặt và xem qua skill

Cài đặt bằng:

npx skills add deanpeters/Product-Manager-Skills --skill problem-statement

Sau đó đọc skills/problem-statement/SKILL.md trước, rồi đến template.md và examples/sample.md. Đây là cách nhanh nhất để hiểu hình dạng đầu ra mong đợi, kết quả cuối cùng và một problem statement hoàn chỉnh tốt trông như thế nào.

Cần cung cấp gì trong prompt

Để dùng problem-statement hiệu quả, hãy đưa vào một đầu vào thô nhưng đủ cụ thể: loại người dùng, nhiệm vụ họ muốn hoàn thành, điểm nghẽn và các ràng buộc liên quan. Nếu bạn chỉ đưa một feature request, đầu ra rất dễ trượt sang ngôn ngữ giải pháp thay vì mô tả đúng vấn đề.

Một đầu vào mạnh hơn sẽ trông như sau:

• Persona: “new support agents on mobile”
• Goal: “resolve tickets without switching tools”
• Blocker: “they lose context between CRM and chat”
• Constraints: “high volume, low training time, remote-first team”

Workflow gợi ý

Bắt đầu bằng một bản nháp ngắn, rồi tinh gọn nó thành câu chuyện năm phần. Dùng template như một checklist: nếu Because nghe giống một giải pháp, hãy quay lại hỏi điều gì thực sự đang gây ra nỗi đau. Nếu Which makes me feel quá chung chung, hãy thay bằng một cảm xúc thật của người dùng gắn trực tiếp với workflow.

Những file nên đọc trước

Ưu tiên SKILL.md, template.md, và examples/sample.md. File ví dụ đặc biệt hữu ích vì nó cho thấy cả một mẫu framing tốt lẫn một anti-pattern, giúp bạn tránh viết ra một giải pháp trá hình thay vì một problem statement.

FAQ về skill problem-statement

problem-statement có chỉ là một prompt template không?

Không. Skill problem-statement là một phương pháp định khung có thể tái sử dụng, chứ không chỉ là một prompt điền chỗ trống. Giá trị của nó nằm ở việc buộc bạn làm rõ người dùng, điểm nghẽn và nguyên nhân gốc trước khi viết PRD hoặc đề xuất cách khắc phục.

Khi nào thì không nên dùng?

Đừng dùng problem-statement nếu bạn đã có một tài liệu yêu cầu được xác định rõ phạm vi, hoặc nếu bạn đang ghi chép chi tiết triển khai. Nó cũng không phù hợp khi mục tiêu là brainstorm giải pháp; skill này tập trung vào việc xác định đúng vấn đề trước tiên.

problem-statement có phù hợp cho người mới không?

Có, nếu bạn có thể mô tả một người dùng và một điểm đau bằng ngôn ngữ đơn giản. Template thì đơn giản, nhưng chất lượng phụ thuộc vào việc bạn có tách được vấn đề của người dùng ra khỏi giải pháp mình thích hay không.

Nó phù hợp thế nào với công việc Technical Writing?

Với Technical Writing, skill này rất hữu ích khi bạn cần làm rõ nỗi đau của độc giả, hỗ trợ một yêu cầu tài liệu, hoặc định khung một khoảng trống nội dung trước khi viết. Nó giúp bạn giữ cho tài liệu tập trung vào kết quả, thay vì trôi sang kể lại tính năng.

Cách cải thiện skill problem-statement

Cung cấp bằng chứng, không phải khẩu hiệu

Kết quả tốt nhất từ problem-statement đến từ những quan sát cụ thể: người dùng đã thử gì, họ bị kẹt ở đâu, họ dùng gì thay thế, và điều gì đã hỏng. “Users are confused” là quá yếu; “first-time admins cannot finish setup because the UI hides the required API key field” tốt hơn nhiều.

Tách vấn đề khỏi giải pháp

Một lỗi rất thường gặp là lén nhét giải pháp vào bản nháp. Nếu draft của bạn viết “users need a dashboard,” hãy viết lại thành “users cannot compare account health across services because status signals are scattered.” Như vậy sẽ giữ problem-statement tập trung vào rào cản thực sự.

Thêm các ràng buộc làm thay đổi câu trả lời

Hãy đưa vào bất kỳ yếu tố nào ảnh hưởng đến hình dạng của vấn đề: thiết bị, quy mô team, áp lực thời gian, tuân thủ, mức độ kinh nghiệm, hoặc giới hạn của nền tảng. Những chi tiết này làm cho problem statement đáng tin hơn và giúp đầu ra cuối cùng hỗ trợ ưu tiên hóa tốt hơn.

Lặp từ bản nháp đến mức đủ để ra quyết định

Sau lần đầu tiên tạo output, hãy kiểm tra xem statement đã đủ cụ thể để qua được stakeholder review chưa. Nếu chưa, hãy siết chặt persona, làm cho phần Because thể hiện rõ quan hệ nguyên nhân, và đảm bảo câu cuối có thể đọc được mà không cần giải thích thêm.