EdTech companies: start with your users, not with a problem.
As a product manager for Apple in Education, I’ve seen far too many in EdTech stick to solid product management advice, only to realize that education is (for good reason) a different ball game. If you want to build a successful EdTech product, below is an alternative framework to ensure your EdTech products meet the needs of teachers and learners.
Design with teachers and learners, not for them.
Good product advise often won’t work in education because it’s a complicated industry with an additional, more important, measure of success (learner outcomes) that is often not correlated with usage or financial return. Designing effective products for education is hard. Especially if you have not been a teacher in the last few years. No, going to school yourself or having a child in school does not qualify you as someone who “knows education”.
Simply building what teachers explicitly ask for also won’t work. It’s not their job to tell you what to build. To build a product that truly has a meaningful impact, design with teachers and learners as you challenge the boundaries of our existing system. Here’s a framework to help you create an open, collaborative process to stay close to your teachers and learners during every phase.
Phase I: Explore with Teachers and Learners
Don’t focus on a solution or a pre-determined problem. You might be good at problem solving, but this is the art of problem finding a problem worth solving. It’s easy to say “absentee rates are very high” and implement severe repercussions to deter students from missing school (note: this may decrease absentee rates, but likely due to a decreased student body). Or you might remember the tech solution that automatically calls home when students miss school (note: this doesn’t work for commonly absent students who have little parental support). Teachers already know this. It’s much harder, and more worthwhile, to understand the nature of problems your users really want to solve. Investigate why and when students most often miss school, how that impacts teachers and students, and how parents feel about it. At LearnSprout, we found that identifying absence patterns helped schools create tailored programs to increase support, and in-turn attendance, for particular groups of students, where a one-size fits all attendance policy wouldn’t have worked. Your exploration should include both the people you’re building for and partners you might build with.
People: Define Your Users
Students? Teachers? Parents? They should be your main focus. Meet them in person. Don’t just send out a survey or make phone calls. Work around teachers’ schedules, and if a teacher invites you to their classroom, go. Understanding the context is critical to designing a meaningful solution and is best done in the classroom, not in your office. The reality of 28 chattering students watching your every move will make an intuitive, uncluttered dashboard a necessity rather than a nice-to-have. At Apple, experiencing unreliable internet connectivity in most classrooms stressed the importance of “offline mode” in apps on our platform. Unfortunately, EdTech products are often built with complete disregard for classroom realities. Observing the challenge of helping three students catch up from absences while engaging the rest of the class will demonstrate that even the most well-designed education app can’t overcome missed class time.
Teachers are severely time-poor. You need to experience the chaos and the magic of their classrooms to begin to empathize with them.
Catching a glimmer of pride flash across a teacher’s face during a student’s presentation can tell you much more than a description of why they went into teaching. Seeing the delight in a student’s eyes as they build their own pulley system is very different than an “I hate science” comment. Ask teachers what parts of their day are the hardest and which bring them the most joy. Ask more questions. Ask them why, and then ask why again, until you deeply understand their hopes and fears. You might understand that students skip school because they feel disengaged, but keep asking why until you understand whether they feel bored or intimidated, excluded or unsafe. Ask why again to understand what motivates students to come to school. You’ll need these insights to separate your product from surface level feature requests that don’t move the needle.
And don’t forget that in education, there is rarely just one stakeholder. Your main users might be teachers, but including the perspectives of students, school leaders, and parents is critical to the success of your product. Once you understand how students might be motivated to attend school, ask parents of commonly absent students for their perspective.
No, going to school yourself or having a child in school does not qualify you as someone who “knows education”.
Partners: Education is a team sport.
Local partners and specialists in your field will add meaningful perspectives to your exploration. A child psychologist might explain the importance of play in creating an optimal environment for learning; a lobbyist for increasing teacher pay will describe the long hours teachers drive to pick up students to make sure they come to school. Understand the cultural, political, and historical background of your topic, which will differ in every region. Partner with researchers who can guide you to studies that improve your effectiveness even before you have user data to measure it. If research shows a strong correlation between mental health issues and absenteeism, this might guide your exploration in a different direction. Partners can later help you scale your product by understanding the nuanced cultural and structural differences between diverse learning contexts.
Phase II: Make (Learn) with Teachers and Learners
The insights and observations you collect during your exploration will help you formulate a hypothesis (not yet a solution) but you should still have questions along the way. Make something to find out.
Use prototypes to learn what you need to know, rather than to test what you think you already know.
A prototype doesn’t need to be your MVP or even a rough version of it (in fact, it’s better that way, so you don’t feel compelled to keep it). And testing a prototype need not always give you a direct answer, just a new insight. Instead of building a MVP app that labels students based on their attendance, make some hypothetical charts to see what teachers find useful, or simulate a scenario where a Sammy Student drops out, and ask a teacher or parent what information she wishes she knew last month.
At LearnSprout, we showed mock charts to intervention specialists and learned which chart designs motivated pro-active action and which pieces of data were most valuable. Through this type of prototyping we learned that looking at attendance by demographic group prompted more self-reflection and action amongst staff than looking at attendance by student, class, or grade level.
Read between the lines. Take what you heard and distill it into insights you’ve learned. This likely won’t be direct feature requests or explicit statements you heard, but rather what you learned from the way teachers and learners react or interact with something you made.
Try something new
Bring teachers and students into the creation process and learn from what they make. This doesn’t mean stealing ideas from teachers and productizing them. Ask teachers to draw a dashboard of information they want and learn from the way they describe the most important pieces of information and how they’d use them. Have students draw a portfolio and hear to whom they’re most proud to showcase it. As soon as you learn something new, share your insight with a different group of teachers and learners to see if it resonates. Then incorporate it!
Phase III: Implement with Teachers and Learners
Keep building what you learn into your product until you’re sure it’s something teachers and learners need and want.
In the tech world, we think our product is ready when we’re done building it. In the education world, a product is inextricably linked to the way it’s used and the impact it has.
As a product owner, take responsibility for the learning outcomes, not just for building the product. Here are three tips:
- Make it as easy as possible for your product to fit into a teacher’s or student’s day. Education is a system. Understand how your product fits in. Before building, ask: How will it work with the other tools they use? What will they do next after using it? What does IT need to set up? Your learning phase can uncover ways to reduce friction, enable action, and simplify teachers’ and learners’ lives. Before launching: Map out the end-to-end experience of a teacher interacting with your product. Where will teachers hear about it and how will it make students or parents feel? How will teachers guide students to use it? Your product might add great value, but if it takes too much work to setup or learn, schools won’t have the time.
- Always pilot, and pilot early. When you think you’re done, find willing teachers to try it out in the real world. Make sure teachers have the appropriate support and approval from their school. You might have the greatest new product since rubber erasers, but you still don’t have the authority to tell a teacher or school what to use with their students. Budget room in your development process so you can afford to make changes after a pilot. Companies often interchange the word “pilot” with “soft launch”, but they aren’t the same thing. Soft launches are an exclusive release of a complete product. If you can’t imagine spending 30% more time making changes based on your pilot, then you waited too long.
- HOW your product is used is more important than IF your product is used. Invest in professional learning for teachers so they know how to get the most value from your product. This could be a tap-through welcome flow, short and specific how-to videos, online webinars or in-person training. Consider any organizational culture shifts that your product might require. Teacher training should be a critical component of any education deployment.
Don’t measure your success by the number of teachers using your product. Measure whether your product is being used in a meaningful way that leads to the outcomes you set out to move.
Bottom Line
In an ever-changing world that requires a massive transformation of the way we teach and learn, amplifying teacher and learner voices within our development processes will guide us to build products that truly address their needs and move us in a direction they believe is right for learning. Take the time to explore beyond surface-level feature requests or market opportunities to build tools that shape the future of education. Together.
What EdTech development methods have worked for you? Educators or students, how would you like to see EdTech products developed with you? What can we do better? I’d love to hear from you!
