Sunday, December 7, 2008

Product Demos: Connecting With Your Audience

This question was posed on one of my LinkedIn groups: How do you create and deliver effective product demos? Specifically, how do you connect your solutions and benefits to the needs of C-level and V-level buyers.

Good question. Here's what I recommended:

  1. As with any audience, you need to understand where they are coming from on an emotional level. What are their pain points? Why are they so painful? Or, conversely, what are their dearest wishes? And what does your product or service do either to cure the pain or provide the emotional payoff behind the wish?

    It can take some hard thinking to connect your offering to this emotional level, but assuming your offering is of real value to the buyer, the connection is there somewhere. You need to put yourself in the audience's head and keep asking the question: "Why should I care?"

  2. Design your demos around one or more stories that concretely show how you cure the pain or provide the emotional payoff. If you have actual customer success stories you can use, so much the better. But cast these as a personal story. Describe the buyer and their problem. Imagine their joy and relief when the problem was solved. Then write the story and build your demo around it.

    To make this more scientific, you might want to create several stories and test each one to see what gives the best results--the best connection and response from your audience.

  3. As far as delivering the demo (and this assumes you are delivering it in person, not doing a webinar or building an on-demand demo), there is a good article in the November 2008 Harvard Business Review called "How to Become an Authentic Speaker." Takeaways: rather than practicing speaking tone and gestures, the speaker should practice being open to the audience and feeling passionate about the subject.

What do you think? What makes a demo work?

Wednesday, October 29, 2008

Best Practices for Synchronous E-Learning

Here's another topic I've been researching for a client. They use primarily classroom delivery today, but are needing to move to a synchronous model using WebEx. They are a software company and this is primarily for product training for customers.

Here's what I've come up with so far.

Best practices for using tools such as WebEx are still evolving in the training industry. But experts and practitioners agree that (compared to classroom training) “live e-learning” demands different strategies and tactics to effectively engage learners and produce results.
  • Research shows that effective live e-learning sessions run no longer than 90 minutes maximum, with a one-hour maximum preferred.

  • Since instructors cannot gauge participant attention by facial expressions or body language, they should request feedback frequently. One guideline recommends requiring some participant interaction every 3 to 5 minutes.

  • Methods for making the virtual classroom interactive include:

    · Use chat and polling functions (available in WebEx)

    · Allow participants to take control of the session, for example to drive an application demo

    · For practice exercises that are done between sessions, provide a simple web form for entering answers and submitting them to the instructor

  • The WebEx Training Center platform provides additional specialized tools, such as a whiteboard, breakout sessions and access to remote lab computers.

Now, all of these methods require that the curriculum design be modified for online delivery, and that instructors learn and practice the new delivery tools and techniques. Achieving the best results would be an iterative process.

My current recommendation to the client: The degree to which you need to investigate these best practices depends on the learning goals. If simply presenting the current curriculum via WebEx proves sufficient, that is certainly the easiest route. However, if this proves insufficient for effectively training customers, then these other approaches need to be explored.

Agree? Disagree? Other best practices to share?

Saturday, September 13, 2008

The missing span - why user documentation often fails

This week I attended a Technology Association of Georgia Product Management SIG meeting this week. John Mansour of ZigZag Marketing did a presentation about using documented requirements through all phases of the product development cycle. John is a product management expert, and his company has a comprehensive framework for analyzing market needs and responding with well-considered technology solutions.

One of the requirements phases in the framework is the User Phase, which, John noted, is often given inadequate coverage or even skipped entirely. In this stage you create user stories and extend them into detailed "what if" scenarios. All of these must be documented and validated in order to design usable interactions. The analysis yields detailed and tested Functional Specifications that can be handed off to Development.

The fact that few companies take the time for this level of user analysis explains why so many products either don't solve user problems (poor "usefulness") or fail because they're too hard to learn and use (poor "usability").

It also explains why user documentation often fails. Lacking adequate user scenarios, technical writers typically create their deliverables from specifications and beta interfaces. They document how a product works, but not why. They explain how to perform tasks in an interface, but not when a user might need to do those tasks. They describe user options in abstract or generic terms, but don't help the user decide which option to choose.

A client I'm working for now is a good example. The technical writer has done a very good job of explaining the components of the interface, but nothing about how they relate to users' real world business problems. The data is described as a developer might understand it, but not in terms of what users need to do with it. As a result, the user guide is essentially useless in teaching me what I need to know to create user training.

When I asked the subject matter expert about this, she said: "The user doc explains what's there but not why you'd use it. That's what the training has to get across."

When was the last time you learned a new software tool just by reading the user manual or help?

Another illustration: I remember hearing a quote from a manager responsible for a popular income tax software product. In regard to the product's help, she said "My problem is not teaching people how to use the software, it's teaching people how to think like accountants." In other words, the help needed to impart domain knowledge, to assist users in knowing which options they needed to choose.

