The brainy, out-of-touch computer geek has long been a sitcom archetype. From Doogie to Leonard and Sheldon, these intelligent yet hapless characters’ struggles to communicate with normal folks is a source of amusement.

But these delightful storylines about experts frustrated by the need to occasionally communicate their esoteric knowledge with the laypeople in their lives hyperbolizes a challenge recognized by many real life ed-tech entrepreneurs.

Most developers realize that their chances of building a (commercially and socially) successful tool improves with input from users. Yet finding beta-testers for these products has been a real hurdle in the ed-tech space. It turns out that teachers are busy people, and programmers and educators sometimes speak different languages.

The Edu Tech Innovators Meetup held this month in San Francisco was sponsored by the team behind LearnBoost, a range of free teacher tools, with the hope of bridging this divide. The event brought together a panel of teachers and entrepreneurs to begin hashing out a framework for better cooperation. Betsy Corcoran of EdSurge moderated a fantastic discussion between Alan Louie, former special products manager at Google and partner at startup incubator Imagine K12; Mick Hewitt, CEO of startup MasteryConnect; Jack West, a high schools physics teacher in Redwood, CA; and Benjamin Chun, an MIT graduate and computer science teacher at Galileo Academy. Their conversation was part of an ongoing effort to codify a basic understanding between teachers and ed-tech developers, ambitiously called the Beta-Testers Bill of Rights.

Here at NewSchools, we’re intrigued by this conversation. It fits with our belief that teachers and their students must be deeply involved in the design process of any new education technology if it is going to have a transformative impact on instructional practice and student learning. Interesting enough, Betsy noted at the conclusion of the conversation that the industry may not be quite ready for a “Bill of Rights” — but that both teachers and developers surely need better “terms of engagement.”  

Here are some of the key points I took away from the Meetup.

1. Be respectful and build a personal relationship. “[Developers] need to understand where [teachers] are coming from,” noted Benjamin Chun. “We spend all day with kids. It’d be nice to be taken out to lunch occasionally.” Bombarding a busy teacher with emails isn’t likely to win you brownie points, either. Their involvement in the beta release of a tool might eventually make their lives easier by tackling a problem in the classroom or saving task time, but it might not be worth it. Testing a “buggy” tool may be incredibly valuable for developers—but candidly a waste of time for teachers.  The entrepreneurs at Engrade, a suite of free online teacher tools, take teachers’ busy schedules very seriously when making product developments. The team goes so far as to count the number of clicks it takes a teacher to perform discrete tasks with Engrade tools to make them as teacher-friendly as possible.  
2. Be honest and upfront. “I want to know what your plan is,” says Chun. “If you want to build a product that makes a ton of money, that’s fine. Just be up front about it.” Being honest about your motivations is the best way to start a good working relationship with teachers. Teachers also need to know exactly where the tool is in development and what type of feedback you’re looking for.
3. The right price for teachers is free. Cost may be one of the most significant barriers to getting your tool into classrooms. As budget shortfalls become the new normal, teachers are often left to make out-of-pocket purchases for anything but the most basic classroom supplies. Last year teachers spent $1.3 billion of their own money on education supplies for their classroom. You can be sure the majority of that was spent on Kleenex and not on iPads.   
4. This is not just a two-way conversation. Even if teachers find a tool they believe in and want to implement it in their classroom, they may face additional hurdles from school or district leaders. Many teachers I spoke with at the Meetup told me that they didn’t feel empowered to try new tools in their classrooms (though, those at public charter and private schools said they had more autonomy in their classrooms). Superintendents, school boards, teachers, and students may all differ in what they think makes for a useful ed-tech tool. Timing of the conversation is also important. While school districts may be motivated to put large sums of money into the development of data dashboards that make their jobs easier, teachers are more likely to benefit if they are consulted on their needs early on. Be prepared to navigate the complexities of modern school politics.
5. Not all teachers are built the same. Just as not all programmers are from Mars, not all teachers are from Venus. Teachers with the predisposition to explore new and useful tech will explore new products. Teachers without that drive won’t. The key for developers is to seek out those teachers open to using new technologies in the classroom. If you are a teacher interested in using a tech tool in your classroom or a developer looking for beta-testers, investigate ed-tech Meetups in your area. Another great resource is the Beta Classroom, a project run by teacher Jennie Dougherty.

EdSurge’s Betsy says her team is committed to continuing to explore these issues. “There’s an essential yin-yang to building great products,” she says. “You need great developers talking with great users.”