No one’s path in life is conventional, and my career from instructional designer to product manager is no exception. If I’ve learned anything it’s that instructional designers have a lot to learn from adjacent industries, especially product management.

A little about me.

My love affair with learning began in 2005 while I was in Russia for an extended volunteer mission. I like to think I’m a quick learner, but trying to learn and use Russian grammar in all its Cyrillic glory stretched me more than anything I could remember. I came to love investigating how to make the learning process better, more efficient, and more fun.

My journey to become an instructional designer is remarkably boring (and probably familiar to all you instructional designers out there). It went like this:

learner → teacher → trainer → instructional designer

By the summer of 2014, I found myself with a PhD in Instructional Design, working as the lead instructional designer for the language learning products and curriculum at the LDS Missionary Training Center in Provo, Utah. True to my training, I approached learning problems with my own adaptation of ADDIE, and was in “instructional design heaven.”

Until…

I started digging in to a particular set of what I thought were learning problems with our proprietary language software, matter-of-factly dubbed Technology Assisted Language Learning (TALL for short — pun intended). The learning experience in TALL was years ahead of its time, using approaches like blended learning and flipped classrooms at least a decade before they became a “thing.” It was built on sound principles of language learning from leading experts in the field. But I couldn’t find an “inside the box” solution to the question: Why was TALL not revolutionizing language learning?

After more digging than I care to admit, I had the “novel” idea of asking the users why they felt TALL wasn’t revolutionary. As you’d expect, it took me less than 30 minutes to realize the answer: TALL wasn’t leading to amazing language learning because no one was using it, and no one was using it because the experience was terrible. Our users either couldn’t find — or couldn’t stomach the interface long enough to find — the instructional gems that would lead them to wonderful learning.

The problem wasn’t a learning problem at all.

ADDIE hadn’t prepared me for this.

Cue “out of the box” thinking. I turned to Google and was confronted with terms like user experience, user interface design, human-centered design, and so on. One term in particular stood out: product management. Eureka! This was doubly interesting to me as I was often referred to as a “product manager” to appease a certain service department that was adamant on having a monopoly on instructional design roles, but I digress. I began reading articles and books, and became more and more convinced that TALL needed an exclusive product manager if it was ever going to overcome its inhibiting interface. After much lobbying, I eventually pawned off my other responsibilities and became the first “TALL Product Manager.”

It was rough at first, and I felt a lot like how I imagine Luke Skywalker must have felt trying to resurrect an ancient religion on his own. But bit by bit, the pieces of a healthy product organization began to fit into place.

User-centered Process

Step one was to take a good long hard look at the current design process. Henry Ford would have been proud. The research team would conduct an analysis and find learning gaps that needed to be addressed and present them to the instructional design team. The instructional design team would then brainstorm ways to fill the learning gaps. An instructional designer would then design a wireframe, complete with learning objectives, and present it to the graphic designer. The graphic designer would make it look pretty. The designs were then sent to the technology team for development. When the solution was built, we piloted with whomever we could easily find and quickly confirmed our biases (that’s the point right?). Then we would pass it to the training department for implementation into the curriculum. The research team would then prepare an evaluation and start the party all over again. Sounds like a successful implementation of ADDIE, right? I learned that in product management speak, this process is referred to as “waterfall” and was abandoned years ago.

I sat in a room with the technology lead and we began dreaming what the ideal product design process would look like and came up with this:

Basically another version of ADDIE, with a heavy emphasis on iteration based on user feedback all along the way. I decided to “practice what I preach” and took the process itself out to different members of the organization for feedback. Several iterations ensued until we landed on this:

It’s certainly not the best product design process out there, but for us it was a game changer. We started talking to our users several times a week. Einstein once said, “If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about the solution.” Well, we spent a ton more time actually understanding the problem before jumping straight to a solution. We started setting qualitative and quantitative user-feedback benchmarks to progress from one step to another.

User Experience Designer

Step two was introduce a user experience designer as a key member of the organization. Up to this point, I had part-time access to a group of very talented, but overworked graphic designers whose job was to make things “look pretty.” After even more lobbying, I convinced the higher-ups that we needed a UX designer and hired one. Instead of just taking my ideas and making them “look pretty” he made them usable and delightful. He helped make our user testing more effective and avoid the plague of confirmation bias. Not only that, but the developers loved working with him so much they actually persuaded me to have him join them in their lair. Which brings us to the next piece.

Cross-functional Teams

Step three was to create product-centered, cross-functional teams across the design and technology teams. This was the hardest piece for the rest of the organization to digest. The higher-ups were worried that this would eat into the developers programming time, making the whole process less effective. I lobbied, convinced, persuaded, and did everything short of bribing the higher-ups to give it a try. We divided the products among teams, assigning a product manager, UX designer, and technology group to each team for each product. They started implementing agile practices, including daily standups and weekly reviews. Best of all, the developers even started participating in the user testing sessions! Naturally, productivity greatly increased. We noticed the usual pushback from the developers pretty much disappeared because they were involved in making the design decisions. As a result, a couple of great things happened with the developers: 1) they understood the vision, and were much more invested in solving the user’s problem rather than just building features and 2) they could anticipate what they would eventually need to build and make sure they were prepared for it.

Communication

All of these changes were implemented in a short period of time in an organization that has mostly run the same way for decades. Yikes… I quickly realized that if I didn’t educate the rest of the organization, I would be spending the next couple months putting out organizational fires. I built a deck to advertise the changes and went on tour to each team, presenting the changes in their staff meetings. Not only was I welcomed with open arms, but the other teams were grinning from ear to ear to be “in the loop.” This created a regular cadence with each team, where I would periodically attend their staff meetings to give updates and coordinate.

All in all, this product management stuff wasn’t all that bad. As a product team, we felt invigorated. We were getting things done, and the organization was cheering us on.

But I was just getting my feet wet.

Product Management at Pluralsight

I went to a product management conference, heard all sorts of amazing presentations, and realized that my journey was just beginning. Through a little networking and a lot of luck, I found myself with a job as a product manager at Pluralsight (an EdTech company with the mission to democratize professional technology learning). I got to rub shoulders with product managers and UX designers as part of a product team with a collective century of experience. The concepts that we “discovered” at the MTC were a way of life at Pluralsight, and it was very refreshing.

My learning background combined with my emerging skills in design-thinking and user empathy suit me very well as a product manager in a learning company. I get to work with others on my product team to help them understand the basics of learning theories, but I also am often knocked off my high horse as I listen to users describe what they need. I get to fiddle around with fun internal dilemmas: for example, what do you do when you are aware of strong scientific evidence that indicates learning styles don’t actually affect learning, but 95% of the population strongly believes they do? Do you risk alienating your user base in pursuit of staying true to what you know? Or do you acknowledge the so-called “learning styles” to match users’ expectations and hope for a placebo effect? That’s another topic for another time, but I hope you get my point.

I’m by no means an expert, but I’m becoming convinced that true innovation is found at the boundaries between disciplines. Instead of focusing solely on one field, perhaps becoming a more influential instructional designer means spending a bit more time investigating adjacent fields that attack similar problems. I certainly found some noteworthy nuggets as I dove into product management.