G3. Design partner V2 cần là ai?

Ngày viết: 2026-05-28 Series: SYNVIA Learning Evidence OS / Real EdTech Mục đích: bài long-form dùng để quay video, giúp chủ trung tâm, academic manager và đội SYNVIA hiểu rằng design partner cho V2 không phải là khách hàng lớn nhất, dễ tính nhất hay đòi nhiều tính năng nhất; đó là trung tâm có học thuật thật, bài làm thật, feedback thật, người phụ trách thật và đủ kỷ luật để cùng pilot một vòng học tập có bằng chứng

Bài nói hoàn chỉnh

Khi xây một sản phẩm mới, đặc biệt là một sản phẩm B2B giáo dục như SYNVIA V2, có một cám dỗ rất lớn: thấy trung tâm nào quan tâm thì nhận hết.

Trung tâm lớn muốn xem demo, người xây sản phẩm rất dễ hào hứng. Trung tâm có nhiều học viên hỏi giá, đội sản phẩm dễ nghĩ đây là cơ hội. Trung tâm đòi rất nhiều tính năng, đội sales dễ nghĩ họ hiểu thị trường. Trung tâm nói có thể làm case study, ai cũng dễ nghĩ đó là logo tốt. Trung tâm muốn dùng thử ngay, người bán dễ nghĩ họ là early adopter.

Nhưng với V2, chọn sai design partner có thể nguy hiểm hơn không có design partner.

Vì design partner không chỉ dùng thử sản phẩm. Họ ảnh hưởng đến cách đội sản phẩm hiểu vấn đề, ưu tiên roadmap, thiết kế workflow, định nghĩa thành công, thậm chí kể câu chuyện ra thị trường.

Nếu chọn một trung tâm chỉ muốn app rẻ, V2 rất dễ bị kéo thành phần mềm quản lý trung tâm rẻ hơn. Nếu chọn một khách muốn custom vô hạn, V2 dễ thành dự án outsource trá hình. Nếu chọn một trung tâm không có dữ liệu học tập thật, sản phẩm sẽ phải thiết kế trong tưởng tượng. Nếu chọn một nơi không có academic manager hoặc giáo viên lead tham gia, V2 dễ bị kéo về vận hành bề mặt: lớp, tài khoản, thông báo, report, giao diện, export.

Những thứ đó không sai. Nhưng đó không phải lõi của Learning Evidence OS.

V2 cần học từ thực tế học tập: bài học viên nộp, feedback giáo viên trả, bản sửa học viên làm, lỗi lặp lại của cả lớp, phụ huynh hỏi về tiến bộ, giáo viên bị quá tải ở đoạn nào, AI output cần duyệt ra sao, dữ liệu nào không nên gửi ra ngoài, dashboard nào thật sự dẫn đến hành động.

Những thứ này không thể tưởng tượng trong phòng.

Chúng chỉ hiện ra khi sản phẩm chạm vào một trung tâm có quy trình học thật.

Vì vậy, câu hỏi G3 không phải là: “Làm sao tìm nhiều khách dùng thử V2?”

Câu hỏi đúng hơn là: “Ai đủ phù hợp để trở thành đồng tác giả của V2 trong giai đoạn đầu?”

Tôi dùng chữ đồng tác giả có chủ ý.

Design partner không phải khách hàng beta theo nghĩa mở tài khoản rồi bấm thử. Họ cũng không phải người thuê đội sản phẩm làm theo yêu cầu. Họ là đối tác giúp sản phẩm học từ thế giới thật, trong khi bản thân họ nhận lại một pilot có giá trị thật cho trung tâm.

Nếu chọn đúng, design partner đầu tiên có thể giúp SYNVIA V2 đi nhanh hơn sáu tháng.

Nếu chọn sai, họ có thể làm sản phẩm đi lệch sáu tháng.

Vì sao V2 cần design partner nghiêm túc?

SYNVIA V2 không phải một tiện ích nhỏ.

Nếu chỉ làm một tool độc lập, ví dụ một công cụ tạo comment Writing, việc thử nghiệm có thể nhanh hơn rất nhiều. Người dùng paste bài vào, nhận output, đánh giá xem hay hay dở. Nhưng Learning Evidence OS là thứ khác.

Nó không chỉ tạo output. Nó phải đi vào workflow.

Học viên nộp bài ở đâu? Giáo viên nhận bài thế nào? AI draft được tạo lúc nào? Ai duyệt? Học viên đọc feedback ở đâu? Bản sửa có bắt buộc không? Giáo viên review bản sửa toàn bộ hay chỉ phần được giao? Academic manager xem pattern lớp ra sao? Phụ huynh nhận summary nào? Dữ liệu học viên được lưu bao lâu? AI output nào được coi là official? Khi có khiếu nại, ai giải thích?

Đây là các câu hỏi không thể trả lời chỉ bằng suy luận.

Một sản phẩm giáo dục tốt phải va vào lịch học thật, bài làm thật, giáo viên thật, học viên thật, phụ huynh thật và các giới hạn thật của trung tâm. Nếu không, sản phẩm sẽ rất dễ đẹp trên sơ đồ nhưng mệt trong vận hành.

Education Endowment Foundation khi nói về implementation có một ý rất đáng nhớ: điều quan trọng không chỉ là một ý tưởng hay trên nguyên tắc, mà là nó xuất hiện thế nào trong công việc hằng ngày của con người. Với V2, câu này rất đúng. Một workflow feedback có thể hợp lý trong slide, nhưng khi giáo viên phải dùng sau ba buổi dạy tối, khi học viên nộp bài muộn, khi phụ huynh hỏi trong Zalo, khi academic manager không có thời gian review từng bài, lúc đó sản phẩm mới bị thử thật.

