Building an invisible product

A couple of years ago, I joined a venture to help create more personal and better connected classrooms. Our mission was to help make the lives of teachers much better. We saw a whole bunch of tools to aid students but very few to help teachers do more of the amazing work they were doing. We started doing this by allowing teachers to send out fun and interactive pulse surveys to check-in with their students. While the mission was noble, we had a problem.

The Problem

A significant amount of teachers we had reached out to did not want to have the overhead of adopting a new product. These teachers were already strapped for time and forcing them to learn a new tool would not be making their lives any easier.

The problem was clear, for the tool we had built to stand any chance of being used we’d have to make it so invisible that our teachers wouldn’t even know that they were using it.

We decided to dig deeper and understand the lives of the teachers we were building our product for. What their day looked like? What tools were they currently using?. We realised that among the suite of tools they were currently using, the one that they depended on most was their calendar. Their classes, portions being taught on the day, it was all part of their calendar.

We built a way for our teachers to send out our pulse surveys on days when specific portions were completed or even post a test. They could flexibly schedule it all in advance within their familiar calendar. Without ever having to login to our product at all they could check-in with their students at the touchpoints they had decided previously. Now pitching our product to teachers we saw an increase in uptake. It not only helped get more teachers to use but also drove increased usage of our product among our existing teachers.

It was an important product lesson but one that was so simple and one that should have been obvious.

  • What we failed to realise was, when a teacher agreed to use our product they were taking a huge bet and it was an extremely risky decision for them to take. It was our responsibility as creators of the product to reduce the risk associated with it by making it easy to plug into their daily lives.
  • In addition to making changes to the product, we were also physically present when they needed our help. We’d go help them out the first time they were using it, be present when they were demoing it to other teachers and get on a call with them as soon as they encountered. These things aren’t necessarily scalable, but sometimes “you need to do things that don’t scale”.
  • Ultimately, the cool technology stack you’re using or the complicated feature you shipped is not valid, unless your product adds value to the lives of your user. Our teachers cared about wanting to be in the know about how their students were doing, that’s all that mattered to them.

Thanks to Akshar Patel, Rami Sanad and Kiran Patel for reading through the draft and giving me feedback!