For many years we've been hearing that user manuals and help are miserable, that they "don't really help people." I think this is the biggest reason why. I see real world examples and domain knowledge as the missing span in most user documentation.

So what's the fix? More on this in a later post.

Tuesday, September 2, 2008

Achieving Good Flow in Your Writing and Speaking

To promote my coaching practice, I write occasional articles on general business communication issues. How to write effective emails, how to give good presentations, and so on. I whimsically call these "Thoth's Tips", after the Egyptian god of scribes and wisdom.

I've just posted a new Thoth's Tip on my website. The subject is how to achieve good flow in written and spoken communication. Flow may be a mysterious quality, but Thoth does have a few suggestions on how to make flow your friend.

Monday, August 25, 2008

Notes on Blended Learning - Part 2

As noted in my previous post, when you design a training course to solve a business problem, you might consider three different delivery methods:
  1. onsite, classroom training
  2. instructor-led web-based training (aka "webinar" or "synchronous e-learning")
  3. self-paced web-based training (aka "tutorial" or "asynchronous e-learning")
Or you might choose a combination of the three; that is, a blended learning approach.

First, here is my take on the pros and cons of the three methods:


  • simplest and cheapest to develop
  • allows immediate student feedback and questions
  • instructor can easily gauge learning
  • content easily updated
  • requires scheduled time away from the job
  • requires dedicated instructor time
  • success depends on the instructor's skill
  • cost of maintaining an in-house classroom or hiring one offsite
  • travel costs for instructor and/or students
Instructor-Led Web Training

  • relatively simple and cheap to develop
  • some (limited) facility for immediate student feedback/questions
  • can be recorded and archived for reuse
  • scales better than Classroom training for large audiences
  • content easily updated
  • requires adequate technical infrastructure (computers, broadband, headphones)
  • technology can be unreliable
  • requires scheduled student and instructor time
  • success depends on the skill of the instructor (more difficult to deliver well than classroom)difficult to judge student engagement and learning
  • if students work from their desks they may multitask and lose attention
  • often less interactive and engaging than classroom or well-designed self-paced training
Self-Paced Web Training

  • available anywhere/anytime
  • learners can learn and review at their own pace
  • always available to review
  • scales well to unlimited audience size
  • most difficult and expensive to develop
  • cannot immediately answer student questions or measure effectiveness
  • content difficult and costly to update
Blended Approaches

All of that said, there are certainly opportunities to combine two or three of the approaches for business training. A few examples:
  • Create a self-paced web tutorial as precursor training for a classroom course. This allows the learners to preview the content and help ensure everyone is up-to-speed when the class begins.
  • Combine a self-paced web training course with a monitored forum or wiki. Encourage learners to post discussion, questions or feedback and an instructor to monitor and provide answers.
  • Begin a series of instructor-led web training sessions with a single classroom session. This can built engagement by allowing everyone to meet face to face and help the instructor gauge the knowledge level of participants.

What pros and cons do you see in the three delivery methods? What examples of blended approaches have you found to be effective?

Tuesday, August 19, 2008

Notes on Blended Learning - Part 1