Paul Graham có bài “Do Things that Don’t Scale”, nhấn mạnh giai đoạn đầu startup thường phải chủ động tuyển người dùng và chăm họ rất sát. Với V2, tinh thần đó không phải là chạy đi xin thật nhiều người dùng. Tinh thần đúng hơn là: chọn rất ít người dùng phù hợp, làm việc rất sâu với họ, rồi học những thứ không thể học từ khảo sát rộng.

Design partner là cách làm “không scale” nhưng cần thiết.

Không phải vì sản phẩm yếu.

Mà vì sản phẩm đang cần sự thật.

Design partner khác khách hàng dùng thử ở đâu?

Khách hàng dùng thử có thể mở sản phẩm, bấm vài tính năng, nói thích hay không thích, rồi rời đi.

Design partner thì khác.

Họ có một vấn đề rõ. Họ có lớp hoặc nhóm học viên thật. Họ có người phụ trách học thuật tham gia. Họ đồng ý đo một vài chỉ số. Họ chấp nhận rằng pilot có phạm vi hẹp, không phải triển khai toàn bộ hệ thống trong một lần. Họ phản hồi đều. Họ cho phép sản phẩm nhìn vào workflow thật trong giới hạn dữ liệu đã thống nhất. Họ hiểu rằng mục tiêu không chỉ là xem sản phẩm có “đủ tính năng” không, mà là xem một vòng học tập có cải thiện được không.

Nếu nói đơn giản:

Khách dùng thử hỏi: phần mềm có gì?

Design partner hỏi: vòng học này có tốt hơn không?

Đây là khác biệt rất lớn.

Một khách dùng thử có thể chê: “Sao chưa có module CRM đầy đủ?” Design partner tốt sẽ hỏi: “Nếu mục tiêu pilot là Writing feedback, CRM có thật sự cần trong bốn tuần đầu không?”

Một khách dùng thử có thể nói: “Anh muốn custom giao diện giống hệ thống cũ.” Design partner tốt sẽ nói: “Miễn là giáo viên dùng được workflow feedback-revision và học viên nộp bản sửa, giao diện có thể tối ưu sau.”

Một khách dùng thử có thể hỏi: “AI chấm có chuẩn như giám khảo không?” Design partner tốt sẽ hỏi: “AI draft giúp giáo viên duyệt nhanh hơn không, và học viên có sửa tốt hơn không?”

Nói vậy không có nghĩa design partner dễ tính.

Ngược lại, design partner tốt thường rất khó tính ở đúng chỗ. Họ không đòi mọi thứ. Nhưng họ sẽ bắt sản phẩm trả lời những câu hỏi thật: giáo viên có dùng không, học viên có hiểu không, phụ huynh có tin không, dữ liệu có sạch không, workflow có tăng tải không, output AI có đáng duyệt không.

Đó là kiểu khó tính mà V2 cần.

Trung tâm lớn nhất chưa chắc là design partner tốt nhất

Nhiều người sẽ nghĩ: muốn làm design partner thì nên chọn trung tâm lớn.

Trung tâm lớn có nhiều học viên, nhiều lớp, nhiều giáo viên, nhiều dữ liệu, thương hiệu tốt. Nếu làm được case với họ, nghe rất mạnh. Điều này có phần đúng. Nhưng với V2 giai đoạn đầu, trung tâm lớn cũng có nhiều rủi ro.

Trung tâm lớn thường có nhiều tầng quyết định hơn. Người muốn đổi mới chưa chắc là người vận hành. Người vận hành chưa chắc có quyền quyết định. Giáo viên có thể đông nhưng khó thống nhất. Dữ liệu có thể nhiều nhưng nằm rải rác. Một thay đổi nhỏ có thể cần qua nhiều phòng ban. Nếu pilot không được sponsor đủ mạnh, sản phẩm bị mắc trong quy trình nội bộ của khách trước khi kịp học về học tập.

Trung tâm nhỏ hơn nhưng có academic owner rõ, lớp học thật, giáo viên sẵn sàng hợp tác, bài làm đều và chủ trung tâm muốn đo chất lượng có thể tốt hơn rất nhiều.

Design partner tốt không nhất thiết lớn nhất.

Họ phải đủ thật.

Đủ thật nghĩa là có hoạt động học tập đang diễn ra đều. Có bài nộp. Có feedback. Có học viên cần revision. Có phụ huynh hoặc học viên cần hiểu tiến bộ. Có giáo viên đang chịu workload. Có academic manager hoặc giáo viên lead biết vấn đề. Có mong muốn cải thiện chất lượng, không chỉ mong mua một phần mềm rẻ.

Nếu trung tâm lớn mà không có người phụ trách học thuật tham gia, không cho pilot vào lớp thật, không muốn đo, không chấp nhận giới hạn phạm vi, thì không phải design partner tốt.

Nếu trung tâm vừa phải nhưng có lớp Writing đều, giáo viên feedback thật, sẵn sàng pilot bốn tuần, cho học viên nộp revision, đo teacher edit rate, review hàng tuần, và nếu ổn sẽ mở rộng, thì đó là đối tác đáng ưu tiên.

V2 không cần logo đẹp đầu tiên.

V2 cần sự thật đẹp đầu tiên.

Tiêu chí 1: Có lớp học tạo evidence đều

Design partner cho V2 phải có evidence.

Nếu không có bài làm, không có recording, không có quiz, không có revision, không có teacher observation, không có parent report, thì Learning Evidence OS không có gì để học.

Với wedge đầu tiên như IELTS Writing Feedback & Revision OS, evidence rõ nhất là bài Writing. Nhưng V2 không chỉ giới hạn ở IELTS Writing. Một trung tâm speaking-heavy có thể có audio, transcript và recording. Một trung tâm trẻ em có thể có bài tập nhỏ, ảnh hoạt động, worksheet, teacher observation và parent summary. Một trung tâm online/hybrid có thể có attendance, recording, chat, assignment, quiz và post-class note.

