Teacher Input Essential to Startup Product Development

DaveMyersToday’s blog is written by Dave Meyers, CEO and co-founder of TeachersConnect, whose mission is to provide communities for educator mentorship and collaboration. 

When your aim is to build an amazing ed-tech product, you’re almost always in a race against time. Getting to market quickly is the established measure of success–something we hear from investors and entrepreneurs alike. The risk of moving too slowly is that your competitors will beat you to the punch.

But moving too quickly carries its own risks. What if you don’t ask the right questions at the right time? What if you bring the wrong product to market? What if you miss obvious opportunities for impact and growth because you weren’t paying close enough attention?

When we began work on TeachersConnect, we took a calculated risk. Although the management team has a combined 35 years of experience in education—about half of it in the classroom— we decided to take precious time to establish a channel of constant, meaningful communication with teachers (our users) in which imagination, curiosity, and value fly in all directions.

Educator Input is Non-Negotiable

Here’s the system we used to make teacher input a natural part of our product development process;

Using the Agile process, Marcel Ollmann (CTO) and Eliza Kano-Bower (Director of Customer Success) designed a development process with one-week design sprints followed by one-week development sprints. The “must-have” element in this process that was not negotiable, was teacher input. Enter seventy Trailblazers—real, live, full-time/overtime classroom teachers who’ve volunteered to provide weekly input and feedback on our product development (stay tuned for a companion blog explaining how we recruited them).

Our aim was to cultivate an authentic, low-stakes bond with teachers whose contributions to the design of TeachersConnect would give us the sensitivity, immediacy, and flexibility to dramatically increase our chances of making a deep impact on teachers—now and in the future.

How the Design Sprint Unfolded

I’ve described the one-week design sprint below. The steps are illustrated in the accompanying diagram.

Day 1:

We state our hypothesis about the feature, articulate the questions we want to test about how it will solve a specific problem related to teacher collaboration, determine the best method for testing it (e.g. interview, survey, resonance test), and begin scheduling time with our seventy Trailblazers. Our goal is to deeply “understand” one problem in a teacher’s life that we’re going to address in the TeachersConnect app.We dip into our product road map and extract the feature(s) we believe will provide the most immediate value to teachers. We’re selecting only the feature or features that can be built with just one week of one developer’s time.

Days 2-3:

Dan Staton (our UX designer), Marcel, and Eliza take 36 hours to “imagine” and “design” mock-ups of how we’re going to solve the teacher problem we’ve selected for the week. They call them “rough” mock-ups, but they usually look and feel pretty darn good.

Days 4-6:

We conduct user research and “learn” the answers to our questions and the results of our hypotheses.

During this stage, we take the results from the user research and tweak or—if Trailblazer feedback demands it—overhaul the initial designs, getting follow-up feedback along the way, sometimes from the same teacher involved in the initial “test” and sometimes from a different teacher.

Day 7:

Back to  the “understanding” phase. We step back briefly, consider the implications of what we learned during the sprint and how that might affect future—and sometimes prior—design decisions.

The team then turns the designs into development tickets, passes them along to the developers, and gets ready to begin the whole process again.

research_develop

Teacher Trailblazers are Essential to Development

It’s certainly not a perfect process. We’d love to have our coders more heavily involved in the design sprints, and there are elements of an app that are just too tough to test with much reliability (e.g. the way features affect the app experience over time; the way two distinct feature sets interact with each other). There’s no doubt at all that we’ll miss something, make mistakes, and take our lumps, but there are three things of which we’re confident with the Trailblazer program:

  1. We’ve nurtured a team of teachers—one that will continue to grow over time—who have high expectations of us.
  2. The Trailblazers are invested in TeachersConnect and feel the confidence and power to guide up forward and to speak up when it looks like we don’t “get them.”
  3. The Trailblazers love the direction and the vision of TeachersConnect, which means that we’ll have a tremendous crew of cheerleaders and spokespeople when our app hits the stores this summer.

And that was well worth the extra time.

 

3 thoughts on “Teacher Input Essential to Startup Product Development

  1. Ηi would you mind stating which blog platform уou’re working with?
    I’m going to start my own blog soon but I’m havіng a diffiсult timе сhoosing between BlogEngine/Wordpress/B2evolution and Drupal.
    The reason I ask is because ʏour layoᥙt seems different then most blogs and I’m looking for something completely unique.

    P.S My apologies for Ьeing off-topic bսt I hаɗ to ask!

Leave a Reply

Your email address will not be published. Required fields are marked *