Are You Playing the Telephone Game With Your Customers?
Every family has a collection of “favorite stories.” You know, those things you keep retelling to each other, year after year.
One of ours involves my son. When he was in grade one, he came home from school and recounted the following history of the indigenous people of Canada:
The Native peoples fought against the Germans and won. The Native peoples were the first Franco-Ontarians. The girls spoke French and the boys spoke English, so they taught each other their languages. They started traveling the world, first the girls in kayaks then the boys in ships. They broke the law by speaking French in school. If it wasn’t for the teachers we wouldn’t have school today because the teachers fought to defend the school from the police and the kids defended with pens, erasers, and chalk. The teachers used rulers, and they won.
Yes, in case you’re wondering, we wrote it down, word for word, as he brought us up to speed (we are planning to read this at his wedding, two decades from now).
If you think something might have gotten garbled in the story somewhere along the way, you are right to be suspicious. The grain of truth in that retelling is that there was a great deal of conflict among the English, French and native people of Canada. Native languages and French were not permitted in schools and the right to speak was hard won.
Clearly, if I wanted a proper history lesson, I would be better off talking to his teacher than to my son,or better yet, an actual historian.
And yet this second hand approach, one that has more in common with a game of “telephone” than with true research, is exactly what many product developers often do: Instead of talking to customers directly, we get our information through intermediaries.
Talk to users, not just choosers
A few years ago, I was working on a product for an insurance company. We were very engaged with the executives there (“the choosers”), who told us what they needed. But when I asked if I could speak with some of their insurance agents (“the users”), to help us understand the workflow, I was told, “Oh, well, they aren’t part of this committee.”
So I persisted. “Well, can you introduce me to a few of your agents so that I can reach out directly?”
Turned out that this wasn’t possible either, because … here comes the punchline … no one on the committee knew any agents!
Uh oh. So people who didn’t know any agents were telling a bunch of product managers what kind of products their agents should be using. The product managers then conveyed this information to a bunch of engineers. You see the problem. It wouldn’t take long before we would end up with, “the kids defended the school with pens, erasers, and chalk”.
Fortunately, we were (eventually) able to talk to insurance agents, but only by independently recruiting them. The internal bureaucracy at the customer site made it practically impossible to speak to any of the agents through official channels.
It’s a funny story, but it’s also quite common, particularly in companies with many layers of management and functional specialization. The people using a given product are often far, far away from the people with the authority to sign a $500,000 check.
What’s the solution?
Get as close as you can to the end user before building anything. It’s not always easy, and the value of doing so won’t always be immediately obvious to the “decision makers” in the organization.
But remember, those who don’t learn from grade one history are doomed to repeat it.
Photo credit: Kelly Knox https://www.stocksy.com/493960
