AI đang ép quy trình phát triển sản phẩm đi quá nhanh

Ở workshop trước, mình chia sẻ nhiều hơn về việc AI đang rút ngắn vòng lặp phát triển sản phẩm như thế nào.

Từ discovery, phân tích dữ liệu, viết tài liệu, lên coding plan cho tới debug, gần như bước nào cũng có thể được tăng tốc mạnh nếu team biết cách xây workflow và gom context đủ tốt.

Nhưng càng đi sâu vào thực tế, mình càng thấy cần nói thêm một nửa còn lại của câu chuyện.

AI không chỉ tăng tốc execution. AI còn đang ép toàn bộ quy trình phát triển sản phẩm đi quá nhanh.

Và khi mọi thứ đi quá nhanh, một loạt vấn đề mới bắt đầu xuất hiện:

• AI cũng có thể tham gia tạo giải pháp
• Ranh giới vai trò trở nên mờ hơn
• Số lượng output tăng nhanh hơn năng lực ra quyết định của team
• Quá trình phản biện bị rút ngắn
• Cảm giác “đã làm được rồi” dễ đến sớm hơn rất nhiều so với mức độ sẵn sàng thật của sản phẩm

Nói cách khác, AI không chỉ tạo ra đòn bẩy. Nó cũng tạo ra một kiểu hỗn loạn mới.

Trước đây, vai trò được phân tách vì chi phí thực thi cao

Trước khi AI bước vào sâu như bây giờ, việc chuyển một ý tưởng thành sản phẩm thường đi qua nhiều lớp handoff:

• Business hoặc sales nêu nhu cầu thị trường
• PM/PO phân tích bài toán, ưu tiên và xác định phạm vi
• Design chuyển hóa thành trải nghiệm
• Engineering hiện thực hóa bằng hệ thống, code, test, release

Quy trình này chậm, đúng. Nhưng chính độ chậm đó cũng tạo ra một số lớp bảo vệ tự nhiên.

Không phải ai cũng có thể nhảy vào làm prototype. Không phải ai cũng có thể tự viết code. Không phải ai cũng có thể biến một mong muốn mơ hồ thành một thứ chạy được.

Muốn đi tiếp, mọi người buộc phải ngồi lại với nhau lâu hơn để làm rõ:

• Vấn đề thật là gì
• Use case nào quan trọng nhất
• Đâu là constraint của hệ thống
• Trade-off nào có thể chấp nhận

Chi phí thực thi cao vô tình khiến team phải tôn trọng giai đoạn suy nghĩ.

Còn bây giờ, chi phí tạo ra “một lời giải nhìn có vẻ đúng” giảm gần về 0

Đây là thay đổi lớn nhất mình quan sát được.

Hôm nay:

• Một bạn BD có thể dùng AI để dựng luôn flow và code ra một bản demo
• Một bạn designer có thể rất tự tin đi sâu vào frontend vì AI đã hỗ trợ translate thiết kế sang code
• Một PM có thể tự draft PRD, task breakdown, tech plan và cả test case
• Một engineer có thể tự đi rất nhanh từ yêu cầu đến UI hoàn chỉnh mà chưa cần nhiều vòng trao đổi

Tất cả điều đó đều là tín hiệu tốt. Nó cho thấy rào cản tham gia vào việc xây dựng sản phẩm đang thấp đi rất nhiều.

Nhưng đây cũng là lúc team dễ rơi vào một cái bẫy mới:

Khi ai cũng tạo được solution rất nhanh, mọi người dễ ngộ nhận rằng mình đã hiểu bài toán đủ sâu.

Prototype nhanh không đồng nghĩa với understanding nhanh. Code chạy được không đồng nghĩa với product đã đúng. UI đẹp không đồng nghĩa với workflow đã bền.

Vấn đề không phải là “ai được làm gì”

Mình không nghĩ câu trả lời đúng là dựng lại hàng rào cứng giữa các vai trò.

Mình không nghĩ nên nói:

• BD thì đừng chạm vào solution
• Design thì đừng đụng vào code
• PM thì đừng bàn về kỹ thuật
• Dev thì đừng góp ý trải nghiệm

Thực tế, AI đang làm điều ngược lại: nó cho phép mọi người hiểu việc của nhau hơn, thử nhanh hơn và đóng góp sâu hơn.

Đó là điều tốt.

Vấn đề thật sự không nằm ở chuyện ai tham gia. Vấn đề nằm ở chuyện team commit cái gì, dựa trên tiêu chuẩn nào, và ai chịu trách nhiệm cuối cùng.

AI làm mờ ranh giới vai trò, nhưng nó không xóa được trách nhiệm.

1. Khi cost của solution giảm, team rất dễ bỏ qua problem framing

Ngày xưa, vì build một thứ khá tốn công, team buộc phải cân nhắc kỹ trước khi làm.

Bây giờ, vì “làm thử luôn” quá dễ, team rất dễ nhảy thẳng từ tín hiệu sang giải pháp.

Ví dụ:

• Nghe một lời phàn nàn từ khách hàng và lập tức generate ngay một flow mới
• Thấy drop-off tăng và vội redesign màn thanh toán
• Nhận một yêu cầu từ business rồi bắt đầu build dashboard, automation hoặc AI assistant ngay

Trong nhiều trường hợp, thứ bị rút ngắn không phải chỉ là lead time. Thứ bị rút ngắn còn là thời gian để nghi ngờ chính giả định của mình.

Đây là mất mát nguy hiểm, vì product quality không chỉ đến từ tốc độ build. Nó đến từ chất lượng của câu hỏi trước khi build.

2. Local optimum xuất hiện ở khắp nơi

Khi nhiều người cùng có khả năng tự làm rất nhiều thứ, mỗi người đều có thể tối ưu rất mạnh cho lát cắt mình đang nhìn thấy.

BD tối ưu cho tốc độ chốt deal. Design tối ưu cho flow đẹp và cảm giác mượt. PM tối ưu cho tốc độ đi từ insight sang ticket. Engineer tối ưu cho khả năng ship nhanh và gọn.

Không ai sai hoàn toàn. Nhưng sản phẩm thường hỏng ở chính chỗ nhiều tối ưu cục bộ gặp nhau.

Ví dụ một flow mới có thể:

• Dễ demo hơn cho sale
• Đẹp hơn ở một màn hình cụ thể
• Dễ code hơn trong sprint này

…nhưng đồng thời:

• Phá consistency của toàn bộ hệ thống
• Sinh thêm edge case ở vận hành
• Làm tăng chi phí maintain
• Gây nhiễu mental model của người dùng cũ

AI khiến việc tạo ra local optimum dễ hơn bao giờ hết. Trong khi đó, giữ được global coherence của sản phẩm lại vẫn là một bài toán rất con người.

3. Số lượng output tăng nhanh hơn năng lực review

Đây là bottleneck mình thấy rõ nhất.

AI giúp một người tạo ra:

• Nhiều phương án hơn
• Nhiều tài liệu hơn
• Nhiều prototype hơn
• Nhiều code hơn
• Nhiều quyết định vi mô hơn

Nhưng số giờ tỉnh táo để review tốt vẫn gần như không đổi.

Khi đó, team bước vào một trạng thái rất lạ:

• Nhìn bề ngoài thì năng suất tăng mạnh
• Nhưng bên trong, năng lực kiểm định chất lượng không theo kịp

Và khi review không theo kịp, đội ngũ thường vô thức chọn một trong hai cách:

• Hoặc duyệt theo cảm giác vì “trông cũng ổn”
• Hoặc quay lại chậm hẳn vì quá tải trong việc đọc, check và phản biện

Cả hai đều là tín hiệu cho thấy tốc độ mới đang vượt quá operating model cũ.

4. Ranh giới vai trò mờ đi, nhưng accountability không tự xuất hiện