Điểm chung là phải có hoạt động học tập tạo dấu vết.

Nếu trung tâm chỉ có lớp giao tiếp rất tự do, không bài tập, không ghi nhận tiến bộ, không phụ huynh hỏi report, không giáo viên ghi chú, thì có thể vẫn là trung tâm tốt. Nhưng họ chưa phải design partner tốt cho V2 ở giai đoạn đầu.

V2 cần những nơi mà vòng evidence đủ rõ để thiết kế.

Một câu hỏi tuyển design partner rất thực tế là:

Trong 4 tuần tới, trung tâm có thể đưa vào pilot bao nhiêu bài làm/recording/bằng chứng học tập thật?

Nếu câu trả lời mơ hồ, nên dừng.

Không có evidence thật thì pilot chỉ còn là demo.

Tiêu chí 2: Có pain rõ, không chỉ tò mò công nghệ

Design partner không nên là người chỉ thấy AI hay hay.

Tò mò công nghệ tạo cuộc gọi đầu tiên. Pain rõ mới tạo pilot nghiêm túc.

Với IELTS Writing, pain có thể là giáo viên chấm chậm, feedback không đều, học viên không sửa bài, phụ huynh hỏi tiến bộ, academic manager không nhìn được lỗi lặp lại, hoặc AI đang được dùng tự phát không có policy.

Với trung tâm trẻ em, pain có thể là phụ huynh muốn thấy tiến bộ nhưng giáo viên không thể viết report sâu đều đặn. Hoặc giáo viên có nhiều quan sát tốt nhưng chúng nằm trong tin nhắn rời rạc. Hoặc trung tâm muốn chứng minh chất lượng lớp online/hybrid nhưng dữ liệu học tập không nối được.

Với Speaking, pain có thể là giáo viên không đủ thời gian nghe lại audio, học viên không retry, feedback chỉ là nhận xét chung, và không có dữ liệu fluency/pronunciation/coherence theo thời gian.

Pain phải đủ cụ thể để pilot có trọng tâm.

Nếu khách nói “tôi muốn chuyển đổi số”, đó chưa đủ. Nếu khách nói “mỗi tuần có khoảng 120 bài Writing, giáo viên trả trong 4-5 ngày, học viên ít sửa lại, phụ huynh hỏi nhiều về tiến bộ”, đó là pain tốt.

Design partner tốt không chỉ nói “tôi muốn AI”.

Họ nói được: “Tôi muốn biết feedback có giúp học viên sửa tốt hơn không.”

Tiêu chí 3: Có academic owner

V2 cần người phụ trách học thuật.

Không nhất thiết phải là một academic manager chính danh. Có thể là founder kiêm học thuật, head teacher, giáo viên lead, curriculum lead hoặc một người đủ hiểu lớp học và có quyền điều phối giáo viên trong pilot.

Nhưng phải có người.

Nếu chỉ có chủ trung tâm quan tâm phần mềm nhưng giáo viên không tham gia, pilot sẽ yếu. Nếu chỉ có sale hoặc vận hành muốn report đẹp nhưng không có người kiểm tra feedback, sản phẩm sẽ lệch. Nếu giáo viên muốn thử nhưng chủ trung tâm không cho thời gian hoặc không xem kết quả, pilot sẽ rơi vào hứng thú cá nhân.

Academic owner làm bốn việc quan trọng.

Họ giúp chọn lớp pilot đúng. Họ giải thích quy trình cho giáo viên. Họ cùng định nghĩa chỉ số học thuật. Họ phản hồi sản phẩm bằng ngôn ngữ học tập, không chỉ bằng cảm giác giao diện.

Một design partner không có academic owner có thể vẫn là lead tốt cho V1 hoặc cho phần vận hành. Nhưng với V2, đặc biệt với Learning Evidence OS, thiếu vai này là rủi ro lớn.

Câu hỏi cần hỏi rất thẳng:

Ai trong trung tâm sẽ chịu trách nhiệm học thuật cho pilot này?

Người đó có tham gia weekly review không?

Người đó có quyền điều chỉnh quy trình feedback/revision trong lớp pilot không?

Nếu câu trả lời là “để anh/chị hỏi lại giáo viên sau”, chưa đủ.

Tiêu chí 4: Giáo viên phải có tiếng nói

Trong EdTech, sản phẩm rất dễ được mua bởi một người và bị bỏ bởi một nhóm khác.

Chủ trung tâm mua. Giáo viên dùng. Học viên chịu trải nghiệm. Phụ huynh cảm nhận giá trị.

Nếu giáo viên không có tiếng nói trong pilot, sản phẩm dễ bị thiết kế sai. Một workflow nhìn rất hợp lý với founder có thể tăng tải cho giáo viên. Một AI draft nhìn rất thông minh với người bán có thể khiến giáo viên mất thời gian sửa hơn là tự viết. Một dashboard nhìn rất đẹp với chủ trung tâm có thể làm giáo viên cảm giác bị soi lỗi.

Design partner tốt phải cho giáo viên tham gia sớm.

Không phải để giáo viên phủ quyết mọi thứ. Cũng không phải để sản phẩm chạy theo mọi thói quen cũ. Nhưng giáo viên cần nói được: phần nào thật sự mất thời gian, phần nào cần giữ quyền phán đoán, feedback nào học viên hiểu được, revision task nào khả thi, và màn hình nào làm họ chậm.

Một pilot V2 nên có ít nhất 1-2 giáo viên trực tiếp tham gia weekly feedback trong giai đoạn đầu.

Nếu design partner nói “anh cứ làm đi, giáo viên bên tôi sau này dùng”, hãy cẩn thận. Câu đó nghe thuận lợi, nhưng thường là dấu hiệu adoption rủi ro.

