Why adoption, not technology, is the real challenge for VocTech

From my experience, testing solutions with real users in real environments as early as possible is essential. Assumptions that seem perfectly reasonable during product design can quickly unravel in practice.

I remember preparing to test a digital platform with a group of learners when I discovered the target audience didn’t have email addresses and our entire onboarding process had assumed they did. On another project learners needed to download an app before they could start using it. Technically this seemed straightforward, but many learners were reluctant to install it. Some were concerned about using their mobile data. Others simply didn’t have enough storage space on their phones.

Again, the technology itself wasn’t the problem. The issue was a small design assumption about how learners would access it.

These challenges are rarely about sophisticated technical problems. They come from simple assumptions about the environments in which vocational learning happens. And these minor niggles can destroy adoption.

Education, training and workplace environments are complex systems. Even when a new solution offers clear benefits, several practical barriers can slow adoption.

Teachers and trainers already operate under significant time pressure. New tools require time to learn and integrate into their teaching practice. Procurement cycles can be slow and budgets can be tight. Existing platforms and processes are often deeply embedded. And, as I’ve witnessed on several occasions, experiencing implementation barriers on the ground, can quickly turn off any potential champion.

All of this means that even excellent technology can struggle to be adopted if they don’t fit naturally into the workflows of educators and training providers. In my experience, the difference between a promising pilot and a widely used solution is not how well the individual features work, it’s how well the overall solution fits into the reality of life.

Also, if we’re really thinking about scale, the challenge is not just helping one customer adopt our product or service, but it’s designing it in a way that allows their adoption to spread easily across other teams, departments and organisations.

I’d like to share a few practical examples from the projects I’ve seen ‘solve’ adoption (and then seen the seven-digit ARR that follow).

One approach is to treat adoption as a critical product feature on the roadmap. This could be investing in resources that make it easy for educators to use the technology straight away.

Ufi portfolio company Bodyswaps, for example, built a dedicated area on its website with tutor resources and lesson plans to show exactly how its simulations can be integrated into teaching sessions. Instead of leaving tutors to work out how the technology might fit into a course, the downloadable lesson plans show clearly how and when it can be used.

TeacherMatic, previously supported by Ufi through grant funding, had the benefit of having an FE lecturer as a co-founder. They knew that the solution needed to integrate with the platforms educators already rely on and adopted an ‘integration first’ approach by developing the platform as an LTI to connect directly with Microsoft Teams and other LMS. By appearing within a platform many educators already use every day, the tool became part of an existing workflow rather than another standalone system.

Recently I saw another example where a VocTech provider had created an entire scheme of work showing how their tool could be used across a 15 month apprenticeship programme. It mapped out where the technology would appear, why it was being used at that point in the curriculum, and how it supported learning outcomes.

It wasn’t simply a tool being added to a course. It was a tool being thoughtfully embedded within it.

Wherever you are in your project, perhaps it’s time to start thinking less about the next feature on the backlog, but about how the current features will work within the everyday realities of education and training. Try asking yourself a few questions:

• Could a busy tutor realistically deploy this in a session tomorrow?
• How confident am I that our solution will work seamlessly in ten (or a hundred) different settings?
• Does it integrate naturally with the tools and workflow our users already have?
• Have we made it clear how it fits into a course or training programme?
• If one tutor finds it useful, how easy is it for that success to spread?