Đây là đoạn mình nghĩ nhiều team sẽ sớm đụng phải.

Một bạn designer hôm nay có thể chỉnh luôn frontend. Rất tuyệt.

Nhưng nếu sau đó:

• UI không khớp với design system ở những màn khác
• Code khó maintain
• Performance giảm
• Trạng thái edge case không được xử lý

…thì ai chịu trách nhiệm?

Tương tự, một bạn BD có thể dùng AI dựng ra giải pháp rất thuyết phục cho một nhu cầu khách hàng. Điều đó cực kỳ giá trị ở giai đoạn khám phá.

Nhưng nếu giải pháp đó:

• Chỉ đúng với một khách hàng lớn
• Kéo sản phẩm lệch khỏi chiến lược chung
• Tạo ra custom complexity cho các team còn lại

…thì ai có quyền nói “không”, và nói dựa trên nguyên tắc nào?

AI khiến việc đóng góp trở nên dân chủ hơn. Nhưng nếu không có cơ chế ownership rõ, nó cũng làm việc né trách nhiệm trở nên dễ hơn.

5. Team dễ nhầm lẫn giữa “ai cũng tham gia” và “ai cũng quyết định”

Mình rất thích một team nơi mọi người đều có product mindset. Mọi người đều hiểu user hơn, hiểu business hơn, hiểu technical constraint hơn.

Nhưng product mindset không có nghĩa là mọi quyết định đều trở thành đồng sở hữu theo nghĩa bằng nhau.

Trong thực tế, vẫn cần phân biệt rất rõ giữa:

• Quyền tham gia khám phá
• Quyền đề xuất
• Quyền phản biện
• Quyền commit vào roadmap, experience và codebase

Nếu không tách rõ các tầng này, team sẽ có cảm giác dân chủ hơn nhưng thực ra lại hỗn loạn hơn.

Mọi người đều nói được. Nhưng không ai thật sự biết quyết định cuối cùng đang được chốt ở đâu.

Điều đội product cần bây giờ không chỉ là AI literacy

Nhiều người nói team product bây giờ cần học prompt, học tools, học automation.

Đúng, nhưng chưa đủ.

Theo mình, thứ cần hơn là một operating model mới cho thời đại AI.

Một mô hình mà trong đó:

• AI cũng có thể khám phá và thử nghiệm rất nhanh
• Nhưng không ai được đốt thẳng khám phá thành cam kết sản phẩm mà thiếu review
• Mọi vai trò đều có thể đóng góp ngoài phạm vi cũ của mình
• Nhưng ownership của các quyết định quan trọng vẫn cực kỳ rõ ràng

Mình hay nghĩ về nó như sau:

Permissionless exploration, controlled commitment.

Khám phá thì mở. Cam kết thì phải có kiểm soát.

Một cách phân vai mới mình thấy hợp lý

AI không làm vai trò biến mất. Nó buộc vai trò phải được định nghĩa lại theo hướng ít handoff hơn nhưng rõ trách nhiệm hơn.

Ví dụ:

• Business/BD sở hữu tín hiệu thị trường, sức ép thương mại và context khách hàng
• PM/PO sở hữu problem framing, ưu tiên, trade-off và quyết định sản phẩm
• Design sở hữu interaction model, trải nghiệm xuyên suốt và sự nhất quán của hệ thống
• Engineering sở hữu tính đúng kỹ thuật, kiến trúc, độ ổn định, performance và maintainability
• QA hoặc những người làm quality sở hữu góc nhìn kiểm định rủi ro trước khi release

Trong mô hình này:

• BD hoàn toàn có thể dựng demo
• Design hoàn toàn có thể chạm vào code
• PM hoàn toàn có thể đi sâu vào data, viết task hoặc draft plan kỹ thuật
• Engineer hoàn toàn có thể góp ý về product và UX

Nhưng việc ai đó có thể làm một việc không đồng nghĩa với việc họ sở hữu quyết định cuối cùng của lớp đó.

