I recently saw a tweet from presentation professional Richard Mulholland saying:
DO NOT PRESENT ON MICROSOFT TEAMS!
Seriously (and ironically), it was designed by people that don't understand presenting.
Now, I don't happen to have a dog in that hunt. I don't use Microsoft Teams and as I often point out, my business and expertise is not related to peer-level web meetings. But I can empathize with Richard's frustration when it comes to presentation-oriented webinar technologies overall.
My colleague Nolan Haims likes telling a story about the time he asked me for a webinar platform recommendation and I grumpily said, "It doesn't matter. They're all awful." I don't find it as funny as he did. It makes me sad. We deserve better.
When I think about the utility of a webinar technology, I think about every aspect of managing and delivering a webinar. Scheduling events, customizing and branding, managing presentation materials, the presenter experience, the attendee experience, audio and video quality, recordings, reporting and analytics, and integration with other systems.
Those are a lot of moving parts, and it takes teams of experienced programmers to write, test, and maintain the software that runs it all. Then they have to figure out ways to make it work on multiple operating systems, hardware devices, and web browsers… All of which keep getting updated on a random basis. The coding teams have a particular area of expertise.
It's coding. Not webinar management. Not the art and science of presentation. Their day to day job requirements do not include administering and delivering webinars. So what typically happens is that individual functions get added, removed, and revised in piecemeal fashion as a product suggestion is made or a bug gets identified and fixed. A programmer gets assigned a task, concentrates on fulfilling the needs as narrowly defined, and moves on to something else. Over time, the system becomes a "Frankenstein's Monster" of discordant elements that can be said to work, but require ever more care on the host or presenter's part to manage and use in the exact fashion that the software demands. Rather than the program adapting to the needs of the user, the user has to adapt to the needs of the program.
"This is all so abstract, Ken. Can you give us some illustrative examples?" I certainly can. I'm going to mention a few product names in order to be specific, which is going to be unfair to those companies. I could find something similar in EVERY web conferencing product on the market. These are just unlucky enough to be ones I remember having to deal with the most recently, and neither you nor I have time to go through a comprehensive list that includes every product in existence.
Example 1) In GoToWebinar, you can copy a past webinar to use as the basis for creating a new upcoming event. Great! You give your new webinar a title, date, and time. Up pops a screen asking if you want to copy over the same hosts and panelists (or a subset of them). That saves time from having to re-enter their names and emails, so you click YES. The system immediately sends them their invitation emails. After which, you move on to the screen where you can customize the emails that go out. For instance, to update the subject line you had customized in the source webinar specifically for the previous topic and date. But it's too late... Your panelists have already received an email with the wrong (old) custom text. It's a simple workflow issue. Just change the order of those two operations. Nobody on the programming team administers and customizes bunches of webinars for their organization, so they think about the individual pieces of functionality instead of the overall workflow.
Example 2) In BigMarker, you can assign webinars a "category" label. The system has the ability to generate a link showing all upcoming and/or past events in a particular category. Great functionality! I could have events for employees, for customers, for partners, and for suppliers under the same account and just drive people to the link with the webinars that are appropriate for them. BUT, the programmers added a non-defeatable selector on the category page that lets visitors select other categories to see what shows up under those labels. I understand the situations where it would be useful. Maybe a college listing courses in different subject areas would like people to be able to browse around and see what is available in each area of study. But in my corporate example, it means customers can see the webinars intended for employees. Not good. The programmers didn't consider that use case. "As long as they operate the way we were intending when we coded this, there's no problem."
Example 3) In Webex, you can get a report on all the people who attended your webinar. First Name, Last Name, and Email show up in some of the early spreadsheet columns. Then there is a lot of other statistical information spread across 15 columns, followed by the rest of the registration information you collected for each person (such as address, phone, etc). When business stakeholders review the information, they want all those identifying fields grouped together for ease of reference. It's a small thing, but an inconvenience for easy utility of the data. Then there's a column showing the amount of time each person spent in session. It's a text field saying "7.0 mins" or "1.0 min" - You can't sum them or do any statistical analysis unless you do two separate search and replace actions and convert the data to numbers. Why is it important to be able to sum? Because the report shows a new row for each person every time they disconnect and rejoin the session. There is no way to get an automatic summary of one record per attendee showing their earliest join and latest leave with the total time spent in session. All that has to be done by hand, looking for duplicate entries and massaging the data for that attendee. It takes forever. The person who programmed the report is perfectly happy... "All the data is there!" They just never had to USE it for a business purpose, so they saw no reason to make it more practical and analysis-friendly.
Give me a couple of real sessions with your webinar product and I'll find something similar in it. Maybe it's as trivial as a language selector listing all the languages in English (why would a person who speaks Hebrew look for the word "Hebrew" rather than "עִברִית")? None of the things I have listed are bugs. They all work exactly as designed. It's just that the design limitations and inconveniences are difficult to understand and appreciate except by people who have to use the product over and over.
There's an old adage in systems development. It says "Go ahead and code your application. Give it some time. Then when you figure out how it was supposed to work, go back and rewrite a system from scratch that does that." It's not really meant literally, because nobody has the time or money to operate that way. There are also plenty of practical considerations when making operational changes to a complex product - updating your own training and support documents, informing existing customers that they need to update their instructional documents, updating macros and API integrations that rely on things working a certain way... It's not trivial.
But the adage is a pointer to a larger conceptual issue in complex systems such as webinar platforms... At some point, people who administer and deliver lots of webinars need to step back and look at overall workflows and different use cases to ask whether the product makes business tasks convenient and logical for business users rather than just supplying a bunch of individual islands of functionality that work within their rigid and carefully prescribed operating parameters. Fixing bugs is all well and good (and VERY necessary!). But I long for more attention to be paid to practicality in support of the business users who have to interact with the software on a frequent basis.
