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.

Using Narrative to Connect with Customers, Users and Everyone Else →

How does your message fit within the interconnected web of stories that defines their worldview?

Empower Your Users — Appiphony Insights →

Delight is great, but people at work want to be empowered.

What Customers Say

What do you get when you talk to customers?

I just finished a large round of customer interviews and was reminded of something in Tony Ulwick’s great book, What Customers Want.

When you talk to customers, they don’t give you “requirements.” In fact, requirements don’t really exist. The statements they make can be separated into four buckets:

• Solutions

• Specs

• Needs

• Benefits

The sketches above give you an idea of what that sounds like. Usually, these statements aren’t directly actionable by the product team and need to be “unpacked” to some degree. You need to translate what you’re hearing into either:

• Outcomes they’re trying to create

• Goals they’re trying to achieve

• Jobs they need to get done

• Constraints they’re under (don’t forget these!)

There’s lots of information available on how to translate the statements into actionable insights: you can use Tony’s book, refer to The Jobs-to-be-Done Handbook, go with the Lean Startup approach, or use the traditional Cooper design methodology.

Talk to customers, but don’t take their statements at face value.

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.