Giáo viên không cần quyết định roadmap.

Nhưng họ phải giúp sản phẩm gặp thực tế.

Tiêu chí 5: Có quy trình hiện tại, dù còn rời rạc

Nghe có vẻ lạ, nhưng design partner tốt không nhất thiết là nơi chưa có gì.

Thực ra, nếu một trung tâm chưa có quy trình feedback nào, chưa có rubric, chưa yêu cầu bài nộp đều, chưa có người quản lý học thuật, thì pilot V2 có thể phải giải quyết quá nhiều vấn đề nền cùng lúc. Lúc đó sản phẩm không biết bài học chính là gì: pain feedback, hay việc trung tâm chưa có quy trình cơ bản?

Design partner tốt thường đã có một cách làm hiện tại.

Có thể cách làm đó rời rạc, thủ công, tốn sức, chưa đo được. Nhưng nó tồn tại. Giáo viên đang chấm trong Google Docs. Học viên nộp qua Drive. Feedback gửi qua Zalo. Phụ huynh nhận report bằng file. Academic manager review mẫu bài bằng tay. AI được vài giáo viên dùng thử. Tất cả hơi lộn xộn, nhưng có chất liệu thật.

V2 không cần thay thế khoảng trống hoàn toàn.

V2 cần nâng cấp một vòng đang tồn tại.

Nếu trung tâm đã có feedback nhưng thiếu revision tracking, quá tốt. Nếu đã có parent report nhưng thiếu evidence, quá tốt. Nếu đã có AI draft nhưng thiếu teacher review và audit, quá tốt. Nếu đã có giáo viên giỏi nhưng workload quá nặng, quá tốt.

Một design partner lý tưởng có đủ quy trình để so sánh trước/sau, nhưng chưa đủ hệ thống để giải quyết vấn đề.

Đó là vùng V2 học được nhiều nhất.

Tiêu chí 6: Sẵn sàng đo, kể cả khi số liệu ban đầu không đẹp

Pilot không có đo lường là một buổi dùng thử kéo dài.

Design partner tốt phải sẵn sàng đo một vài chỉ số, kể cả khi kết quả ban đầu không đẹp.

Với IELTS Writing wedge, các chỉ số có thể là time-to-feedback, feedback viewed rate, submitted revision rate, meaningful revision rate, teacher edit rate, teacher time per essay, student usefulness rating. Không cần đo quá nhiều. Nhưng phải đo đủ để biết vòng học có cải thiện không.

Điều quan trọng là văn hóa đo.

Nếu trung tâm sợ số liệu vì nghĩ số liệu dùng để bắt lỗi giáo viên, pilot sẽ căng. Nếu chủ trung tâm chỉ muốn con số đẹp để marketing, pilot dễ bị diễn. Nếu giáo viên tick cho xong để dashboard đẹp, dữ liệu vô nghĩa. Nếu học viên bị ép nộp revision hình thức, revision rate tăng nhưng học tập không tăng.

Design partner tốt hiểu rằng chỉ số là công cụ học, không phải công cụ diễn.

Jisc khi nói về learning analytics nhấn mạnh dữ liệu và can thiệp phải được dùng minh bạch, có validity, vì lợi ích người học và tránh tác động bất lợi. Với trung tâm nhỏ, nguyên tắc đó có thể diễn dịch rất thực tế: đừng dùng dashboard để quy kết vội, đừng dùng nhãn để dán lên học viên, đừng đo chỉ để khoe, và đừng che số liệu xấu nếu nó giúp cải thiện.

Câu hỏi cần hỏi:

Nếu sau 4 tuần revision rate thấp, trung tâm có sẵn sàng xem đó là tín hiệu học tập để cải thiện workflow không?

Hay trung tâm chỉ muốn một case study đẹp?

Nếu chỉ muốn case đẹp, không phải design partner tốt.

Tiêu chí 7: Có kỷ luật phạm vi

Design partner tốt không phải người yêu cầu ít.

Họ là người hiểu vì sao phải giới hạn đúng.

V2 rất dễ bị kéo rộng. Hôm nay bắt đầu với Writing feedback, ngày mai muốn CRM, ngày kia muốn app phụ huynh, hôm sau muốn nhập học phí, sau đó muốn chỉnh giao diện, rồi muốn khóa video, rồi muốn Meet AI, rồi muốn báo cáo tổng hợp. Mỗi yêu cầu đều có lý. Nhưng nếu đưa hết vào pilot đầu tiên, không còn biết vòng nào tạo giá trị.

Design partner tốt có thể nói: “Trong bốn tuần đầu, chỉ pilot lớp Writing này. Những thứ khác ghi vào backlog.”

Đó là một phẩm chất quý.

Vì V2 đang cần học sâu một vòng, không cần chứng minh có thể làm mọi thứ.

Kỷ luật phạm vi cũng bảo vệ khách hàng. Nếu pilot quá rộng, giáo viên bị ngợp, học viên không hiểu, dữ liệu loạn, chủ trung tâm thất vọng. Một pilot hẹp nhưng chạy được sẽ tạo niềm tin tốt hơn nhiều so với một hệ thống rộng nhưng lỏng.

Trong proposal design partner, cần ghi rõ:

Pilot này làm gì.

Pilot này không làm gì.

Tính năng nào nằm ngoài scope.

Điều kiện nào mới mở rộng.

Nếu khách không chấp nhận phạm vi, có thể họ là khách custom, không phải design partner.

Tiêu chí 8: Có dữ liệu và quyền dùng dữ liệu rõ ràng

V2 xử lý dữ liệu học tập.

Điều này khiến design partner không thể chỉ là người “cho dùng thử”. Hai bên phải thống nhất rất rõ dữ liệu nào được dùng, ai được xem, dữ liệu có được đưa vào AI không, output nào được gửi cho học viên/phụ huynh, dữ liệu nào dùng trong case study, dữ liệu nào phải ẩn danh, và khi kết thúc pilot thì xử lý ra sao.

