Microsoft CEO Institutes Customer Visits

Nice little article in Quartz today about how Satya Nadella changed things for the better at Microsoft, including customer visits during executive retreats:

Another decision, not universally loved, was scheduling customer visits. “There was more than a little eye rolling and groaning,” Nadella reports. But the next morning, roughly 150 retreaters were split into groups and traveled together in vans to visit clients, including large and small businesses, schools, hospitals, and startups. Each van, Nadella says, carried one “nervous account manager” along with a cross-section of business leaders from a range of company departments, like marketing, engineering, and finance.

When they all regrouped for dinner back in the mountains, the employees were assigned tables within remixed groups, and were therefore not able to fall back into their regular circles and—let’s be honest— gripe. Instead, each person was asked to describe their day and discuss where they saw the company’s culture and where it should go. Nadella writes that he expected little engagement, more of a “let’s-get-this-over-with” attitude. “They’d be persnickety” he predicted. Instead, he claims, the conversations went long into the evening.

There’s something in human nature that makes it next to impossible to ignore the plight of your customer when you see it with your own two eyes. It doesn’t matter if the evidence is only anecdotal.

Inside Apple And IBM's App Making Machine

Apple helps IBM design enterprise apps by starting projects with a three-day workshop in which they work out the key aspects of the app.

When IBM gets an order for an app such as Passenger+ from one of its enterprise clients, it invites key members of the client’s team in for a three-day workshop at Apple’s Cupertino campus. At the beginning of Passenger+ development, Air Canada sent IT people, managers, and flight attendants to the workshop to hash out the basics.

This is similar to the process we use at Appiphony. Though there isn’t time to sort out every tiny detail in a few days, the group has reached consensus on the core elements of what the app will do and how it will work.

Note the emphasis on talking to the actual end users of the app.

In addition, Apple requires that end users from the client—such as flight attendants in the case of Passenger+—are there to provide their unique view of what they need from an app. The company believes that this step is essential for prompting an immediate “Oh I know how to use that” reaction from the people who will actually use an app, one app designer told me. It also cuts way down on the training time needed to initiate new users.

Miller-Sylvia told me that this insistence from Apple doesn’t always play well. “You can’t imagine how much push-back we get from the client, because the managers think they know,” she says. But “all of the transformation comes from the end users being involved. There’s so many things that they do, and the managers end up getting surprised in the sessions and saying, ‘We had no idea.’”

During one workshop, one of the end users explained: “When I need to do that, I just write it on my hand,” Sylvia-Miller recalls. “And the manager was like, ‘you what?!’” It’s exactly this kind of nitty-gritty day-to-day work reality that gets exposed during the three-day workshops—things a middle manager might never know about.

It’s odd how this is seen as problematic given that it costs so little in time and money, and almost every company talks with customers after products are delivered to gauge customer satisfaction, Net Promoter Scores, etc.

User Stories Must Die

I knew the traditional Agile user story was lifeless and disconnected from the real world long before I could articulate why. Then I came across Alan Klement’s post on replacing user stories with Job Stories, which builds on top of the Jobs-to-be-Done framework.

Instead of the usual “As a / I want / so that” structure, a Job Story looks like this:

  • When [I’m in a certain situation]
  • I want to [take some action]
  • so I can [achieve some outcome].

I’m in the middle of synthesizing a pile of customer research right now, and I’m kind of amazed how well the Job Story lets me encapsulate what I’ve learned in literally one sentence. Traditional design methodologies offer other ways to capture and share these insights, but boiling it down that much is very compelling.

Another benefit I’m seeing is knowing how much more research is needed. That is, if you can’t write the Job Story to explain a behavior, you’re not done interviewing.

The Study of Causation: Etiology

I was listening to the TED Radio Hour today and ran across a great word: etiology.

It’s the study of causation, as in:

What causes someone to contract polio?

For those of us doing product work, it’s critical to know what causes someone to use a particular feature. What caused this user to run a certain report? What’s causing these other users to create a given workaround?

Your product will improve when you understand the etiology of each user behavior.