The Longest Game of Telephone
I’ve uncovered a metaphor that expresses feelings amassed since my first professional experience: program management is the longest, most labyrinthine game of telephone ever invented.
In this article, I attempt to explain how I’ve come to this metaphor and offer a cautionary tale that helped elevate it from a subconscious purr to a neon, pulsating warning sign. I also provide some ideas for how you can steer clear of the pitfalls, but please know that I am not the inventor of these ideas! None of them is new or unique. They’re perhaps just new ways to express that bringing customers and product teams together will create more innovative and useful products.
But before I get to solutions, let me tell you a brief story about a project that ended in heartache instead of joy (or even relief).
A Cautionary Tale
Back in the aughts, I led a project that integrated a content management system (CMS) into an e-commerce website. This system slashed the time needed to update our site by giving publishing tools to our content team. By all standard measures, the project was a success! The CMS launched on time, met requirements, and was within budget—but my project’s sponsor was not happy.
It was a rough experience. There are words you never want to hear at the end of a project, and he sure as heck said them. I was surprised and immediately pinballed through the five stages of grief, but understood he felt the CMS didn’t meet his expectations. With an awkward lump in my throat, I pleaded and explained that we built the product just as he requested. But he stood firm, “Unacceptable,” he said. With hindsight, I should have seen it coming.
Months earlier, he helped us create requirements, assess competing CMS products against them, and select the final vendor. The project's next stage was to design the implementation to fit his team’s needs and then integrate the CMS into our site. But before we started, his availability evaporated; he couldn’t collaborate because he had more urgent work.
It felt like he budgeted a ton of money to remodel his kitchen and bathrooms but could not find time to ensure they’d meet his family’s needs. Those are essential rooms! Thankfully, he assigned his most trusted teammate to join the project, represent his team, and make decisions. His proxy would consult the sponsor for risky or significant decisions and return his answers. This plan seemed like an adequate solution, but had I been more experienced, or had I known the outcome, I’d have pushed harder for more direct participation.
In the best of times, communication ain’t easy! Even with an active sponsor, we could capture requirements incorrectly or misinterpret designs, and build an imperfect product. Hell, we could capture requirements perfectly and create the product to satisfy them, but the solution may still not satisfy the customer because we addressed the wrong problems. However, passing messages through an intermediary raised the risk of miscommunication. Was I naive to assume a substitute could understand and represent my sponsor’s expectations?
Due to system capabilities and limitations, hundreds of decisions shaped the final product. While his surrogate understood the logic behind them, the sponsor could not. Even though the product satisfied his proxy and met his documented requirements, there was a gap between the product my sponsor envisioned and what he received. I’d be frustrated, too!
It’s been a long time since that project. I’ve experienced many new project bruises and successes, yet this project has stuck with me as a defining moment for what it continues to teach. Scope, time, and budget are important project considerations, but without sufficient focus on people, communication, and empathy, projects will devolve into the longest, most labyrinthine game of telephone ever invented.
What do I mean by "Game of Telephone?"
... an internationally popular children's game in which messages are whispered from person to person and then the original and final messages are compared … Although the objective is to pass the message uncorrupted, part of the fun (gasp!) is the corruption that happens. Errors accumulate, so the statement announced by the last player ain’t the same as the first. - Wikipedia
FWIW - World Record Games of Telephone
In 2008, 1,330 children and celebrities set a Guinness world record for Telephone. The opening statement was, "Together we will make a world of difference," which became "We're setting a record!" midway, and simply "haaaaaaaaaaaaaaaaaaa" by the end!
A new record was set in 2017 by 1,792 people. This game started with the statement, “Turn it down,” but I’ve found no record of the final statement announced by the last player—perhaps they succeeded?
How on earth is Telephone related to Project Management?
I’ve read that comedy equals tragedy plus distance. Enough people have experienced project communication breakdowns that result in calamity that a meme has retained relevance since the 70’s! People turned the miscommunication between a customer and project team members into a comic strip.
To Understand Telephone, Understand Communication
At its most simple, communication occurs in person between just two people. One person attempts to send a message, the other receives it, but noise is eager to interfere. Physical distractions and physiological limitations make it difficult to hear or focus. Unfamiliar words or field-specific jargon can make a message unintelligible, thus reducing understanding.
Why not throw in some social dynamics? Individuals can feel pressure to adjust to perceived expectations that influence their feelings toward a message or messenger. Additionally, each individual’s knowledge of the subject matter and skill at sending and receiving messages impacts success. Furthermore, receiving ain’t just receiving because the recipient responds in real-time through body language (or instant messages!) that influences the sender, who reshapes and resends their message.
Between just two people, so much is involved that it becomes hard to imagine gaps not forming between what the sender intends to express and what the recipient interprets the message to be.
In my CMS experience, genuine care would need to be taken between the project sponsor and me to mitigate the risk of misunderstanding. However, introducing an envoy injected an additional node for messages to pass through, expanding the distance between us and doubling the number of messages needed to transfer information. Let the games begin!
But a project ain’t just two (or even three) people!
Projects have dozens of participants actively communicating within the project team. There are even more people outside the team who influence them. Messages are sent in conference rooms and hallways through dialogue and facial expressions. They’re sent across continents and time zones via Zoom, Slack, and email. Messages are translated into charters, requirements, and designs one month and deciphered by new teammates months later. Sometimes the authors move on to new projects, leaving a new group to determine their intent. Each interaction adheres to the same communication principles (noise, social dynamics, skill, etc.) and is ripe for unwitting mischief!
The pristine idea that kicks off the project will be interpreted, modified, and refined by all participants over weeks, months, or years and eventually built into the product delivered at the end. This is what I mean by the world’s longest and most labyrinthine game of telephone. It takes a lot of time and effort to keep a project’s communication focused and flawless—if that’s even possible.
TL;DR - What can be done about it?
Reduce the distance your messages must travel!
There’s physical distance between the customer and team, temporal distance between initial product inspiration and delivery, and conceptual distance between what the customer says they want and what would genuinely delight them. Find ways to reduce each of these distances!
Accept No Customer Substitutes!
Open and maintain a dialog between your customers and the people who work hard to build the products they need.
In the three major sections below (Physical, Temporal, and Conceptual Distances), I cover different ways to do this, starting with the most obvious takeaway from my CMS experience ...
Close the physical distance between Project Team and Customer
If my CMS Sponsor collaborated closely with me and the project team, our messages would not have been filtered and delayed through a proxy. We’d have had more opportunities to determine if we understood each other and could correct miscommunication sooner. Additionally, he would have influenced all decisions directly, had more control over the shape of the product, and would have been happier with the product we delivered.
But why stop there? In many projects, the sponsor is merely an internal stakeholder who advocates for real customers outside. Sometimes, a project will have several stakeholders representing the interests of external customers. Internal stakeholders are not the same external customers! While having champions for the customer is invaluable, accept no substitute for direct customer participation! Doing so will risk recreating my painful CMS experience.
Customer Shadowing
Shadow your customers as they work to accomplish their goals. Their body language (joy and frustration) will provide insight into unspoken experiences customers may not realize can be improved. These insights can lead to questions the project team may not have thought to ask and fresh responses the customer didn’t know they had in them.
Put yourself in their shoes
Perform your customer’s job for a day or two. This will help generate a deeper understanding of your customer’s frustrations because you will experience them yourself. The joy or suffering from doing the job, the body language, and facial expressions will be your own. You’ll find greater empathy for your customer, and with your technological knowledge and skill, invent creative new ways to improve their experience.
Meet in person!
I know this is potentially controversial (indeed more complex) in our post-COVID world. Still, it’s the most efficient way to communicate ideas.
Through nonverbal cues, you’ll more easily determine if your messages are understood and can improve them in real-time. You can read a room and pick up on the unspoken social cues, emotions, and the attention of all attendees. Interpreting the absorption of information improves as you shift from email to Zoom and then to face-to-face because there are more cues to pick up on and fewer distractions. The inverse is also true—identifying miscommunication becomes increasingly tricky as you shift from in-person communication to Zoom and then email because of increased noise and fewer social signals.
Close the temporal gap between product inspiration and delivery
Let’s face it: projects take time. What a customer wants in January may not satisfy them in July. When I think back to my early CMS experience, it’s possible that the sponsor clearly expressed his expectations, and we captured them accurately! Perhaps we integrated the CMS precisely as intended. If we delivered it to him right then, the day he approved the designs, he may have been thrilled because we got him what he asked for when he asked for it. But we didn’t. It took time for us to pull it all together.
In the time it took us to build and test the CMS, much could have changed around us. New content technologies could have landed that altered the meaning of industry-leading CMS. The sponsor could have learned important new information that influenced his vision for the product.
Has his expectations changed? Certainly! Should he scale back his new expectations to meet documented requirements? Absolutely not! If the market has changed, then so must the direction of the product.
I now try to remember that when projects deliver products to customers, those products—not our vision statements or requirements documents—communicate our vision to the world. Because traditional projects can take months or years, the original visionary idea that sparked a project may no longer be revolutionary (or even relevant) and may inadvertently communicate indifference to customer needs. What can be done about it?
Break large projects up into smaller ones!
Instead of a 12-month project with ten features, run a 6-month project with five, or a 3-month project with (ahem) two and a half features! Okay, I’m unsure about the fractional features, but I hope you catch my drift!
At the end of 12 months, you’ll still deliver all ten features and get customer feedback in a fraction of the time. Early feedback will help improve collaboration and allow you to pivot your direction to meet customers where they are. Not to mention that customers would benefit from your hard work much sooner. Even if you don’t deploy the entire product until the end of the planned 12 months, invaluable input and fresh ideas will help your product steer clear of irrelevance.
Deliver features incrementally throughout the lifecycle of the project
This is just a logical continuation of the petite project idea above. The slimmer the deployments to production and the more frequent the feedback from your customers, the quicker you, your team, and your customer will find out if you’re all in sync.
领英推荐
Provide Your Customers Mockups!
If your project must be lengthy and linear, lavish your patrons with prototypes! A quick drawing enables your customer to visualize your understanding of their problems and can bridge the gap between conceptual solutions and the final product.
For particularly risky or long projects, provide increasingly detailed and interactive prototypes as the project progresses: they’re far less expensive to create and more easily modified than complete products, so take advantage of them!
In a world flush with dense technical jargon too hieroglyphic for clientele eyes, a picture’s worth a thousand words! Or, as my mom says, “Keep it simple, stupid!”
Better yet, have customers provide you with mockups!
Speaking of pictures, why not have your customers sketch their vision for the product? Doing so will make them translate the ideas they hold in their heads into physical or digital drawings in the real world. Their sketches would offer fresh insight into their unspoken assumptions, the problems they’re looking to solve, and how they value and prioritize them. It could inspire new questions and conversations that inform how your team attacks customer problems and how you spend valuable project time. If customers are uncomfortable sketching themselves, have someone on your team draw with them.
Close the Conceptual Gap between expressed need and real need
We’re imperfect. Though we’ve trained all our lives to be wise, to synthesize complex information, and to make good choices—we make mistakes! But this isn’t our fault. Cognitive scientists believe that mental models (internal representations of external reality) and biases (like anchoring and confirmation bias) may explain the intrinsic flaws in our decision-making. While it’s enlightening to noodle on such philosophies, for us time-pressed mortals, it’s simply helpful to acknowledge that we are human, biased, and jump too quickly to conclusions.
No decision is safe from distortion, so our biases infiltrate all phases of our projects. But because the initial product inspiration influences all downstream choices, the most impactful decision made in product development is what product to develop in the first place.
If you’ve already improved collaboration and sliced your projects into bite-sized (but meaningful) chunks, this will be less of an issue because you you'll discover problems early and can change course. However, there are still opportunities to improve your understanding of your customer’s needs.
Organizations with lengthy linear projects are at a slight disadvantage. Starting off on the right track is crucial for them because, once that project train is rollin’, it’s hard to switch tracks. When a project manager or team joins a project, the “Aha!” moment has already happened. The sponsor has decided the problem that needs to be solved and the solution for that problem, and just wants the solution delivered. But if the sponsor didn’t identify the root cause of their customer’s pain, even if built perfectly, the product will only fix symptoms. The sponsor and customers will remain unsatisfied, and the project team will be frustrated because the product they poured their hearts into could become a pricey doorstop.
As uncomfortable as it may feel, the best time to ensure the product will satisfy customers is before the project is kicked off. Doing so will help prevent the discomfort of realizing that the product you’ve released is “unacceptable.”
Design is seeing something that we want to be better and then the activity of making it better. It usually starts with someone seeing a problem. But it's up to that first conversation to ask, “Does the problem, as stated, represent the problem we should observe?”
It's just like in medicine: I may go to a doctor and say I have pain here. The doctor may realize the problem isn't here, the problem's over there. It's the design conversation's responsibility to diagnose.
Begin from where the user is and understand human needs through a kind of ethnography and observation. Then, brainstorm and diverge and understand what all the possibilities might be. Paul Pangaro
Ask the customer why they want a solution, not what solution they want
And then ask “Why?” a few more times for good measure. I know this sounds basic, but you’d be surprised how easily this step is overlooked and how valuable it can be.
Thinking back to my Content Management System project, I suspect I never asked, “Why do you want a CMS? What problem do you want to solve?" I didn’t because I thought I knew the answer and was too embarrassed to ask an annoying question.
Sometimes, when you ask, "Why?" you're a bit of a troublemaker. The question, "What?" is an acceptable question, but "Why?" is a much tougher question to answer. - Dan Formosa
But if I had asked, “Why do you want a content management system?” do you know what he could have said? “Because the current CMS requires the dev team to publish our content.” That answer opens the door to solutions that wouldn’t require a brand-new CMS. If I followed that up with other questions like, “Why is it a problem for the dev team to publish content for you?” or “Is there anything else about the current CMS you don’t like?” I could have learned valuable insights into the root causes of my sponsor’s pain that would have changed the direction we took.
Around 12 minutes into the Design & Thinking documentary, Sara Beckman provides an example of how asking "Why?" can help identify the root cause of a problem and lead to more interesting solutions. Inspired by Plato and Columbo (Platumbo?), I've taken the liberty of converting her concise phrasing into a slightly more playful, if wordy, dialog:
CUSTOMER: Hey, thanks for joining the team. I’m sure you’ve heard we’d like you to build us a bridge?
PROJECT LEAD: I have, and we can indeed build you a bridge. We can build you a cantilever bridge, an arch bridge, a suspension bridge, or even a covered bridge, you know, so you don’t get wet.
CUSTOMER: Dry sounds nice.
PROJECT LEAD: In fact, there's a whole lot of different types of bridges we can build you. Would you mind my asking, why do you want bridge?
CUSTOMER: So we can get across the Bay.
PROJECT LEAD: Ah, that sounds advantageous … but I hope you don’t mind my saying there are many ways to do that. You could swim, joking, of course. But we can get you a boat or an airplane or build a tunnel, and of course, we can build you a bridge.
CUSTOMER: I hadn’t thought about those other options.
PROJECT LEAD: I see. You know, each of those options has its tradeoffs—different costs.
CUSTOMER: Sure.
PROJECT LEAD: And each of those options is divided into, well, its own options.
CUSTOMER: How do you mean?
PROJECT LEAD: Take boats, for instance, there’s so many types! There’s single hulls, catamarans, and trimarans …
CUSTOMER: Oh.
PROJECT LEAD: There’s sailboats, motorboats, schooners, skiffs, and skipjacks …
CUSTOMER: mm-hmm
PROJECT LEAD: There’s dinghies and kayaks, canoes, barges, and deck boats!
CUSTOMER: Okay.
PROJECT LEAD: You know, hovercraft can be a boat when they want to!
CUSTOMER: I was thinking, a bridge just seems more straightforward.
PROJECT LEAD: Of course, bridges are a great way to get places! But now you’ve got me curious: why do you want to get across the Bay?
CUSTOMER: So we can send messages to our friends over there!
PROJECT LEAD: Ahhhh, it’s funny, isn’t it? The more I ask, the more confused I get.
"If you want to have a great idea, have lots of ideas!"
I’ve seen this quote attributed to Thomas Edison, a foundational and prolific inventor, Linus Pauling, a founder of quantum chemistry and molecular biology, and most recently David M. Kelley, a founder of IDEO and Professor of Product Design at Stanford.
If you want to have a great idea, have lots of ideas. So we have a brainstorm and come up with one hundred ideas in ten minutes. David Kelley
For our product development purposes, ideas are either problems we can solve or solutions to those problems. This quote implies that limiting the set of ideas you draw from reduces the likelihood of finding a great idea. Naturally, this limitation will increase the chance of choosing a mediocre or crummy one. I suspect most people agree with this statement but hesitate to share a wild idea or two for fear of what others might think and restrict the floodgates for fear of the time it could take to filter through them.
We tend to self-regulate. We limit ourselves to sharing only those problems we believe are fixable and ideas we think are socially acceptable. So, we keep many ideas bottled up inside. But thinking a problem is impossible or a solution is socially unacceptable does not make it unsolvable or unworthy of consideration—but keeping it bottled up certainly does.
In my CMS example above, the Sponsor likely thought that because the existing system couldn’t publish, he needed to replace the whole thing with one that could. Had he posed that problem to an engineer, she might have offered an inexpensive solution that allowed him to keep his existing CMS … AND publish!?
Bringing two people together from different fields offers a broader range of experiences and perspectives, leading to more innovative solutions than would have been possible alone. Two heads are better than one!
What if we brought people together from additional fields and backgrounds, gathered an interdisciplinary crew of customers, product managers, product developers, user experience designers, etc., and hosted a collaborative brainstorming session? We’d generate a deep and diverse group of ideas to select from and increase the likelihood of finding a gem! In addition to developing better ideas, these cross-functional sessions could help customers and teammates learn from each other and improve communication.
If you’re worried that brainstorming sessions would be too large and unwieldy, break them into smaller cross-functional groups and set tight time constraints. The first meeting could focus solely on dreaming up problems to solve and prioritizing them, while the second would spotlight solutions to the highest-value issues. In a couple of hours per group, you’d overflow with ideas your customers and team would find valuable and feasible to build. For more on how to do this, look into creative design thinking exercises or hire an expert to train your teams in design thinking theory and practices.
In conclusion, cut the distances!
The Game of Telephone is funny and enlightening, but the inevitable corruption of messages is not worth recreating on customer-focused project teams. Predicting customer expectations is challenging enough; why introduce unnecessary physical, conceptual, and temporal communication barriers?
Instead, find ways to reduce the distance between your customers and teammates. I’ve provided a few ideas you can try—meet directly with customers, understand why they want a product or solution, and reduce the delay from idea to product—but I’m sure you can find methods that best fit your organization’s culture. I’d love to hear them.
References, Influences, and final thoughts
I did not invent any of these ideas! I’m just a tech worker who’s spent enough time in the project management profession to have lived through the shift from traditional project practices to more “agile” ones and back again! I’ve also found that it’s vital to keep learning in this mutable landscape.?
As such, I plucked all of these ideas from the project management and agile training I’ve received, the talented people I’ve worked with, and the projects and teams I’ve been part of. But I’ve also learned from the parallel fields that project management and agile influence and borrow from, especially those that remind me to focus on people and interactions more than methodologies.
I was not the first to find this metaphor!
In fact, it’s rather popular. Here are a few other articles that express the same metaphor from fresh perspectives, with similar and different solutions:
Enabling Growth Through UX & AI | Building Precious | Ex-Google Policy Specialist | Ex-Lawyer
1 年Love the analogy of the longest game of telephone! Excited to dive into the read. Mo Berry