Made by
Made by
For developer products, education often falls under DevRel. In reality education is a valid concern for multiple teams within companies looking to engage developers, but it’s often characterised differently in product and customer functions. Not to wade into the endless debate about what developer relations is, but it’s not all public speaking–enablement and facilitation are key too.
Here are some considerations I recommend before launching into your education program, based on what I’ve learned building a few myself.
Are you trying to broaden adoption among specific user profiles or communities? Are you trying to deepen engagement and get people using more of your product, or get them using it for more of their development lifecycle?
Product usage data from analytics or research / feedback can inform these questions, and so can collaborating with functions outside of DevRel, particularly in product (management, UX, DX) and customer success / support. These teams can provide perspective on how people are engaging with the product, challenges they’re facing at particular points in their journeys, and so on.
Knowing your product and user context is essential when you define an education strategy. Most dev tools exist within a wider ecosystem involving integration with other products–understanding and supporting that interplay is vital if you want to become part of a developer workflow.
We talk a lot in DevRel about “speaking developer” and tailoring our messaging to a technical audience, but the truth is that people are at different stages of their dev journeys. You might have non-developer users, or they might be less experienced in your part of the stack, or unfamiliar with frameworks you rely on. If you only support experienced experts you’re going to alienate a lot of potential users.
Shifting the focus away from profiles and onto tasks and contexts can diffuse this tension–where are people and where are they trying to get to with your product?
That said, you’ll probably find most people on the technical end of the spectrum prefer help resources to stay out of the way. Creating a low friction experience for these users while also keeping the door open for beginners can be a challenge. Making info available on demand vs by default can help, using modular content, linking to resources on prerequisites rather than including them inline.
Where you are able to deliver your education depends hugely on company dynamics. Does your product have a user interface? If yes, the best place to educate bar none is in context, inside the product–as soon as people have to leave it, you’re going to lose a sizeable chunk of them.
Whether your product has a UI or not, UX / DX will have the biggest impact on developer learning, so if you have any influence over those decisions it’s a good idea to use it (or argue for it)–API and SDK design will make or break the ability for people to adopt any dev tool you interact with programmatically.
Product aside, there are many types of resource you can employ to support learning, including docs, samples, videos, streams / events, training sessions, and interactive experiences. Weigh in maintenance and scalability when deciding where to invest (unless you have unlimited resources). Documentation is the foundation of other activities, it’s self-serve and more readily updatable than most other media, so an initial investment in docs is typically a no-brainer.
Docs are frequently cited in dev surveys as the biggest barrier to adopting tools, and yet are still often neglected (in part because tech writing is infuriatingly undervalued).
Good documentation is a whole thing in its own right, and for that I’ll defer to a couple of experts I always find illuminating on the subject:
Taking the time to define learning outcomes (and even curriculum if you have the bandwidth) before jumping into execution will set you up for developing your program in the longer term. A rudimentary effort vs impact analysis can guide what to pay attention to first.
Creating learning pathways that combine units of material helps to deepen engagement–try to always have a next step. Gamification is rightly controversial in education and doesn’t always result in meaningful learning that lasts. However, certification can be valuable–but imo only once you have a certain momentum, if people aren’t asking for it you probably won’t want to bother.
How does your education program relate to community? For example, if your company has open source projects, you can incorporate them into your learning experiences. If you’re engaging students, you’ll find that some education institutions will be happy to talk to you about including your teaching in their curricula or allowing you to e.g. guest lecture, especially the less formal, bootcamp type courses (e.g. in exchange for licenses).
If you’re working for a startup or have a small team and ambitious growth targets, it’s essential that you build for scale. Can automation play a role in delivering your education program?
Case study: The most comprehensive learning program I’ve personally put together was at API development platform Postman. The nature of the product let me build self-serve, automated learning experiences delivered inside it but without requiring product engineering. We designed a series of mock and real APIs specifically for learning, feeding into a pilot certification program, and integrated into cross-functional engagement including community, customer, and internal employee training. The early stages of the program benefited from a tight feedback loop that helped validate this experimental approach, and the automation provided readily available performance metrics.
There are tried and tested practices you can draw on when you build a learning experience. I’ll leave it to two of my favourite DevRelCon talks to do a much better job than I would exploring these, but some basic principles include connecting to context, being explicit about prerequisites, encouraging reapplication and reflection on learnings, and creating opportunities for people to acquire skills they’ll be able to continue using in real projects:
Another favourite piece of inspiration for me is this report on systematic vs opportunistic learners, which I repeatedly find relevant for developer tools.
Perhaps most associated with learning platform Scratch, remixing is a common element in coding education–see also community web coding environment (who I’m currently working with) Glitch.
It’s worth thinking about performance measurement upfront–not only for leadership buy-in, but to validate and course-correct as necessary.
My personal preference is to start on a small scale and get qualitative user feedback–quantitative analytics are especially subject to interpretation and not always high enough fidelity to justify an experimental strategy. If you’re liaising with customer and product teams, they might have ways to trial your learning with users in contexts that generate more meaningful output, since they often have existing tracked relationships they can leverage.
DevRel people often don’t want to go down this road, but if you really want approval to educate, customer engagement data, such as feature uptake, upgrades, and retention can prove most compelling.
And finally, you can’t learn without failure:
Failure is part of writing code, but we need to make it safe for everyone to fail if we want tech to become more equitable (warning: soapbox content).