Why We Built for Teachers First, Not Students

When Michelle Grant and her co-founder started building LearnPath, the first question they faced — the one every edtech founder faces — was: who is the primary user?

The obvious answer is students. They're the ones using the platform every day, working through problem sets, receiving feedback, progressing through material. Their experience of the product is what ultimately determines whether learning happens.

LearnPath's answer was teachers. And that choice has shaped every product decision we've made since.

The Standard Model and Its Problem

Most K-12 edtech products are built from the student experience outward. The central design question is: how do we make this engaging, motivating, and effective for a ten-year-old? That's a reasonable starting point. Getting students to engage with academic content is genuinely challenging, and UX designers with a child development background can do a lot of useful work here.

The problem with this model shows up at the adoption layer. A product that students enjoy but that teachers can't integrate into their existing routines doesn't get used. A platform that delivers rich student-level data but doesn't surface it in a way teachers can act on doesn't change instruction. An app that students love at home but requires 45 minutes of setup to use in a classroom context gets abandoned after the first month.

The edtech graveyard is full of products students rated highly in pilots. The products that stick are the ones teachers choose to keep using after the pilot ends — because teachers control when and how the platform is used in a classroom, and a tool that doesn't serve teachers' needs won't be used regardless of what students think of it.

What Building for Teachers Actually Looks Like

Early in LearnPath's development, we spent eight months doing something unusual for an edtech company: we embedded a researcher with four different teachers in four different schools and observed their full workday. Not their teaching time. Their entire day — the planning period, the grading, the before-school meetings, the thirty seconds between class transitions when they checked their email.

What we learned from that research shaped the product in ways that would have been impossible to infer from a standard user interview. Teachers don't have extended blocks of time to evaluate data. They have two minutes between classes and maybe fifteen during a planning period that's often interrupted. Any feature that requires more than three clicks to reach in a pressed moment isn't a feature teachers will use in practice, regardless of how valuable it is in theory.

We learned that teachers are deeply skeptical of technology that makes them feel surveilled or second-guessed. A platform that flags a student as "at risk" based on three days of data, or that sends automated alerts to parents without teacher knowledge, is a platform that erodes the teacher's sense of professional authority over their classroom. We avoid both.

We learned that teachers' primary anxieties around new technology aren't about whether students will like it. They're about whether it will create more work, whether it will work reliably during class (offline mode matters, a lot), and whether they'll be blamed if something goes wrong during implementation. Building for teachers means addressing those anxieties directly, in the product, before teachers have to ask.

The Paradox

Here's the thing that makes this decision counterintuitive: building for teachers first produces better student outcomes than building for students first.

The mechanism is adoption. A product teachers trust and use consistently will reach students with much greater fidelity than a product students enjoy but teachers use sporadically. If a platform is used four days a week with genuine teacher attention to the data, students get 30 to 40 adaptive practice sessions per month with a teacher who can respond to what the data shows. If the same platform is used haphazardly because teachers don't find it practically useful, students might get 8 to 10 sessions per month with no teacher follow-up on the data it generates.

The gap in outcomes between those two scenarios is not primarily a function of student engagement. It's a function of implementation fidelity, which is primarily a function of teacher buy-in, which is primarily a function of whether the product actually helps teachers do their job.

What This Has Meant for Our Students

The students who use LearnPath in consistently-implementing classrooms show meaningfully better outcomes than students who use it inconsistently. That's not a surprise — it's the expected result of higher-fidelity implementation. But the pathway to that consistency runs through teachers.

In our pilot surveys, the most common reason teachers give for continuing to use LearnPath after a pilot ends is some version of: "It actually saves me time." Not "my students love it." Not "the research shows it works." Saves me time.

That's the teacher-first design paying off. A teacher who spends less time on the diagnostic and planning work that the platform now handles has more cognitive bandwidth for the relational and instructional work that requires human presence. They're not using the platform instead of teaching. They're using it to teach better.

The Design Commitment That Follows from This

Building for teachers first means accepting some constraints that a student-first design wouldn't require. We won't add features that increase student engagement at the cost of teacher visibility. We won't automate parent communications in ways that bypass teacher judgment. We won't build gamification mechanics that make the platform feel like a game rather than a learning tool, even if engagement metrics go up in the short term.

These are genuinely limiting commitments. There are products in the market that have made the opposite choices and found success with them. We're not arguing that teacher-first is the only viable design philosophy for edtech.