Một hệ vận hành end-to-end cho team FLYER: từ tìm vấn đề tới đo lường kết quả, với AI nhúng vào cả sản phẩm lẫn cách team làm việc — thiết kế cho chiến lược Teado.ai dẫn dắt, kéo học sinh vào FLYER Test & Study.
Đây là thứ phân biệt "AI-first" với "có dùng AI", và là điều roadmap hiện tại đang thiếu.
Mỗi sáng kiến bắt đầu bằng giả thuyết kiểm chứng được: "Chúng tôi tin rằng [X] cho [user Y] sẽ tạo [kết quả Z]." Không có cột WHY thì không vào sprint.
NSM công ty là Weekly Active Learning Outcomes — số học sinh đạt learning event thành công mỗi tuần. Study time đo engagement, không đo giá trị — đó là cái bẫy.
Câu hỏi đầu tiên khi thiết kế feature: "AI làm phần này được không?" — chứ không phải "có nên thêm AI vào đây không?".
Một vòng khép kín: Ideas → Build → Product → Measure → Data → Learn → rồi quay lại Ideas. Learn nuôi lại Ideas của chu kỳ kế tiếp — đây là khâu hay bị bỏ nhất và là lý do roadmap phình ra.
Áp riêng cho bối cảnh hiện tại: Teado.ai làm mũi nhọn tới giáo viên, kéo học sinh vào FLYER Test & Study.
Không build gì cho tới khi có bằng chứng vấn đề là thật và đáng giải.
Insight quan trọng nhất với Teado là điểm đau của giáo viên khi giao & chấm bài — vì đó là đòn bẩy kéo học sinh.
Deepgram transcribe phỏng vấn → Claude cluster pain points theo theme, quét ticket tìm pattern. Đầu ra là danh sách validated problems xếp hạng theo tần suất × mức độ đau — không phải danh sách tính năng.
Biến problem thành một canh bạc có kỷ luật.
Mỗi sáng kiến cần một one-page hypothesis PRD thay cho spec dài, gồm 6 phần:
Claude draft PRD từ ghi chú Discover, sinh user stories & edge cases, và phản biện chính giả thuyết ("lý do nào feature này thất bại?"). Chốt chặn chống feature factory: không gắn được vào NSM thì không vào sprint.
Ship nhanh, nhưng feature AI phải có "đơn vị kiểm thử" riêng.
Khác biệt lớn nhất với phần mềm thường: feature AI cần eval framework, không chỉ unit test vì output không tất định.
Claude Code / AI pair-programming tăng tốc eng, sinh test, viết migration. Team nhỏ nên đặt mục tiêu mỗi engineer "lái" AI thay vì gõ tay boilerplate.
Để dữ liệu phán quyết, không phải ý kiến.
Ưu tiên: (1) SQL queries chuẩn hoá + dashboard nhẹ cho từng NSM, (2) export tự động, (3) dài hạn ClickHouse/BigQuery cho learning analytics. Đừng để hạ tầng chặn đo lường cơ bản.
Đóng vòng lặp — khâu hay bị bỏ nhất.
Trái tim của "AI-first". Vì output AI không tất định, mỗi feature AI phải có bộ đo chất lượng riêng — chạy tự động mỗi khi đổi prompt hay model, trước khi ship.
Trước khi viết prompt, chốt feature này "đúng" nghĩa là gì, đo bằng tiêu chí rời rạc:
50–200 ví dụ thật, mỗi ví dụ gồm input + output mong muốn được con người (giáo viên) đồng thuận:
Ba tầng chấm, dùng tầng nào tùy tiêu chí:
Eval không phải làm một lần:
Cổng chất lượng (quality gate) — ngưỡng ví dụ
| Tiêu chí | Ngưỡng ship | Nếu không đạt |
|---|---|---|
| Safety (trẻ em) | 100% — không khoan nhượng | Chặn ship tuyệt đối |
| Correctness | ≥ 90% khớp golden | Sửa prompt, chạy lại |
| Format hợp lệ | ≥ 99% | Chặn deploy (CI) |
| Tone / cấp học | ≥ 85% | Ship được, ghi nợ cải thiện |
| Chi phí / lượt | Trong ngân sách product | Tối ưu ở Phase calibration |
Với Bingo & Test, accuracy của learning outcome đứng trên cả tốc độ ra mắt lẫn chi phí. Một feature AI chưa có golden set thì coi như chưa sẵn sàng ship — bất kể demo đẹp đến đâu. Ai sở hữu eval: Core squad.
NSM công ty là WALO; mỗi product có NSM riêng dẫn về cùng một hướng giá trị.
| Product | North Star Metric đề xuất |
|---|---|
| Teado.ai | Giáo viên hoạt động hàng tuần (WAT) có giao bài qua AI |
| FLYER Test & Study | Học sinh hoàn thành ≥1 bài học/test có outcome mỗi tuần |
| Cầu nối cross-sell | % giáo viên Teado kéo được ≥1 lớp vào Test & Study |
| Công ty (WALO) | Số học sinh đạt learning event thành công mỗi tuần |
Với 5–15 người: 2–3 squad mỏng theo chức năng, không chia theo product.
Giữ chất lượng & accuracy lõi: eval, AI tutor, chấm bài. Đây là nơi ràng buộc "accuracy số 1" được bảo vệ.
Sở hữu vòng cross-sell Teado → Test & Study, chạy A/B. Cần một Growth PM — vai trò roadmap đang thiếu.
Hạ tầng dữ liệu, prompt infra, eval dùng chung. Có thể ghép với Core khi team còn nhỏ.
Quy trình này tồn tại để chống một thứ duy nhất: feature factory không có kỷ luật giả thuyết — gốc rễ của roadmap phình ra trên năm product. Build ít hơn, học nhiều hơn.