Design partner tốt không né câu hỏi dữ liệu.

Họ không nhất thiết phải có policy hoàn hảo. Nhưng họ nghiêm túc. Họ hiểu bài làm, feedback, audio, video, thông tin phụ huynh và dữ liệu trẻ em không phải thứ muốn copy đâu cũng được. Họ sẵn sàng cùng đặt rule tối thiểu.

Nếu khách nói “cứ lấy dữ liệu thoải mái, không sao đâu”, nghe có vẻ dễ, nhưng thật ra đáng lo. Một đối tác không cẩn thận với dữ liệu học viên hôm nay có thể tạo rủi ro lớn ngày mai.

Design partner tốt sẽ hỏi ngược:

Dữ liệu học viên lưu ở đâu?

Ai trong team SYNVIA được xem?

AI provider nào xử lý?

Có ẩn tên học viên không?

Case study sau này có dùng ví dụ thật không?

Phụ huynh/học viên có cần thông báo không?

Những câu hỏi này không làm pilot chậm.

Chúng làm pilot đáng tin hơn.

Tiêu chí 9: Có đường mở rộng hoặc trả tiền nếu pilot chứng minh giá trị

Design partner không nhất thiết phải trả nhiều tiền ngay từ đầu.

Giai đoạn đầu, có thể có những pilot ưu đãi, thậm chí một vài design partner đặc biệt được hỗ trợ sâu để đổi lại feedback và case chất lượng. Nhưng dù mô hình thương mại ban đầu thế nào, vẫn cần một đường mở rộng rõ.

Nếu pilot thành công, chuyện gì xảy ra?

Mở thêm lớp Writing? Thêm Speaking? Thêm parent progress? Chuyển sang hợp đồng tháng? Tính phí theo lớp, theo học viên, theo bài chấm, hay theo package? Ai quyết định? Khi nào review? Tiêu chí nào khiến trung tâm nói “đáng tiếp tục”?

Nếu không có câu trả lời, design partner có thể biến thành người dùng thử mãi mãi.

Đây là bẫy phổ biến. Một khách rất thích sản phẩm, phản hồi rất nhiều, dùng khá nhiệt tình, nhưng không có khả năng hoặc ý định trả tiền. Họ giúp product học một phần, nhưng nếu có quá nhiều khách như vậy, startup sẽ bị mắc trong service không tạo business.

Design partner tốt không cần cam kết mua ngay bằng mọi giá.

Nhưng họ phải có willingness-to-continue nếu pilot tạo giá trị.

Một câu hỏi thẳng nhưng lịch sự:

Nếu pilot chứng minh được giảm thời gian feedback và tăng revision có ý nghĩa, trung tâm có sẵn sàng mở rộng sang hợp đồng trả phí không?

Quyết định đó do ai duyệt?

Nếu câu trả lời luôn né, nên đưa lead này về nurture hoặc research, không nên dành slot design partner quý.

Tiêu chí 10: Có khả năng kể câu chuyện sau pilot

Case study không phải mục tiêu duy nhất, nhưng rất quan trọng.

SYNVIA V2 cần thị trường tin rằng Learning Evidence OS không chỉ là ý tưởng. Một case tốt có thể cho thấy: trung tâm chọn một lớp pilot, đo feedback-revision, giáo viên duyệt AI draft, học viên sửa bài nhiều hơn, phụ huynh hiểu progress rõ hơn, academic manager phát hiện pattern lỗi, và sau đó mở rộng.

Nhưng không phải design partner nào cũng sẵn sàng public.

Có trung tâm muốn giữ kín quy trình nội bộ. Có nơi không muốn tên xuất hiện. Có nơi đồng ý ẩn danh. Có nơi có thể cho quote nhưng không cho số liệu. Có nơi cho số liệu nhưng phải duyệt kỹ.

Tất cả đều có thể chấp nhận nếu nói rõ trước.

Điều không nên là giả định rằng sau pilot khách sẽ tự nhiên cho case. Nên hỏi từ đầu:

Nếu pilot có kết quả tốt, trung tâm có sẵn sàng làm case study không?

Có thể dùng tên trung tâm không, hay chỉ dùng ẩn danh?

Có thể dùng số liệu tổng hợp không?

Có thể dùng ví dụ bài học viên đã ẩn danh không?

Ai duyệt nội dung public?

Design partner tốt hiểu rằng câu chuyện sau pilot cũng có lợi cho họ: họ được xuất hiện như trung tâm nghiêm túc về học thuật, biết dùng AI có trách nhiệm, biết đo feedback và tiến bộ.

Nhưng mọi thứ phải minh bạch.

Không dùng case như cái bẫy.

Những kiểu khách không nên chọn làm design partner V2

Có những khách hàng vẫn có thể mua V1, mua dịch vụ khác, hoặc trở thành lead sau này, nhưng không nên là design partner V2 ở giai đoạn đầu.

Kiểu thứ nhất là khách chỉ muốn app rẻ.

Họ hỏi chủ yếu về giá, giao diện, có app hay không, có web riêng hay không, có thay được màu không. Khi nói về feedback, revision, parent evidence, họ không quan tâm nhiều. Với nhóm này, V2 sẽ bị kéo thành commodity software.

Kiểu thứ hai là khách custom vô hạn.

Họ có một danh sách rất dài các yêu cầu riêng, muốn sản phẩm giống quy trình hiện tại từng chi tiết, không chấp nhận giới hạn pilot, và xem design partner như cơ hội thuê đội dev rẻ. Nếu nhận, roadmap sẽ vỡ.

Kiểu thứ ba là khách không có người phụ trách.

