Learning Technology Roadmap

In a decentralized learning function with 72k learners in 10 countries, landing on ONE learning technology roadmap can be challenging, but it’s critical. Often, the limited budget and headcount aligned against the technology needs of the learning function and its myriad of authoring, curating, tracking, and operations platforms makes it critical to have a clearly articulated learning technology roadmap with buy-in from all of the stakeholders, especially when they don’t all report into the same learning leader.

Not Our First Rodeo

Shortly after the arrival of the new learning technology manager (in 2012), an effort was underway to identify what learning technology would meet what business needs and when. The organization was still a centralized learning function at that time and the principles behind user research had not yet taken hold in our organization. It was largely a command and control approach, though stakeholders from each division (or Line of Business) participated in drawing up the ideas of what they wanted to support their organization.

On the positive side, the result of this original road map was the implementation of a number of impactful learning technologies: a cloud-based LMS, a VILT platform, mobile delivery of content, and a new learning operations platform. On the negative side, that roadmap became an enforcement tool for shutting down any efforts in the Lines of Business that weren’t reflected in the plan. With the decentralization of the learning function, the funding, energy, and intent really moved into the LOB teams to move learning tech forward while the learning technology team largely maintained status.

Resetting with a Focus on the User Experience & Business Priorities

Through transitions in leadership and a heightened focus on the employee experience(EX)/learner experience (LX), a new effort began in late 2017 to redefine the learning technology roadmap focusing efforts on incorporating numerous rounds of user research on topics like: digital learning, system functionality, mobile experience, SME-engagement, and other topics to create a more integrated road map. Because we leverage the product mindset, we believe it’s necessary to balance both business priorities as the business funds our work, but also, the user as our consumer. As we quote frequently – “the value isn’t in what gets built, it’s in what’s used.” We took all of our insight from user personas and user research and combined that with a series of questions we posed to each LOB team around business objectives, learning strategy, technology exploration, and current click paths.

14 Feature Sets?

With such a large audience across such a large footprint servicing so many different business needs, it should be no surprise that the results yielded 14 distinct  sets of features that the users and the business were looking for. We have a belief that there’s not one solution that can solve for all of the needs of the modern learner – it’s necessary to build a learning ecosystem and allow those feature sets to move across one system or the other, and as long as those systems leverage microservices and have a flexible framework for displaying data, the user experience can be integrated across platforms.

Prioritizing those feature sets was an entirely different matter. Here are the considerations we took into account to prioritize the work.

  1. Resourcing. Unlike years past when all technology was implemented and managed from an enterprise-level group, it was time to deprioritize ownership and focus on leveraging whatever technology from whatever group had resources. If one group thought it was important and worked to implement – don’t get in the way. We should support them, then offer to pick up costs/management if it solves for priorities for multiple groups.
  2. Level of interest across multiple groups. The next logical criterion was around level of interest. The more groups that committed to adopt and deploy the functionality in their learning solutions, the quicker we should get to the work.
  3. Alignment with key enterprise-wide imperatives or business goals. If there was an opportunity to tied the system or feature set to an enterprise imperative or business goal, that should elevate the priority of the work. Examples might be a tie to people management, diversity & inclusion, or strategic business goals.
  4. Dependency on other pieces of the eco-system. Some parts of the ecosystem needed to have a firm data set behind them in order to function, others needed to be built into a larger platform that already existed It only makes sense to prioritize what might be a dependency.

Product Management Approach

Given that our learning platforms were now distributed to multiple teams across the org, I needed to take steps to unify our approach, not by org or chain of management, but by the competencies of the role. I decided we no longer had “system owners,” they were product owners, responsible for knowing what’s happening with the technology, gathering feedback from users, and making decisions with the business in mind. Each product owner was responsible for keeping a clear list of bugs and enhancements and tracking their status. They had to publish a monthly roadmap, even for SaaS applications where we just made configuration decisions, not completed native development.

These product owners would need to be the liaison with the business about what their system could do, the liaison to the vendor or development team about our priorities, and should have means to regularly gather input directly from users, via empathy interviews and user research. We established an advisory committee where as many folks from the business and learning team could join the product owners on a monthly basis for an update on the roadmap and to be available to ask/answer questions about what they needed for their organization.

Inspect What You Expect

All of these items were collated in a few decks that included the following, available for our LOBs and leaders to see at any moment:

  • Quarter by quarter view of product deployments for the next 3 years
  • 12 month rolling product roadmap (with an outline of what would be developed vs what would be deployed)
  • The business, learning, and learning technology priorities for each LOB in the business
  • A Harvey Ball chart showing demand for function set by LOB
  • A priority list for what technology was most critical for implementation in order
  • A platform dashboard that outline release dates, status, and highlights for all existing or in-implementation products
  • A click-path of how the major learner personas across Capital One accessed their learning content
  • A plan for a learner experience platform (LXP) to sit on top all of the other platforms to give users a unified experience

I’m sure there are parts of this that are overkill for many organizations or situations, but in a federated model, communication and partnership are the silo-killers. While in its essence it can seem like a CYA to make sure no one can complain about a system not meeting a need since they had a chance to complain, it was fact, so much more. These items weren’t just shared at Advisory Committee meetings, they were repackaged and sent to stakeholders, presented at Learning Council meetings, shared in cross-department lunch and learns and forums, and published for all to see. While business needs or user feedback can drive a roadmap to change (and should drive it to be iterated upon), a lack of communication and awareness should never be the reason that resources aren’t prioritized to meet the needs of the learner.

A few months ago, an effort was in place in this organization to identify which parts of the centralized Enterprise team should be decentralized. When we saw the results, we knew we were doing the right thing – only one participant out of nearly 20 advocated for taking ownership of systems in their LOB – the rest had grown confident that the Enterprise team heard their requests and advocated for their needs.