How to run a pilot with a university

A university pilot is a time-boxed deployment of your product with real users inside a real institution — students in actual courses, advisors using your tool with their actual caseload, an IT team running it against their actual systems. Done well, it is the fastest way for an early-stage EdTech company to prove its product works in the environment it sells into. Done badly, it burns months and produces a case study nobody believes.

This playbook shares the filter, not the verdict: the evaluation methodology, the pilot-design framework, and the readiness criteria ASU ScaleU uses, drawn from reviewing 4,000+ EdTech companies and running 30+ paid institutional pilots. Institutions can adopt or adapt it; founders can use it to self-assess before approaching a school.

The problem this solves

Universities evaluate the same EdTech companies independently. Each institution runs its own discovery, its own diligence, its own pilot design. A company that validates at one university runs a nearly identical pilot at the next, and evidence from Pilot A is almost never accepted by Institution B. The cost is redundancy: for institutions, staff time re-evaluating products peers have already tested; for founders, 12–18 month sales cycles repeated everywhere.

What institutional leaders told us at a recent roundtable:

“I don’t have time for a full scan of the market. I have a list of things I’m looking to accomplish, and I’m on the hunt for solutions. What I don’t have time for is to evaluate everything. The RFP process is a gamble because I don’t see the full vendor slate.” — VP of Online Learning, public university

“If two or three other universities had tested this successfully, that would help me convince my internal stakeholders to take the risk.” — Innovation Director, European business school

The recurring theme was time, not money. Even for low-cost products, what leaders lack is the time to evaluate, integrate, and run a pilot. Several described running lightweight tests before involving IT or procurement — what we call a “dirty pilot”: “Let’s not worry about 100% of the tech integration. Let’s see if it works. Let’s see what our students think.”

Pilot readiness checklist

Before evaluating a single product, an institution should answer these. They separate institutions ready to pilot from those still figuring out what they need.

Part 1: Needs discovery

1. What specific gap in the student journey are you trying to close? Map the lifecycle — pre-enroll, apply, onboard, course experience, graduate — and name the phase with the most friction. If you can’t name a phase and a problem, you’re ready for a needs assessment, not a product evaluation.
2. What does “better” look like, and how would you measure it? Complete the sentence: “[Target population] who use [intervention] will show [measurable outcome] compared to [comparison group], as measured by [metric] over [time period].” If you can’t, the pilot won’t produce evidence anyone can act on.
3. Who currently owns this problem? Name the person, not the department. If the answer is “nobody specifically,” the pilot dies from lack of ownership regardless of product quality.
4. What are you doing about this problem right now? Name the workaround (spreadsheets, manual processes, duct-taped tools) and what it costs. If the current state is genuinely “nothing” and no one is bothered, the problem isn’t painful enough to sustain a pilot.

Part 2: Readiness assessment

Scoring: 4–5 “Ready” means you can run a structured pilot. 2–3 means run a lightweight “dirty pilot” to test demand first. 0–1 means focus on needs discovery before evaluating anything.

Evaluation criteria

This is the filter for whether a company is ready for a structured institutional pilot, designed for seed-stage companies ($500K–$3M raised) with a functional product. Founders can use it to self-assess.

Hard filters (pass/fail)

1. Institutional buyer exists. You can name a specific person at a specific institution who would champion this. “Higher education” is not a buyer.
2. The problem is real. Evidence, not assumption, that the problem exists and matters to institutional stakeholders.
3. A product exists. Not a pitch deck, not a prototype. Something users can use today.
4. Validation is possible. You can design a pilot that produces measurable evidence within 12–18 months.
5. The founder will engage. Willing to treat the pilot as an evidence-generation instrument, not a sales demo.

Eight-dimension scoring rubric

The moat durability test

One AI-era lens: does this product survive an LLM plus a two-week prompt-engineering sprint by a competent IT team? “AI-powered” is not a moat — it’s a feature layer exposed to the same substitution risk it claims to solve. Four durable moats apply: proprietary data networks, deep institutional integration (LMS, SIS, SSO) that creates switching costs, supply-side network effects, and regulated access (certifications, compliance, licensed content).

How to run a pilot in 12 weeks

A structured pilot that produces actionable evidence, not “we tried it and it was fine.”

Weeks 1–2: Design

• State the hypothesis using the measurement template above.
• Identify the cohort — minimum 200 students for significance; name the courses, faculty champion(s), and IT contact.
• Define success criteria: what means go (proceed to procurement), pivot (adjust and re-test), and no-go (end the relationship).
• Negotiate terms — pilot cost, post-pilot pricing, data ownership, support — before deployment, not after.

Weeks 3–4: Setup

• Security review (FERPA, SOC 2, HECVAT, LTI 1.3 as applicable). This is where timelines stretch — start early.
• Technical integration (LMS, SSO, data feeds). For a dirty pilot, skip full integration: standalone access with manual enrollment.
• Faculty briefing on the hypothesis, their role, and what data is collected.

Weeks 5–10: Execution

• Launch with the cohort; track adoption, engagement, and the primary outcome metric.
• Weekly check-ins with the company — co-development, not vendor management.
• Mid-pilot review (week 7–8): is the hypothesis testable given actual adoption? If adoption is low, diagnose why before the pilot ends.

Weeks 11–12: Evidence

• Analyze results — statistical significance on the primary outcome, plus qualitative feedback.
• Decision gate: go, pivot, or no-go.
• Debrief with the company, including negative findings. This is what distinguishes a validation partner from a customer.

What institutions actually care about

For founders, ranked by what actually drives decisions:

• Tier 1 — deal-breakers: security compliance (FERPA, SOC 2, accessibility); a named institutional champion who owns the pilot internally; pricing that works for a pilot, not enterprise-scale from day one.
• Tier 2 — differentiators: evidence from prior deployments; willingness to co-develop on feedback; integration depth with existing systems (Canvas, LMS workflows).
• Tier 3 — signals: the founder’s grasp of institutional context; how they answer “what if the pilot doesn’t work?”; whether they treat the pilot as research or a sales opportunity.

What matters less than founders think: the technology itself (institutions buy outcomes, not architecture), awards and press, and “AI-powered” as a differentiator.

Where ASU ScaleU fits

Most founders can’t get a university sponsor on the phone, let alone a paid pilot scoped and signed. That access problem is why ASU ScaleU exists. We place early-stage EdTech startups into paid pilots inside Arizona State University — 190,000 students, 4,000 faculty, 20,000 staff — and provide the executive introductions and operational support to make them succeed. We take 1% in-kind equity for that access, not cash.

If you have a working product and want a real institutional pilot, apply to ASU ScaleU. Then read how to sell EdTech to universities for what comes after the pilot converts, or the 2026 EdTech trends report for where the market is heading.

Adapted from ScaleU’s EdTech Pilot Playbook, published under CC BY 4.0.