Vào tháng Tư, tôi đã viết về điều khiến Prova trở nên thực sự: động cơ sprint, hệ thống thanh toán, đánh giá, những công việc vận hành tẻ nhạt tách biệt một bản demo với một sản phẩm.
Bài viết đó là đúng khi tôi xuất bản nó. Kiến trúc sprint-first tôi mô tả — các sprint được biên soạn, đánh giá rubric, định tuyến thích ứng, đường dẫn Operator và Builder — thực sự đang hoạt động. Động cơ đã đúng.
Điều tôi chưa biết lúc đó là chương trình học được xếp lớp bên trên nó vẫn còn sai.
Không sai theo cách bạn có thể phát hiện từ một bản demo. Sai theo cách chỉ lộ ra sau khi bạn đã biên soạn từng rubric, truy vết từng đường dẫn người dùng, và hỏi câu hỏi mà không ai buộc tôi phải hỏi cho đến giữa tháng Năm: chính xác điều gì khiến việc này khó bị một chatbot miễn phí sao chép?
Từ giữa tháng Năm đến cuối tháng Sáu, chương trình học đã được xây dựng lại hai lần. Mỗi lần, tôi thay thế một thứ mà trước đó tôi đã tự tin về. Đây là những gì mỗi lần viết lại thực sự hướng tới.
Kiến trúc 3 làn (26/5–1/6)
Đến cuối tháng Năm, sản phẩm có một vấn đề. Nó có 33 sprint, và ba đối tượng rất khác nhau — những operator đang thiết kế lại quy trình làm việc, những builder đang cố gắng xuất xưởng một lát cắt hữu ích đầu tiên, và những leader đang cố gắng chuyển đổi đội nhóm — chia sẻ 7 trong số 9 sprint và gọi hai sprint còn lại là một "track." Đó là một thực đơn, không phải một xương sống.
Bề rộng không phải là hào phòng thủ.
Vậy là tôi xây dựng thứ cảm giác như câu trả lời nghiêm ngặt: một kiến trúc phân lớp với nền tảng chung Layer 0, rồi ba làn đối tượng (Operator, Builder, Leader) với các sprint chuyên biệt, tất cả được lấy nguồn từ 16 template của khóa học và kho ngữ liệu đã xuất bản. 38 đơn vị trên 5 loại đơn vị. Concept, exercise, sprint, project, checkpoint — mỗi loại có ngữ nghĩa hoàn thành khác nhau.
Trên giấy, nó trông giống một chương trình học thực sự.
Cái hỏng không phải là bất kỳ sprint riêng lẻ nào. Nó là giả định cấu trúc bên dưới toàn bộ thứ đó: rằng nhiều làn hơn và nhiều sprint hơn khiến sản phẩm dễ phòng thủ hơn.
Không phải.
Framework 7 Powers của Hamilton Helmer đặt tên cho điều này một cách rõ ràng. Sức mạnh đến từ các rào cản — những lợi thế cấu trúc mà đối thủ cạnh tranh không thể sao chép chỉ bằng cách quyết định. Thêm sprint vào một đường dẫn không phải là một rào cản. Nó là diện tích bề mặt vận hành. Một chatbot tổng quát khớp với bề rộng ngay lập tức với không ma sát.
Mô hình 3 làn đã thêm phạm vi bao phủ. Nó không thêm chiều sâu. Tôi đã xây dựng thứ sai, và tôi đã không nhìn thấy nó cho đến khi kiến trúc được triển khai và từng sprint được viết xong.
Tôi đã biên soạn 24 sprint mới cho mô hình 3 làn, được lấy nguồn từ các template của khóa học và kho ngữ liệu đã xuất bản. Kiến trúc trông nghiêm ngặt trên giấy. Tôi đã tự hào về nó.
Hệ thống làn đã bị ngừng hoạt động cùng tuần nó được xuất xưởng.
Một quy tắc (2/6–22/6)
Lần viết lại thứ hai không bắt đầu bằng các sprint. Nó bắt đầu bằng một câu hỏi chiến lược.
Tôi ngồi xuống và hỏi: nếu lợi thế phòng thủ duy nhất của Prova là thứ mà một công cụ AI ngang hàng về mặt cấu trúc không thể áp dụng, thì lợi thế đó sẽ là gì?
Câu trả lời đáp xuống ba lớp tăng cường lẫn nhau:
Chiều sâu dọc (cái nêm). Một marketer xuất xưởng một quy trình làm việc chiến dịch được lập tài liệu bằng brief, với đo lường thực tế và một cổng quyết định, theo tiêu chuẩn cấp ngành quảng cáo. Đó không phải là thứ một chatbot có thể tạo ra từ một prompt.
Giàn giáo (sự kích hoạt). Hầu hết marketer không biết phải hỏi gì. Sản phẩm phải gặp họ ở điểm "Tôi nghĩ AI có thể giúp việc này nhưng tôi không chắc bắt đầu từ đâu" và làm công việc xác định phạm vi, sắp xếp trình tự, và thiết lập tiêu chuẩn.
Tác phẩm đã được xác minh, xuất xưởng theo tiêu chuẩn (bằng chứng). Mỗi sprint kết thúc bằng một bài nộp được đánh giá dựa trên một rubric thực tế. Không phải "trông có ổn không." Không phải "có sạch về mặt ngữ pháp không." Mà là: tác phẩm này có đứng vững trước những gì một operator agency hoặc media buyer thực sự sẽ sử dụng không?
Từ ba lớp đó, kiến trúc đơn giản hóa một cách đáng kể.
Cấu trúc 3 làn được thay thế bằng một vòng lặp ngữ pháp duy nhất: kiểm tra thực tế → brief → kế hoạch → chạy/xây dựng → cổng quyết định → capstone.
Cùng một ngữ pháp cho cả ba đường dẫn. Các tác phẩm khác nhau cho mỗi đường dẫn. Operator chạy một thí điểm quy trình làm việc chiến dịch. Builder xuất xưởng một lát cắt sản phẩm hoạt động được. Leader xây dựng một business case cho stakeholder và một bản thiết kế mô hình vận hành.
Chiều sâu chỉ được thêm vào sau capstone: các phần mở rộng agency, phần mở rộng chiều sâu sản phẩm, phần mở rộng thay đổi tổ chức. Nếu người dùng muốn nhiều hơn, họ kiếm được nó thông qua xương sống trước.
Bề rộng không biến mất. Nó bị giáng cấp thành các mô-đun đường vòng kích hoạt bằng chứng cứ — những sprint ngắn, được gán chỉ xuất hiện khi một reviewer phát hiện một khoảng trống mà xương sống đã biên soạn hiện không thể giải quyết. Kiểm toán hạ tầng dữ liệu. Quyết định stack nhà cung cấp. Chẩn đoán bàn đạp. Chúng vẫn tồn tại. Chỉ là chúng không phải là tuyến đường bạn đi trừ khi sản phẩm có bằng chứng bạn cần chúng.
Commit đơn lẻ chính thức hóa điều này là feat!: replace dual curriculum routing with unified path sequences vào ngày 11 tháng Sáu. Dấu ! biểu thị một thay đổi phá vỡ. primary_path (operator, builder, leader) đã thay thế learning_track làm trục định tuyến duy nhất. Có một feature flag — DISABLE_BRIEF_DRIVEN_RESET_PATH — ngăn cách quá trình chuyển đổi cho đến khi cổng QA được thông qua. Bảy sprint kế thừa đã được nghỉ hưu khỏi trình tự nhưng vẫn có thể xem như lịch sử.
Capstone đã trở thành cấu trúc, không phải một tính năng. Nó là cơ chế chi phí chuyển đổi. Một công cụ ngang hàng có thể tạo ra một gói sprint tươm tất. Nó không thể tạo ra một danh mục các tác phẩm đã được xác minh, xuất xưởng, được đánh giá dựa trên các tiêu chuẩn cấp ngành quảng cáo với một lịch sử reviewer bền vững.
Trước khi biên soạn bất kỳ sprint hoặc đường dẫn mới nào, hãy hỏi: điều này củng cố sức mạnh nào trong 7 Powers, và rào cản của nó là gì? Nếu câu trả lời trung thực là "nó thêm phạm vi bao phủ" mà không có rào cản, thì nó là diện tích bề mặt vận hành mà một chatbot đã bao phủ — đừng xây dựng nó.
— Ngày 5 tháng Sáu, 2026, tài liệu chiến lược chương trình Prova
Quy tắc đó đã giết chết kiến trúc 3 làn. Nó đã giết những sprint được viết tốt nhưng dư thừa về mặt cấu trúc. Nó đã biến capstone từ một tính năng tôi đang trì hoãn thành một yêu cầu cấu trúc. Và đó là câu hỏi lẽ ra tôi phải hỏi từ tháng Ba.
Sự khác biệt giữa tháng Tư và tháng Sáu
Sản phẩm tôi ra mắt vào tháng Tư đúng ở phần động cơ. Sản phẩm tôi chốt lại vào tháng Sáu đúng ở phần xương sống.
Động cơ — các sprint được biên soạn, đánh giá rubric, định tuyến thích ứng, vòng đời sprint tổ hợp — là cần thiết. Một kiến trúc chương trình không có động cơ sprint hoạt động chỉ là một đề cương.
Nhưng một động cơ sprint không có xương sống có thể phòng thủ chỉ là một danh sách tính năng mà các công cụ miễn phí đã đang khớp.
Sự khác biệt giữa hai sản phẩm không phải là nhiều code hơn. Mà là một câu hỏi tốt hơn. "Điều này củng cố Power nào?" đã buộc tôi phải giết những thứ tôi tự hào, và nâng cấp những thứ tôi đã đối xử như tùy chọn.
Tôi không tuyên bố kiến trúc tháng Sáu đã hoàn thành. Sản phẩm hiếm khi hoàn thành. Nhưng nếu bạn đang xây dựng một sản phẩm học tập ngay lúc này, câu hỏi này đáng để hỏi trước khi bạn viết sprint tiếp theo. Bởi vì bề rộng là thứ dễ thêm nhất, và là thứ đầu tiên một AI tổng quát sẽ hàng hóa hóa.
Ghi chú bổ sung: Prova là sản phẩm coaching của tôi dành cho marketer và chuyên gia quảng cáo, với đường dẫn Operator (thiết kế lại quy trình làm việc) và đường dẫn Builder (xuất xưởng lát cắt hữu ích đầu tiên). Nó hoạt động tại prova.chandlernguyen.com. Framework 7 Powers đến từ cuốn sách 7 Powers: The Foundations of Business Strategy của Hamilton Helmer — bài viết này tham chiếu framework nhưng không dạy nó; cuốn sách là nguồn.
Nếu bạn đang xây dựng một sản phẩm có cấu trúc trên một lớp AI chuyển động nhanh, tôi thực sự tò mò: điều gì trong kiến trúc của bạn mà một công cụ miễn phí không thể sao chép chỉ bằng cách thêm prompt?
Đến đây thôi từ tôi.
Chúc sức khỏe, Chandler