Nghĩ như người làm sản phẩm

Tưởng tượng mèo con thuê thợ xây nhà mà chỉ nói "xây cho tôi một căn nhà đẹp". Thợ giỏi tới đâu cũng chịu - vì "đẹp" với mèo con và "đẹp" với thợ là hai thứ khác nhau. Kết quả gần như chắc chắn không vừa ý. Lỗi không ở tay nghề người thợ, mà ở bản mô tả.

Với Claude Code y hệt. Nó gõ code rất nhanh, nhưng nó dựng đúng thứ bạn NÓI, không phải thứ bạn NGHĨ trong đầu. Vì thế kỹ năng quyết định của người vibe coding không phải là gõ code - mà là mô tả chính xác thứ mình muốn. Dân trong nghề gọi vui quy luật này là "rác vào, rác ra" (garbage in, garbage out).

• ▸AI dựng đúng thứ bạn MÔ TẢ, không phải thứ bạn nghĩ trong đầu.
• ▸Mô tả mơ hồ thì kết quả mơ hồ - "rác vào, rác ra".
• ▸Kỹ năng cốt lõi của khoá này là viết mô tả rõ, không phải gõ code.

Trước khi mô tả cho AI, hãy tự trả lời bốn câu hỏi nền. Đây chính là bộ khung mà người làm sản phẩm (product owner) dùng, gói gọn lại cho mình:

• ▸Cho AI? - người dùng là ai (khách mua hàng, hay admin quản lý)?
• ▸Họ làm được GÌ? - những việc chính họ cần làm trên sản phẩm.
• ▸MVP là gì? - bản nhỏ nhất vừa chạy được vừa có ích, ship trước.
• ▸"Xong" là gì? - tiêu chí kiểm được để biết một việc đã hoàn thành.

Lấy ví dụ xuyên suốt khoá - một web bán hàng có ví: người dùng gồm khách (tạo tài khoản, nạp tiền, mua hàng) và admin (quản lý hàng, kho, giao dịch). Trả lời xong bốn câu này là mèo con đã có bộ xương của một bản spec.

Cách gọn nhất để ghi "họ làm được gì" là user story - một câu kể nhu cầu theo đúng mẫu, nêu cả việc lẫn lý do:

Mẫu: Là <vai>, tôi muốn <việc>, để <lợi ích>.

- Là khách, tôi muốn nạp tiền bằng quét QR, để mua hàng nhanh mà không cần thẻ.
- Là khách, tôi muốn xem số dư và lịch sử giao dịch, để biết mình còn bao nhiêu.
- Là admin, tôi muốn xem các giao dịch nạp tiền, để đối soát cuối ngày.

Vì mỗi story nêu rõ lợi ích ("để…"), nó giúp mèo con kiểm lại xem tính năng có đáng làm không - và giúp Claude hiểu ý ĐỒ đằng sau, chứ không chỉ thao tác bề mặt.

Ai cũng có một đống mơ ước: web bán hàng thì muốn có nạp tiền, khuyến mãi, đánh giá sao, chat với shop, gợi ý sản phẩm, app điện thoại… Ôm hết một lúc là công thức để không bao giờ ship. Người làm sản phẩm giỏi cắt xuống còn MVP (Minimum Viable Product) - bản nhỏ nhất vừa chạy vừa có ích:

Mơ ước (để sau):  khuyến mãi, đánh giá sao, chat, gợi ý, app mobile…

MVP (làm trước):
  1. Đăng ký / đăng nhập
  2. Xem danh sách hàng
  3. Nạp tiền vào ví (quét QR)
  4. Mua hàng -> trừ số dư

Ship được bốn việc này là đã có một sản phẩm chạy được để đưa cho người dùng đầu tiên. Phản hồi của họ đáng giá hơn mọi tính năng mèo con đoán mò trong phòng kín.

Cách nghĩ này có tên: vòng dựng → đo → học (build-measure-learn). Mỗi MVP là một giả thuyết ("mình đoán khách cần X") đem ra cho người dùng để kiểm: đo xem họ có dùng không, rồi học và sửa ở vòng sau. Ship không phải đích đến, mà là cách học nhanh nhất xem mình đoán đúng hay sai.

Gộp bốn câu hỏi + user story + phạm vi MVP lại, mèo con có một tài liệu BA (Business Analysis) - bản thiết kế bằng lời cho cả người và AI. Đây là thứ dân làm sản phẩm chuyên nghiệp luôn có trước khi code. Khung một tài liệu BA gọn:

# Web bán hàng có ví - Tài liệu BA

## 1. Bối cảnh & mục tiêu
## 2. Người dùng & vai trò (khách, admin)
## 3. User stories
## 4. Phạm vi MVP (làm trước)
## 5. Definition of done (tiêu chí "xong")
## 6. Ngoài phạm vi (để sau)

Có tài liệu BA rồi, cách dùng rất đơn giản: đưa nó cho Claude Code ngay đầu phiên, bảo nó đọc và hỏi lại những chỗ chưa rõ trước khi dựng. Rồi bắt đầu từ một user story nhỏ thay vì đòi cả sản phẩm trong một câu. Ở bài sau, ta sẽ gắn tài liệu này vào bộ nhớ dự án (CLAUDE.md) để mọi phiên đều bám theo. Và với việc lớn, đừng để Claude lao vào sửa ngay - bảo nó lập kế hoạch trước từ BA (plan mode) để bạn duyệt hướng đi rồi mới cho dựng; cách dùng có ở bài Dựng app Next.js đầu tiên.