Founder thích ý tưởng, nhưng không có academic manager, không có giáo viên lead, không có ai tham gia weekly review. Pilot kiểu này thường bắt đầu rất vui và kết thúc bằng im lặng.

Kiểu thứ tư là khách không có dữ liệu thật.

Họ muốn làm V2 nhưng chưa có lớp phù hợp, chưa có bài nộp đều, chưa có feedback, chưa có phụ huynh cần report. Có thể nurture, nhưng chưa nên pilot.

Kiểu thứ năm là khách chỉ muốn marketing case.

Họ muốn nói đang dùng AI, đang chuyển đổi số, đang có hệ thống mới. Nhưng khi hỏi về chỉ số học tập, revision, teacher workflow, họ không muốn đo. Case kiểu này đẹp bên ngoài nhưng không giúp sản phẩm học.

Kiểu thứ sáu là khách có văn hóa đổ lỗi.

Nếu dữ liệu được dùng để bắt lỗi giáo viên hoặc dán nhãn học viên, V2 sẽ bị đặt sai văn hóa từ đầu. Learning Evidence OS cần dữ liệu để hỗ trợ học tập, không phải để tạo áp lực mù.

Kiểu thứ bảy là khách không tôn trọng dữ liệu học viên.

Nếu họ quá dễ dãi với privacy, gửi raw data lung tung, hoặc muốn đưa mọi thứ vào AI mà không cần rule, đó là rủi ro nghiêm túc cho V2.

Từ chối những khách này không có nghĩa là kiêu.

Nó là bảo vệ sản phẩm.

Free value: Design partner qualification scorecard

Dưới đây là scorecard có thể dùng sau buổi diagnostic. Mục tiêu không phải chấm điểm đạo đức hay đánh giá trung tâm tốt/xấu. Đây chỉ là bộ lọc xem một lead có phù hợp để trở thành design partner V2 trong giai đoạn đầu hay không.

Chấm mỗi tiêu chí từ 0 đến 3:

0 = chưa có / không rõ / không phù hợp

1 = có một phần nhưng yếu hoặc rời rạc

2 = đủ để pilot nếu hỗ trợ thêm

3 = rất phù hợp, có thể bắt đầu nhanh

Scorecard tổng

Tổng điểm tối đa là 36.

Gợi ý đọc kết quả:

Điều kiện cửa ngõ

Ngoài điểm tổng, có vài điều kiện nếu không đạt thì nên dừng, dù điểm các phần khác cao:

Scorecard này nên được dùng sau G2 Diagnostic. Diagnostic giúp hiểu hiện trạng. Scorecard giúp quyết định có nên đầu tư thời gian sâu không.

Ví dụ dùng scorecard

Hãy tưởng tượng ba lead khác nhau.

Lead A là một trung tâm IELTS có 250 học viên, mỗi tuần khoảng 80 bài Writing, giáo viên chấm qua Google Docs, học viên ít nộp revision, academic manager rất quan tâm quality control, và chủ trung tâm muốn tìm cách dùng AI nhưng vẫn giữ teacher review. Họ sẵn sàng chọn một lớp pilot bốn tuần, có hai giáo viên tham gia, đo time-to-feedback và revision rate. Họ chưa chắc muốn public tên, nhưng có thể cho case ẩn danh.

Lead A rất đáng chọn.

Không phải vì họ lớn nhất. Vì họ có wedge fit, evidence volume, pain rõ, academic owner và kỷ luật pilot.

Lead B là một chuỗi trung tâm lớn hơn nhiều, có vài nghìn học viên. Founder thích ý tưởng V2, nhưng team học thuật chưa vào cuộc. Họ muốn xem full platform, hỏi rất nhiều về CRM, mobile app, thanh toán, phân quyền, kế toán, landing page, notification. Khi hỏi về Writing feedback hoặc parent evidence, họ nói “cái đó để sau”. Họ có logo đẹp, nhưng không có lớp pilot cụ thể.

Lead B có thể đáng nurture hoặc bán V1 nếu fit, nhưng chưa nên là design partner V2 đầu tiên.

Lead C là một trung tâm nhỏ, khoảng 80 học viên, nhưng founder là giáo viên IELTS chính. Mỗi tuần có 30 bài Writing, feedback rất kỹ nhưng mất thời gian. Học viên thường không sửa bài. Founder muốn đo revision và thử AI draft với teacher review. Tuy nhiên, họ không có academic manager riêng và volume hơi nhỏ.

Lead C vẫn có thể là design partner tốt nếu founder thật sự tham gia và có kỷ luật. Điểm yếu là volume và capacity, nhưng điểm mạnh là insight học thuật sâu. Với họ, pilot nên rất hẹp, có thể chỉ một lớp, và kỳ vọng case nên khiêm tốn.

Ba ví dụ này cho thấy scorecard không phải máy chấm tự động.

Nó giúp việc lựa chọn bớt cảm tính hơn.

Design partner nhận lại gì?

Nếu mời một trung tâm làm design partner, không thể chỉ nói “anh chị giúp bên em test sản phẩm”.

Cách nói đó làm đối tác cảm giác họ đang làm việc cho bên bán.

Một design partner tốt phải nhận giá trị rõ.

Họ nhận một diagnostic sâu về vòng học tập. Họ nhận một pilot có phạm vi rõ để giải quyết một pain cụ thể. Họ được ảnh hưởng roadmap ở những phần thật sự liên quan đến workflow của họ. Họ được hỗ trợ sát hơn khách bình thường. Họ nhận báo cáo sau pilot với số liệu và khuyến nghị. Nếu case study phù hợp, họ có thể xuất hiện như một trung tâm đi đầu về học thuật có bằng chứng, dùng AI có trách nhiệm và quản trị tiến bộ tốt hơn.

Nhưng cần nói rõ: design partner không nhận lời hứa rằng mọi yêu cầu của họ sẽ được xây.

