It’s February, and the stores abound with Valentine’s Day products in all the hues of red and white. Online, I’m being bombarded with ads for dating apps and articles with advice for catching and keeping that special someone. Most of this content is pretty barf-worthy (and some is just downright sexist), but it got me thinking: some of these “tips,” while awful for dating, might just be useful for an Instructional Designer.
Discovery Meetings – Or, Your Blind Date
“So, I met this new training initiative and I think you two would really get along…”
Let’s quickly define what a Discovery meeting is. If you do any kind of curriculum development, hopefully your company is giving you time to schedule “Discovery” meetings (I’ve also seen these referred to as Analysis meetings, after the “A” in the ADDIE process). This is where you sit down with your stakeholders and find out why they think they need a training product. The idea is to gather as much information as possible about:
- What problems the company is seeing
- Why your stakeholders think training is the answer
- Where they’re pulling their data from
- Who you can talk to over the project’s lifespan to gain more information
So how does one conduct a successful first meeting with people who are likely to be too busy to read up on learning theory and expecting to be able to simply “order up” a training module and move on with their day?
To the dating articles we go!
Wow Them with Your Words
“Your eyes are like sapphire pools of blue, your font is a 12-point Times New Roman…”
Blue Ocean Strategy (the second result on Google at the time of this writing) has several tips that all boil down to communication:
- Don’t over-complicate things – Ask simple questions that cut down on your stakeholders’ tendency over-explain, or give you too much background information. For example, instead of asking “How does X software work?” try asking “What’s the first thing your new hires will need to do in X software once they log in?”
- Cut down the texting, meet in person – I actually don’t always follow this advice, but I thought it was important to talk about. Some stakeholders prefer to write and have time to outline all their thoughts, while others tend to “verbally process,” and prefer a meeting to get things done. Because of this, I typically email the stakeholder first to introduce myself and let them know I’ll be working with them. Then I’ll ask whether they prefer to start an email chain or schedule a meeting.
- Prepare some first date topics – I cannot stress enough how important it is to do research ahead of time where possible. When you come to a Discovery meeting with an idea of the problem already, you impress your stakeholders and save you all a lot of time. “Research” could mean anything from watching a demo video on how to use a software, to asking around the office to gauge how learners feel about a new sales strategy.
- Up your listening game – This one is pretty obvious: our job depends on being able to listen, and sort of Sherlock our way into a corporate solution by virtue of context clues and follow-up questions.
- Follow up – Always remember to do this! It’s always nice to thank stakeholders for their time, and it comes with the added bonus of being able to send along your meeting notes. You can even require a sign-off. This ensures that everyone on the project is on the same page, and you have “proof” of your discussion, just in case someone tries to insist that you promised them a three-week classroom course in four days. Not that that’s ever happened to me, of course.
Be Coy- Everything in Moderation
“After this whirlwind meeting, you want a module completed in two weeks? You mad, impetuous thing, you!”
I may not have needed these extremely-outdated 13 Secrets to Win His Heart, but I certainly could brush up on a few of these tips:
- Let him win you over – I’m wincing just a little as I read that, but okay… This isn’t a bad idea for an Instructional Designer, though. When I hear that someone wants to meet with me on a “training initiative,” I always take the phrase with a grain of salt. This loops back around to making sure I’ve done my research ahead of time, and can ask all the right questions. After all, if employees aren’t using Software X because a piece of it is broken, or there’s a pervasive attitude about Software X slowing down sales, then simply creating a training won’t fix the problems my stakeholders are seeing.
- Give positive reinforcement – People’s egos are… tricky. Over the years, I’ve learned a little bit about couching my arguments. Instead of saying something like “Sorry, there’s no way that just a video is going to work for this training- we’d need more content,” try something like, “Yeah, thanks for that great suggestion! And perhaps we could pair the video with some other strategies…” This accomplishes the goal of introducing more than just a video, while hopefully making your stakeholder feel heard and appreciated.
- Maintain some mystery – I used to give stakeholders a little peak behind the curtain of instructional design work, and let them know why I’m asking them all these questions. However, I’ve learned to keep quiet about some of the finer points of curriculum development for a few reasons: they’re rarely interested in the process (that’s why the hired me to do it, after all!), the nature of projects can change quickly (I hate having to eat my words when a deadline shifts), and sometimes it’s good to give yourself some extra breathing room (I always build in more review time than I actually need, so that my reviewers have time to procrastinate before they get back to me)
- Plant the seed for the second date (or meeting) – I end every Discovery meeting by outlining my plan for the next few steps. It’s important to emphasize the fact that this is a process: I don’t want my stakeholders getting the impression that they can just order a training from me and be done with it. I’ll need their involvement, and that comes in the form of several reviews and possibly some resources regarding their subject matter experts and test accounts.
- Politely decline his advances – Okay, uh… Geez, I warned you when I said these articles were gonna be bad. But for stakeholders, the article does actually have a point. Like I mentioned earlier, these people are often far, far too busy. They’re corporate heads and project managers, and they will push you to give them an estimate on when this project can be completed. Don’t do it! The majority of the time I dive into a project, I find out that there’s more to it than I was led to believe. It’s the nature of a corporation: unless you deal in a process or software every day, you’re not going to be aware of every single detail that needs to be trained. Because of this, whenever possible, I avoid committing to a deadline. My go-to line is usually something like “I’ll be able to get you an estimate in a few days after I’ve gone through the materials you’ve provided to me” and I find it works most of the time. If you’ve got a particularly demanding client, then at the very least you should estimate extra time than you actually think you need: under-promise, over-deliver and all that. If I think a project will take me a week, I’ll usually estimate two if I’ve had no time to sort through the raw materials.
I may be sick of dating advice this month, but it’s always good to revisit my meeting skills. Hopefully this helps you charm your company and sweet-talk your SMEs as you navigate your “first date” for many training projects to come!
