Building edtech is different from building consumer or enterprise software. Users are diverse (learners, instructors, admins), contexts are constrained (school calendars, compliance, budgets), and the stakes are high. Here’s what we’ve learned about shipping products that stick.

Start with the problem, not the feature

It’s tempting to copy what others do or to add features that sound impressive. The best products come from a clear understanding of the problem:

• Who has the problem? (e.g. teachers grading essays, admins building schedules.)
• What exactly is painful? (e.g. “I spend 3 hours a week on repetitive feedback.”)
• Why hasn’t it been solved yet? (e.g. “Existing tools don’t integrate with our LMS.”)

Interviews and observations beat surveys for depth. Run at least 5–10 conversations per persona before locking the roadmap.

Design for the classroom, not the lab

EdTech is used in noisy, time-poor environments. That means:

• Fast load times – We aim for at least 3s.
• Clear affordances – Buttons and actions should be obvious. Avoid hidden menus and multi-step flows for common tasks.
• Offline and low bandwidth – Not every school has perfect Wi‑Fi. Consider offline-capable flows and lightweight assets.
• Accessibility – Screen readers, keyboard navigation, and sufficient contrast aren’t optional. Build them in from day one.

We use WCAG 2.1 AA as a baseline and test with real assistive tech and users.

Iterate with real users

Pilots and betas are essential. We recommend:

1. Define success up front – What would “this is working” look like? (e.g. 80% of pilots say they’d recommend it.)
2. Ship small – One course, one school, one cohort. Learn before scaling.
3. Collect structured feedback – Surveys at key moments (onboarding, mid-term, end) plus optional interviews.
4. Act on the data – If completion drops at a certain step, fix that step before adding new features.

Avoid the trap of “we’ll fix it later.” Later rarely comes if the first experience is poor.

Work with institutions, not around them

Schools and universities have procurement, compliance, and integration needs. To work with them:

• Support SSO and rostering – One login and automatic enrollment from the SIS/LMS. Manual setup doesn’t scale.
• Document everything – Security questionnaires, data flow diagrams, and compliance documentation (e.g. FERPA, GDPR) should be easy to find.
• Provide admin visibility – Dashboards for usage, grades, and progress so that admins can support teachers and report up.
• Be flexible on contracts – Pilots, short terms, and clear renewal criteria build trust.

Product and sales need to align so that promises match what the product can do.

Measure what matters

Vanity metrics (sign-ups, page views) are easy to game. We focus on:

| Metric | What it tells us | |--------|-------------------| | Activation rate | Are users reaching the “aha” moment? | | Weekly active instructors | Is the product part of routine practice? | | Completion rate (by course) | Is content and UX appropriate? | | NPS / satisfaction | Would they recommend us? | | Support ticket volume | Where are we confusing or breaking? |

We review these in product and eng syncs and tie them to specific experiments and releases.

Conclusion

EdTech product work is demanding but rewarding. By starting with problems, designing for real environments, iterating with users, supporting institutions, and measuring outcomes, teams can ship products that educators and learners rely on every day. We’re still learning—follow our blog and reach out if you want to compare notes.