15 Feb

Are You Playing the Telephone Game With Your Customers?

493960

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

01 Feb

3 Big Ideas for B2B Product People: Oleg Mysyk

In most organizations, the people using the technology, buying the technology and developing the technology, don’t tend to communicate frequently (if at all). At times, it feels like an extended game of “telephone,” with the essential elements of the conversation getting garbled along the way.

I sat down with Oleg Mysyk, a Product Manager and leader in application development at Nokia, to gain understanding of how direct observation can overcome these challenges.

Here’s what he told me:

  1. Ask for stories rather than requirements.When talking with customers about their needs, it’s tempting to just ask them for a wish-list — what features would they like most?This approach is sometimes effective, but it has an ugly downside: What happens when a customer’s requests don’t align with your capabilities or roadmap? Now, not only are your customer’s needs unmet, they feel ignored, too.

    Instead, let your customer tell you stories. Ask them to talk about the job they do and the obstacles they frequently face. When you take these stories back to your team, you can put yourselves in problem-solving mode and work on solutions from the customer’s point of view.

  2. Observing your customers in person is crucial to understanding their needs.
    I recall one particular project I had worked closely with for a year, and I was quite happy with it. As far as I could tell, it fit our customers’ needs like a glove. I then did something a bit unorthodox: I took a three week “shadowing tour” to observe some of our actual users. Not to make a sale, not to train them, but simply to watch. The results were both astonishing and painful. On one hand, I gained a whole new understanding of who used our software. On the other; I realized many of our assumptions were wildly off.In many cases, the insights gained from this “fly on the wall” approach were simple yet powerful. For instance, our software was designed for use by a single user. After a week of observation, though, we realized our mistake — many different people were using the same piece of software, and information was constantly changing hands. Seeing this, we adjusted our assumptions about the customer use cases and added functionality to ease transitions between a variety of users.
  3.  Outsourcing customer observation can obscure the longer term vision
    Doing the in-person shadowing described above can be incredibly valuable, but it’s not easy. Not only is it time-consuming and a scheduling nightmare, the travel costs of visiting many clients can make it downright expensive.At one point, we tried to outsource this shadowing within our own company and asked our regional sales teams to do the observation days instead. As it turned out, big mistake. The reports we got from the sales teams, as you might expect, were entirely focused around short-term insights needed to close sales – not the farther vision needed to develop tech that stands the test of time.Whenever possible, I now try to do customer observation directly. It may be painstaking and expensive, but I’ve found the insights we gather are always more than worth our time.

Thanks, Oleg! After hearing what you shared, it’s hard to imagine going about technology design any other way.

Of course, there was one more question I had for Oleg: “Star Trek or Star Wars?” “That one’s easy,” Oleg told me. “I watched Star Trek all the time at university — that’s my pick!”