Đây là ranh giới quan trọng.

Họ có quyền ảnh hưởng roadmap, không có quyền sở hữu roadmap.

Họ có quyền phản hồi sâu, không có quyền biến sản phẩm thành hệ thống riêng của họ.

Họ có quyền kỳ vọng pilot tạo giá trị, không có quyền đòi V2 giải quyết mọi bài toán của trung tâm trong một vòng đầu.

Nếu hai bên nói rõ như vậy, quan hệ sẽ khỏe.

SYNVIA cần cam kết gì với design partner?

Quan hệ design partner không thể một chiều.

Nếu yêu cầu đối tác đưa lớp thật, giáo viên thật, dữ liệu thật và thời gian thật vào pilot, SYNVIA cũng phải cam kết nghiêm túc.

Cam kết đầu tiên là phạm vi rõ. Đối tác phải biết pilot làm gì, không làm gì, kéo dài bao lâu, ai phụ trách, chỉ số nào được đo và sau pilot sẽ review thế nào.

Cam kết thứ hai là hỗ trợ nhanh. Giai đoạn đầu sẽ có lỗi, thiếu màn hình, workflow chưa mượt, AI draft chưa ổn. Nếu design partner phải chờ quá lâu, niềm tin sẽ mất. Pilot không cần hoàn hảo, nhưng phản hồi phải được xử lý có trách nhiệm.

Cam kết thứ ba là tôn trọng dữ liệu. Không dùng dữ liệu học viên ngoài phạm vi đã thống nhất. Không public case khi chưa duyệt. Không dùng output chưa kiểm tra để hứa quá tay.

Cam kết thứ tư là trung thực về trạng thái sản phẩm. Không nói V2 đã hoàn chỉnh nếu đang pilot. Nhưng cũng không nói như thể sản phẩm chưa có gì. Cách nói đúng là: sản phẩm có hướng rõ và một wedge đang được phát triển cùng các trung tâm phù hợp.

Cam kết thứ năm là học có kỷ luật. Mỗi tuần phải có review: cái gì dùng được, cái gì làm giáo viên chậm, học viên có sửa không, AI draft sai ở đâu, metric có vấn đề gì, scope có cần chỉnh không.

Nếu không có các cam kết này, design partner chỉ là nhãn gọi đẹp cho một khách beta.

Pilot agreement nên có gì?

Một thỏa thuận design partner không cần dài như hợp đồng enterprise. Nhưng nên có vài phần rõ.

Phần “out of scope” đặc biệt quan trọng.

Nhiều quan hệ pilot hỏng không phải vì hai bên thiếu thiện chí. Chúng hỏng vì phạm vi bị trôi. Một bên nghĩ đang pilot vòng feedback. Bên kia nghĩ đang làm hệ thống toàn trung tâm. Một bên nghĩ AI draft cần teacher review. Bên kia nghĩ AI sẽ chấm tự động. Một bên nghĩ case study là ẩn danh. Bên kia muốn dùng logo.

Viết rõ từ đầu giúp giữ quan hệ tốt.

Nên mời design partner như thế nào?

Cách mời không nên tạo cảm giác “bên em đang cần khách thử nghiệm vì chưa có gì”.

Cũng không nên nói như thể đây là một sản phẩm hoàn chỉnh đã được chứng minh ở mọi bối cảnh.

Giọng phù hợp là minh bạch và tự tin:

Bên em đang chọn một số trung tâm phù hợp để làm design partner cho SYNVIA V2 - Learning Evidence OS.

Vòng đầu tiên không phải triển khai toàn bộ hệ thống, mà là một pilot hẹp quanh feedback, revision và bằng chứng tiến bộ.

Điều kiện phù hợp là trung tâm có lớp/bài làm thật, có giáo viên hoặc academic lead tham gia, sẵn sàng đo vài chỉ số và review hàng tuần.

Đổi lại, trung tâm sẽ được diagnostic sâu, pilot sát workflow thật, ảnh hưởng roadmap và có báo cáo sau pilot.

Nếu pilot chứng minh giá trị, hai bên mới bàn mở rộng.

Cách nói này có ba điểm tốt.

Thứ nhất, nó tạo chọn lọc. Không phải ai cũng phù hợp.

Thứ hai, nó không hạ thấp sản phẩm. Design partner không phải dùng thử bừa; họ tham gia một pilot có triết lý và phạm vi.

Thứ ba, nó đặt kỳ vọng đúng. V2 là sản phẩm đang được phát triển cùng thị trường thật, không phải một lời hứa mơ hồ.

Design partner không nên là nơi để làm tất cả theo yêu cầu

Một trong những ranh giới khó nhất là custom.

Design partner chắc chắn sẽ yêu cầu những thứ chưa có. Đó là lý do họ hữu ích. Nhưng không phải yêu cầu nào cũng nên làm.

Cần phân biệt ba loại yêu cầu.

Loại thứ nhất là yêu cầu làm rõ lõi sản phẩm. Ví dụ, giáo viên cần xem bài trước của học viên khi duyệt feedback. Học viên cần thấy revision task ngay dưới comment. Academic manager cần lọc lớp theo submitted revision rate. Đây là yêu cầu đáng ưu tiên vì nó phục vụ Learning Evidence loop.

Loại thứ hai là yêu cầu hỗ trợ pilot nhưng chưa chắc là core. Ví dụ, import danh sách học viên từ file, export report, đổi một số wording, tạo template thông báo. Những thứ này có thể làm nếu nhẹ, hoặc xử lý thủ công tạm thời.

Loại thứ ba là yêu cầu kéo sản phẩm đi lệch. Ví dụ, xây module học phí phức tạp, clone toàn bộ CRM hiện tại, làm app riêng theo UI khách, tích hợp một công cụ hiếm chỉ khách đó dùng, hoặc thay đổi data model vì thói quen nội bộ của một trung tâm. Những yêu cầu này nên đưa vào backlog hoặc từ chối trong pilot V2.