Đó là khác biệt rất quan trọng.

Quy trình phát triển sản phẩm mới trong thời AI có lẽ nên như thế nào?

Nếu phải tóm lại ngắn gọn, mình nghĩ quy trình mới nên có ít nhất 4 lớp:

1. Mở rộng quyền khám phá

Cho phép mọi vai trò:

• Truy cập context tốt hơn
• Tự tra cứu dữ liệu
• Tự dựng prototype
• Tự dùng AI để mô phỏng giải pháp

Mục tiêu là tăng chất lượng đóng góp đầu vào.

2. Gom mọi thứ về một shared plan

Mọi tín hiệu, giả định, use case, constraint, decision log, scope và checkpoint cần hội tụ về cùng một plan chung.

Không phải để tài liệu đẹp hơn. Mà để team có một nơi duy nhất trả lời câu hỏi:

• Mình đang giải quyết vấn đề gì
• Vì sao làm bây giờ
• Chấp nhận trade-off nào
• Chưa chắc cái gì
• AI chịu trách nhiệm chốt từng lớp quyết định

3. Thiết kế các quality gate rõ hơn trước

Khi AI làm tăng tốc output, team cần tăng chất lượng checkpoint chứ không chỉ tăng số lượng output.

Ví dụ trước khi commit một hướng đi, cần check tối thiểu:

• Đây có đúng problem ưu tiên không
• Có phá logic sản phẩm hoặc kiến trúc hiện tại không
• AI sign-off phần experience
• AI sign-off phần kỹ thuật
• Metric hoặc tín hiệu nào sẽ xác nhận là mình đúng sau khi ship

4. Giữ review là một năng lực cốt lõi

Trong kỷ nguyên AI, năng lực quý hiếm không còn chỉ là “tự làm ra”.

Năng lực quý hơn là:

• Biết cái gì đáng làm
• Biết cái gì chưa nên làm
• Biết chỗ nào phải nghi ngờ
• Biết review đủ sâu để không bị đánh lừa bởi một output trông rất hoàn chỉnh

Nói cách khác, khi AI làm chi phí sản xuất giảm mạnh, năng lực phản biện và ra quyết định trở thành lợi thế cạnh tranh thật sự của team product.

AI không giết product process

Nó chỉ làm lộ ra quy trình nào đang yếu.

Nếu trước đây team sống được nhờ:

• Họp nhiều
• Handoff nhiều
• Vai trò tách biệt cứng
• Tiến độ chậm nên còn thời gian sửa sai

…thì AI sẽ làm những điểm yếu đó lộ ra rất nhanh.

Còn nếu team coi AI như cách để:

• Tăng quyền tiếp cận thông tin
• Tăng tốc độ học
• Tăng tốc độ thử nghiệm
• Nhưng đồng thời siết chặt ownership, decision log và quality gate

…thì AI sẽ không làm product process biến mất. Nó chỉ buộc product process tiến hóa.

Lời kết

Mình không bi quan về chuyện ai cũng có thể tham gia sâu hơn vào việc làm sản phẩm. Thực ra mình thấy đó là tín hiệu rất đáng mừng.

Điều mình nghĩ các team cần cẩn thận là:

AI đang dân chủ hóa khả năng tạo ra giải pháp, nhưng nó không dân chủ hóa được trách nhiệm cho chất lượng cuối cùng.

Vì thế, câu hỏi quan trọng nhất bây giờ không còn là:

“AI có thể giúp team mình làm nhanh hơn không?”

Mà là:

“Khi mọi người đều có thể làm nhanh hơn, team mình sẽ ra quyết định thế nào để không trượt khỏi thứ thực sự cần xây?”

Có lẽ đó mới là bài toán product lớn nhất của giai đoạn này.

Nếu team mình trả lời được câu hỏi đó đủ sớm, AI sẽ là đòn bẩy.

Nếu không, nó sẽ chỉ làm mình đi nhanh hơn về phía những quyết định chưa đủ chín.