Quy trình làm sản phẩm trong kỷ nguyên Vibe Code
Quy trình làm sản phẩm trong kỷ nguyên vibe coding
Có một nghịch lý mà bất kỳ ai build sản phẩm trong vài năm gần đây đều sẽ nhận ra: công cụ ngày càng mạnh, tốc độ code ngày càng nhanh, nhưng số sản phẩm thực sự đến tay người dùng và được họ giữ lại thì không tăng tương ứng.
AI có thể viết một REST API hoàn chỉnh trong vài phút. Cursor có thể scaffold toàn bộ frontend chỉ qua vài prompt. Nhưng cái bị bỏ lại phía sau không phải là năng lực kỹ thuật — đó là tư duy sản phẩm.
Vibe coding giải phóng bạn khỏi việc viết code. Nó không giải phóng bạn khỏi việc phải nghĩ.
Bài viết này không phải một framework mới. Đây là cách mình nhìn lại quy trình PRD → Plan → Technical Design → Build → Iterate sau khi áp dụng nó trong bối cảnh AI-assisted development — và tại sao mỗi bước lại mang ý nghĩa khác đi so với trước.
1. PRD — Không phải tài liệu, mà là bản đồ tư duy
Trong môi trường truyền thống, PRD thường là một tài liệu nặng nề mà team đọc một lần rồi để yên trong Notion. Trong kỷ nguyên vibe coding, nó đóng vai trò hoàn toàn khác: đây là thứ duy nhất giữ cho bạn và AI không đi lạc cùng nhau.
Khi bạn prompt AI mà không có một mental model rõ ràng về sản phẩm, điều xảy ra không phải là AI tạo ra thứ sai — mà là AI tạo ra thứ hợp lý nhưng không phải thứ bạn cần. Sự khác biệt đó rất tinh tế và cực kỳ tốn kém.
AI sẽ luôn cho bạn một câu trả lời. Vấn đề là bạn có đang hỏi đúng câu hỏi không.
Một PRD hiệu quả không cần dài, nhưng phải trả lời được những câu hỏi căn bản nhất:
- Người dùng là ai — không phải "tất cả mọi người", mà là một người cụ thể với một vấn đề cụ thể
- Họ đang chịu đựng điều gì — pain point đủ lớn để họ chịu thay đổi thói quen
- MVP thực sự là gì — ranh giới rõ ràng giữa "cần có ngay" và "có thì tốt"
- User flow trông như thế nào — từ lần đầu tiên mở app đến khi tạo ra giá trị đầu tiên
Ranh giới của MVP cần được vẽ ra trước khi mở editor, không phải trong lúc code. Mỗi feature bạn thêm vào mà không có trong PRD ban đầu đều là một khoản nợ cần trả — bằng thời gian, bằng độ phức tạp, hoặc bằng cả hai.
2. Plan — Thứ tự quan trọng hơn tốc độ
Không có gì lãng phí hơn việc làm thật tốt một thứ không cần làm lúc này.
Phần lớn các sản phẩm thất bại không phải vì thiếu năng lực, mà vì sai thứ tự. Những sai lầm kinh điển vẫn lặp lại đều đặn:
- Build UI trước khi có data model ổn định
- Làm authentication trước khi validate core flow
- Tối ưu performance trước khi có người dùng đầu tiên
- Làm feature "thú vị" trước khi làm feature "cần thiết"
Với AI, những sai lầm này càng dễ xảy ra hơn, vì mọi thứ đều có thể được tạo ra nhanh chóng. Sự dễ dàng đó che khuất câu hỏi quan trọng hơn: cái này có cần làm lúc này không?
Một framework đơn giản để kiểm tra: nếu bỏ feature này ra khỏi MVP, sản phẩm có còn hoạt động không? Nếu có — đó là feature của phase 2. Kỷ luật này, không phải tốc độ code, mới là thứ quyết định bạn ra được MVP hay mắc kẹt giữa đường.
Plan tốt không cần Gantt chart hay sprint phức tạp. Nó chỉ cần xác định rõ: phase nào làm gì, milestone nào là điểm kiểm tra, và — quan trọng nhất — thứ tự logic để mỗi bước build trên nền của bước trước.
3. Technical Design — Bước bị bỏ qua nhiều nhất, và đắt giá nhất
Đây là điểm mà vibe coding dễ tạo ra ảo giác nhất. Bạn có thể có một ứng dụng chạy được trong vài giờ. Database schema hình thành tự nhiên qua từng prompt. API endpoint được thêm vào khi cần. Mọi thứ trông có vẻ ổn — cho đến khi không còn ổn nữa.
Kiến trúc hệ thống tệ không giết chết sản phẩm ngay lập tức. Nó giết chết sản phẩm từ từ — bằng bug, bằng chi phí refactor, bằng sự mệt mỏi của người build nó.
Technical design không phải là vẽ diagram cho đẹp. Đó là quá trình buộc bạn phải nghĩ trước về những câu hỏi mà bạn sẽ phải trả lời sau dù muốn hay không:
- Dữ liệu di chuyển như thế nào qua hệ thống — từ input của user đến output cuối cùng?
- Khi có 10,000 records thay vì 100, điều gì sẽ vỡ đầu tiên?
- Các thành phần trong hệ thống phụ thuộc vào nhau như thế nào — và phụ thuộc đó có thể trở thành điểm chết không?
- Error handling được xử lý ở đâu, và khi fail thì user nhìn thấy gì?
Với sản phẩm có AI component — dịch thuật, summarization, content generation — bước này càng không thể bỏ qua. Chunking strategy, queue design, retry logic, cost tracking: đây không phải optimization sau này. Đây là foundation. Bỏ qua nó trong tuần đầu, bạn sẽ phải rewrite toàn bộ trong tuần thứ tư.
4. Build — Đây mới là lúc vibe coding thực sự phát huy sức mạnh
Sau khi ba bước trên đã được thực hiện nghiêm túc, giai đoạn build trở thành trải nghiệm mà mọi người hay mô tả khi nói về vibe coding: nhanh, trơn tru, và gần như thú vị.
Lý do không phải vì AI giỏi hơn. Mà vì bạn đã cho nó đủ context để làm đúng việc.
Một prompt được viết với hiểu biết về data schema, API contract, và business logic sẽ tạo ra output hoàn toàn khác so với một prompt viết từ trong chân không.
Trong giai đoạn này, có một vài nguyên tắc giúp giữ momentum mà không mất kiểm soát:
- Commit theo logic, không theo cảm xúc — đừng push code chỉ vì nó trông "xong rồi"
- Test assumption sớm — deploy bản thô cho 2–3 người dùng thực trước khi polish UI
- Ghi lại technical debt — những gì bạn biết là tạm thời cần được đánh dấu rõ ràng, không phải để quên
- Resist scope creep — mỗi "feature nhỏ thêm vào" đều có chi phí ẩn cao hơn vẻ ngoài của nó
Điều cần nhớ: tốc độ là hệ quả của sự chuẩn bị, không phải mục tiêu. Build nhanh trên nền móng sai chỉ đưa bạn đến điểm rewrite nhanh hơn.
5. Iterate — Nơi sản phẩm thực sự được tạo ra
Phiên bản đầu tiên của bạn là hypothesis, không phải solution. Càng sớm chấp nhận điều đó, bạn càng học được nhiều hơn.
Không có sản phẩm nào đúng ngay từ đầu — đây không phải câu nói để an ủi. Đây là đặc tính cơ bản của quá trình phát triển sản phẩm, được xác nhận lặp đi lặp lại bởi hầu hết mọi sản phẩm thành công mà bạn biết.
Iteration có giá trị khi nó được dẫn dắt bởi dữ liệu thực, không phải cảm tính của founder. Những câu hỏi cần trả lời được bằng số liệu:
- Người dùng bỏ ở bước nào trong flow?
- Feature nào họ tìm mà không thấy — và họ tìm ở đâu?
- Session trung bình kéo dài bao lâu, và tăng hay giảm theo thời gian?
- Người dùng quay lại vì lý do gì — hay họ không quay lại?
Cảm tính của founder thường sai ở đây — không phải vì founder thiếu kinh nghiệm, mà vì founder không phải người dùng. Khoảng cách giữa "thứ mình nghĩ user cần" và "thứ user thực sự làm" thường lớn hơn nhiều so với dự đoán.
Trong bối cảnh vibe coding, iteration cycle có thể được rút ngắn đáng kể. Một insight từ user feedback có thể được test trong vài giờ thay vì vài ngày. Nhưng giá trị của tốc độ đó chỉ xuất hiện nếu bạn có hệ thống thu thập và đọc hiểu feedback một cách có chủ đích — không phải đợi user tự email cho bạn.
Nhìn lại toàn bộ
PRD → Plan → Technical Design → Build → Iterate không phải một quy trình tuyến tính. Đây là một vòng lặp, và mỗi vòng bạn hiểu sản phẩm và người dùng sâu hơn một chút.
Những gì AI thay đổi không phải là logic của quy trình này — mà là chi phí của từng vòng lặp. Khi iterate rẻ hơn, bạn có thể làm nhiều vòng hơn. Khi build nhanh hơn, bạn có thể test nhiều hypothesis hơn.
Nhưng nếu thiếu quy trình, tốc độ cao hơn chỉ có một nghĩa: bạn đi sai hướng nhanh hơn.
Thứ quyết định sản phẩm của bạn tồn tại hay biến mất không phải là công cụ bạn dùng. Đó là khả năng bạn duy trì được tư duy rõ ràng — về người dùng, về ưu tiên, về hệ thống — trong suốt quá trình build, bất kể AI có thể làm thay bạn bao nhiêu đi nữa.