Nếu không có ranh giới này, design partner sẽ biến thành custom client.

Mà custom client đầu tiên thường rất nguy hiểm: họ trả cho đội sản phẩm bằng sự bận rộn, nhưng lấy mất sự tập trung.

Khi nào nên dừng một design partner?

Không phải pilot nào bắt đầu cũng nên đi đến cuối.

Có những dấu hiệu nên dừng hoặc thu hẹp.

Nếu sau hai tuần, trung tâm không đưa được lớp thật vào pilot, nên dừng. Nếu giáo viên không tham gia review dù đã thống nhất, nên thu hẹp. Nếu khách liên tục kéo scope sang tính năng ngoài wedge, nên reset kỳ vọng. Nếu dữ liệu học viên được gửi không có kiểm soát, phải dừng để xử lý governance. Nếu số liệu bị làm đẹp thay vì dùng để học, pilot mất ý nghĩa. Nếu người quyết định thương mại biến mất, cần xem lại đường mở rộng.

Dừng không phải thất bại.

Dừng sớm có thể là quyết định tốt.

Một design partner không còn phù hợp có thể chuyển thành lead thường, khách V1, hoặc quan hệ nurture. Không cần đốt cầu. Nhưng cũng không nên để một pilot sai kéo cả team đi sai.

Ở giai đoạn đầu, thời gian của đội sản phẩm là tài sản hiếm. Một pilot sai không chỉ tốn lịch. Nó tạo dữ liệu sai, insight sai, roadmap sai và câu chuyện sai.

Từ design partner đến case study

Một case study tốt không nên chỉ nói “trung tâm A dùng SYNVIA V2”.

Nó nên kể một vòng học tập.

Trước pilot, vấn đề là gì? Feedback chậm? Học viên không sửa? Phụ huynh không thấy tiến bộ? AI dùng tự phát? Giáo viên quá tải? Academic manager không thấy pattern?

Trong pilot, hai bên làm gì? Lớp nào, bao nhiêu bài, workflow nào, giáo viên duyệt ra sao, học viên revision thế nào, chỉ số nào được đo?

Sau pilot, điều gì thay đổi? Time-to-feedback giảm hay không? Revision rate tăng hay không? Giáo viên thấy AI draft hữu ích ở phần nào? Học viên nói feedback dễ sửa hơn không? Parent summary có rõ hơn không? Academic manager có phát hiện lỗi lặp lại không?

Điều gì chưa tốt? Đây là phần nhiều case study hay bỏ qua, nhưng nếu viết khéo, nó làm câu chuyện đáng tin hơn. Ví dụ: “Ở tuần đầu, AI draft quá dài nên giáo viên mất thời gian rút gọn. Sang tuần hai, workflow chuyển sang 1-2 revision task chính, teacher edit time giảm.”

Một case như vậy có sức thuyết phục cao hơn nhiều so với ảnh chụp dashboard đẹp.

Nó cho thị trường thấy SYNVIA không chỉ bán công nghệ.

SYNVIA đang học cách cải thiện một vòng học tập thật.

Kết luận: design partner là đồng tác giả, không phải khách beta

SYNVIA V2 cần design partner.

Nhưng không cần nhiều ngay.

Cần đúng.

Một design partner tốt cho V2 là trung tâm có học thuật nghiêm túc, có bài làm hoặc evidence thật, có pain rõ, có academic owner, có giáo viên tham gia, có quy trình hiện tại đủ để so sánh, sẵn sàng đo, tôn trọng dữ liệu, chấp nhận scope hẹp và có đường mở rộng nếu pilot chứng minh giá trị.

Họ không nhất thiết là trung tâm lớn nhất.

Họ không nhất thiết có logo nổi nhất.

Họ không nhất thiết trả nhiều tiền nhất ngay từ đầu.

Nhưng họ phải giúp sản phẩm chạm vào sự thật.

Nếu G1 là wedge đầu tiên và G2 là diagnostic để nhìn thấy vòng học, thì G3 là bộ lọc để chọn ai xứng đáng bước vào vòng pilot sâu.

Chọn đúng design partner, SYNVIA V2 sẽ có insight thật, case thật, roadmap thật và ngôn ngữ bán hàng thật.

Chọn sai, V2 sẽ bị kéo vào app rẻ, custom vô hạn, demo đẹp hoặc case rỗng.

Trong giai đoạn đầu của một sản phẩm học thuật, một đối tác đúng có giá trị hơn mười người dùng thử sai.

Design partner không phải người được cấp quyền vào bản beta.

Design partner là người cùng viết những dòng đầu tiên của sản phẩm.

Nguồn tham khảo và gợi ý đọc thêm

• Paul Graham, Do Things that Don't Scale: https://www.paulgraham.com/ds.html
• Education Endowment Foundation, Putting Evidence to Work: A School's Guide to Implementation: https://educationendowmentfoundation.org.uk/public/files/Publications/Implementation/EEF-Implementation-Guidance-Report.pdf
• Jisc, Code of practice for learning analytics: https://www.jisc.ac.uk/guides/code-of-practice-for-learning-analytics
• Steve Blank, Customer Development is Not a Focus Group: https://steveblank.com/2009/11/30/customer-development-is-not-a-focus-group/
• Tài liệu nội bộ liên quan: v2/G1-ielts-writing-feedback-revision-os-wedge-v2-dau-tien-nen-trong-nhu-the-nao-2026-05-28.md, v2/G2-learning-evidence-diagnostic-hoi-gi-de-biet-trung-tam-co-dang-hoc-that-khong-2026-05-28.md, reports/bao_cao_chien_luoc_tong_the_synvia_reset_2026-05-27.md.