So, you’ve developed a learning technology

In the course of the edtech work I do in the provincial post-secondary system, I often get asked by someone developing a new learning technology to take a look at the technology and provide some feedback. Often these technologies are developed by an educator, sometimes in collaboration with a (usually co-op computing science student) developer/programmer. These are often small, niche projects; labours of love built on the side of someones desk to scratch a pedagogical itch the educator has. I love seeing these projects, mostly because the educators pitching them are passionate about their tool, and that passion is infectious. Last Friday I had the opportunity to again sit in on one of these demos/pitches.

As someone who has sat in on my fair share of edtech elevator pitches from educators, I’ve come up with some standard talking points that I often bring up during the demo/conversation. If you are an educator who has spent some time working off the side of your desk on an edtech project and are looking to take it wider, here are some things you should consider as you begin your journey from educator to learning technology provider.

1. Do your research on where your product fits in to the edtech landscape. There is a very good chance that your idea is not unique and someone is already doing it. That doesn’t mean you shouldn’t do it, but it does mean that you have to be able to differentiate your technology from theirs, and be able to explain that difference to others. And, sorry to be the one who disappoints, but chances are very good that someone is doing something similar to what you are already doing.*
2. Narrow your target audience. What education level is your product aimed at? Broadly speaking, you should decide on whether your system is better suited for k-12 or higher education. And, once you have made that broad distinction, narrow in even further. Educators are no longer looking for one size fits all systems. Focus on who your audience is and develop for them.
3. Pay attention to integration. Your technology will have to fit into the existing technology eco-system of an institution, so be sure to answer questions like, “how does this integrate with a student record system?” and “how will you handle authentication?”
4. Have a pedagogical model. This should be obvious, make sure you can clearly articulate the learning model that underpins your technology.
5. Explain how your technology uses and stores data, and how you ensure that your application is (BC context here) FIPPA compliant.
6. Have other educators use your technology, ideally in a class with students. I often see a lot of work that has gone into a technology that is only used by the person developing it. You’ll learn much from having others use your tool.
7. You need to pay attention to three aspects of your project; Pedagogy, Technology, and Business Development. The pedagogy piece is usually taken care of by the person driving the project, whom is often an educator of some kind. Second, have an actual developer working on the project, someone with a firm grasp of current development methodologies and architectures. Third, have someone who understand business models and can see how to sustain the technology. I often see projects with the first, sometimes the second, but rarely the third. Speaking of business models….
8. If you are going open source (and I really hope you do), know what are successful business models for open source software. There are many to choose from. Pick a model you like and go from there.
9. If you go open source (and I really hope you do), have a plan for how you will develop your community. Open source depends on community, some of whom may be commercial partners and vendors, so don’t exclude them as they can have a valuable role in helping to sustain your product.
10. If you say you support Open Education or Open Educational Resources, you need to explain exactly how you do that, and be prepared for hard questions. I see A LOT of tech products that say they support Open Education, but don’t. If by support you mean “we can take OER’s and import them into our platform”, then unless you can explain to me how you add value to those OER for the wider Open Education community in a way that is free and unencumbered, then you are a freerider and the meeting will end quickly. If you want to work in the Open Education space, and say you work in the Open Education space, then learn how to work in the Open Education space in ways that are meaningful to the goals and aims of the open education community. Here’s a very good guide started by Paul Stacey of the Open Education Consortium where you can start to learn about how to be a valuable partner in the Open Education community.

Now, following these guidelines doesn’t necessarily mean you will be successful in launching your new learning technology to the world. But putting some thought into these areas while you are in the bootstrapping phase of your project will go a long way in helping you take your idea to a larger community.

* If you do find someone doing something similar to you, and they are an open source project, consider joining forces with them.