After you've recognized that training is needed to solve a business problem, how do you decide on the delivery method? How do you choose whether you should deliver instruction by:

  • onsite, classroom training
  • self-paced web-based training (aka "tutorial" or "asynchronous e-learning")
  • instructor-led web-based training (aka "webinar" or "synchronous e-learning"
  • some combination of the above ("blended learning")

Following up on my previous post on heuristics, I would love to be able to formulate simple guidelines for this, but it is not a simple problem.


From the reading I've done on this lately, it's obvious that choosing the best delivery method depends on a lot of factors:

  • Learner preferences - Are the learners comfortable with online instruction? Can they learn effectively using self-paced training?
  • Resources - Are qualified instructors available for instructor-led training? Are qualified design and production resources available for self-paced e-learning?
  • Instructor preferences - Are instructors comfortable and experienced with e-learning?
  • Scheduling - Is there adequate time to develop self-paced e-learning? Conversely, is there time in learners' schedules for them to attend instructor-led classes?
  • Technical infrastructure - Is there sufficient equipment and bandwidth for synchronous e-learning. Is the equipment reliable? Are support people available if needed?
  • Budget - Self-paced e-learning is usually the most costly to develop. But weigh this against the cost of learners' lost job-time for attending instructor-led training.

More to Come

All of that said, I think there are pros and cons that can be stated for each approach. And sometimes, by blending the delivery methods, a skillful designer can make the most of the advantages and minimize the drawbacks.

More on this in my next post.

Friday, August 15, 2008

How the Wiki Was Won

Yesterday I attended a meeting of the Atlanta chapter of STC (Society for Technical Communication). The presentation was a case study about using a wiki for knowledge sharing and collaboration at a software company. There was some excellent discussion on tools, processes, pitfalls and workarounds.

You can find my full report here on the Atlanta STC blog.

Tuesday, August 12, 2008

Heuristics: Do you need to present information or provide training?

I am always on the lookout for good heuristics, rules of thumb to help me slice up and sort out communication problems.

When a client calls me because they need to provide "instructions" or "documentation," one of the first questions I need to answer is: Do they need to present information or provide training?

As you might expect, presenting information, while not simple, is a whole boatload simpler than providing training.

  • Presentation requires good information design, structuring of content, and easy-to-use access methods (search, index, browse).
  • Training usually needs all of this, plus more: learning objectives, lesson plans, engaging content design, simulations, practice, evaluation. Training is more complex and costly to develop.

But how do you choose? A splendid set of heuristics is provided by Michael Allen. I highly recommend his book, Michael Allen's Guide to E-Learning (John Wiley & Sons, 2003) to anyone who needs to do any kind of training in the corporate world.

In discussing when to present information vs. when to deliver interactive training, he provides the following decision table (pgs. 278-279 of the paperback edition).

(By the way, if anyone knows a way to format a table in the blogger interface, help me out!)

Choose Presentation When...
Content is readily understood by targeted learners.
Learner differences are minimal.
Errors are harmless.
Information is readily available for later retrieval and reference.
Desired change to existing skill is minor and can be achieved without practice.
Learners can easily differentiate between good and inadequate performance.
Mentorship is inexpensive and will follow.

Choose Interactivity When...
Content is complex and takes considerable thought to comprehend.
Learners are diverse in their ability to understand the content.
Errors are injurious, costly or difficult to remedy.
Information needs to be internalized.
Behavioral changes will require practice.
Learners need guidance to differentiate between good and poor performance.
Mentorship is costly, limited, or unavailable.

There is plenty of great food for thought here, which I may expound on in future posts.

Does anyone have other frameworks for determining when training is needed? Like I said, I am always on the lookout for good heuristics.

Wednesday, August 6, 2008

Not Elevator Speeches, Stories!

My problem with the elevator speech

I've never been comfortable with the idea of the elevator speech. You know, the proverbial dynamic and enticing 30-second description of your business that you give to the hiring CEO you happen to meet on the elevator, and he's ready to hire you by the time you reach the 10th floor.

I've tried to put one together several times and it always comes out sounding canned and worse (because my business is so multi-threaded) confusing.

But...A communication consultant who cannot communicate his value in 50 words or less. Not good!

How I found a solution

So I was delighted and relieved recently when I heard a panel discussion on networking and one of the panelists said she thought the whole elevator speech idea was bogus. "No CEO is going to hire you after hearing a 30-second canned speech," she said. "Doesn't happen."

(I would love to be able to give her name and a link to her site or blog, but I confess I neglected to write it down and now can't find it referenced anywhere. I apologize and promise to do better.)

Instead, she said, use stories. Have one or several brief stories ready to explain how you have helped your clients solve their problems.

Brilliant. I'm a big believer in the power of stories for both marketing communication and training, so I thought this was an excellent lesson.

And the very next day...Proof of Concept!

The next morning, I happened to be at another networking meeting. I shook hands with a tall, gray-haired guy who turned out to be a chief marketing officer for an IT consulting firm. He asked what I did and I gave a version my 10-second intro: "I do writing and training development, mostly for technology companies. I specialize in making complex information clear."

Didn't mean much to him, I could tell. So remembering the lady's advice, I launched into a story.

"For example, on a recent assignment I worked with C-level executives of a marketing services company as they were beginning to design their next generation software product. I sat in on their brainstorming sessions, documented everything they said and helped them think through the gaps and inconsistencies. From there I wrote initial customer-facing marketing documents and also requirements and specifications for the engineering team."

His face lit up. Comprehension!

I had told him a story he could relate to and now he had an idea of how my consulting practice adds value.

Stories, such a handy tool. More on stories in future posts.

Tuesday, August 5, 2008

A Mercurial Mind at Work

Setting up this blog was easy; figuring out what to write first was hard.

You see, as a business and technical communication consultant, I work in many disciplines. In the past year alone I've filled the roles of technical writer, documentation architect, business writing coach, instructional designer, e-learning developer, marketing writer and (sorta) product manager.

This is exactly NOT the advice usually given to freelancers and consultants. "Focus your business," the gurus say. "Don't make the mistake of trying to be all things to all people."

I can't help it. I'm a generalist in an age of specialization. I'm just curious and interested in too many things. So every time an intriguing opportunity comes along, I charge after it. A mercurial mind at work.

So I expect this blog will reflect my meandering explorations across many domains: e-learning, instructional design, technical writing, content management, user-experience design, software development, marketing writing. I'll also touch on lessons learned in running a consulting practice and in coaching people to be better communicators. And, I promise to link to interesting writings by thought-leaders in many of these fields (See my blog list at right for starters.)

So stick around, gentle reader, I can promise you this: It will be different every time.