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.

"Their customers never flinched." →

parislemon:

James Surowiecki:

You had tens of millions of affluent consumers. They ate out a lot. They were comfortable with fast food, having grown up during its heyday, but they wanted something other than the typical factory-made burger. So, even as the fast-food giants focussed on keeping prices down, places like Panera and Chipotle began charging higher prices. Their customers never flinched.

It might seem that the success of fast-casual was simply a matter of producing the right product at the right time. But restaurants like Chipotle and Five Guys didn’t just respond to customer demand; they also shaped it. As Darren Tristano, an analyst at Technomic, put it, “Consumers didn’t really know what they wanted until they could get it.” 

Some of this is analogous to the recent rise of Apple as well. Certainly, there’s an element of “right place, right time”, but it’s also about shaping conditions to create that place at that time.

Few consumers can imagine new products or services they’d buy at anything but the “lowest resolution.”

Build Your Product Without Silos

A silo-less way to build your products

Bill Buxton is a legend in the field of computing, and his book Sketching User Experiences is a classic for those building products. The title is actually a bit misleading: the book doesn’t specifically cover sketching, but instead provides a detailed walkthrough of the process of building great products.

These pictures from the book illustrate the product development process with increasing levels of maturity:

1. Engineering builds something, sales tries to sell it (no design)

2. Design is introduced prior to engineering

3. The walls separating those groups are broken down; management and marketing are integrated so the product has a consistent vision and story

If you’re struggling to get your company to focus more on design, try painting this larger picture and treat it as a stepping stone.

Prioritizing Features with Cards

Amberlight Partners created an innovative, visually-oriented way to engage users in prioritizing future product ideas. First, they create a “card” for each idea featuring an illustration of the concept. This way, the user understands the gist of the idea without getting hung up on the potential UI.

Then, the user places the card in one of three categories:

1. Really important

2. Nice to have

3. I wouldn’t use this

Finally, the person running the activity asks the user what led to their decisions.

Tip: Don’t over-explain the possible features and bias the users. After all, it’s likely they will get little to no explanation in the real world.

What Is a Requirement?

What is a requirement? How would you define it? Is it…

• a need that a customer has?

• something a key stakeholder wants?

• a raw idea from someone on the team?

• a detailed description of how something should be built?

• a specific solution someone has in mind?

It’s all of those, and none of those. Since a “requirement” can’t be defined in any useful way, we can’t point to something and say, “yep, that’s a requirement.” How many years has the technology industry been building things without a clear, shared definition of this word?

Let’s say you’ve “captured” a requirement or “gathered” it and you’re holding it in your hand, staring at it. What exactly are you looking at? It’s a bunch of words that fell out of someone’s mouth. That’s it.

What do you do with all these words? If you’ve got a big list full of them, how do you move forward? Well, I recommend you print them all out, bundle the pages together, and feed the pages to a goat. That way, at least the goat gets something out of it. Then, go figure out what would actually help your customers.

Credit: Jake Fleming

But I Already Know What It Needs To Do

Let’s say you’re not going into uncharted territory and you already have a good idea about what the product needs to do. OK, that’s cool. Gather your team together and tell them a story of a better tomorrow in which your customer is the hero and they’re succeeding at something using your product.

Kevin, who works the counter at the coffee shop, can take a credit card payment much faster using the new point of sale system. Finally he can focus on making the best espresso possible.

This is what we (and others) call a scenario. It’s a plausible story about a customer using your product in the future to create a positive outcome. Here’s another one:

Kevin moves quickly and sometimes makes a mistake with the register. Fortunately, it’s easy to void a charge and refund money to a patron’s credit card.

The two scenarios above could be grouped together under a capability called Accepting Credit Card Payments. After all, it’s not feasible for the coffee shop to advertise that they take credit cards unless they can both charge them and process refunds. Continue by listing all the scenarios you plan to enable in this release of the product.

Once you group your scenarios into capabilities, it’s usually pretty clear which capabilities need to ship first. The key is to not deliver a feature until your customer can walk through all the scenarios under the same capability. Put dates next to each of the capabilities and you’ve got yourself a release schedule. Congratulations! Your engineers can get started.

Epilogue

Tony Ulwick’s insightful book What Customers Want helped me realize requirements don’t exist. He advocates an even more rigorous method of determining a product’s feature set against a set of quantified outcomes (e.g. “Clerks can ring up patrons 50% faster with our new point of sale system”).

Check it out if you want to dive deeper.

Steve Jobs on Defining the Problem

Defining The Problem

The above image is a screengrab from this behind-the-scenes video of Steve Jobs and the NeXT team building their strategy. This happened in late 1985, so the slide was actually a transparency on an overhead projector.

The products and markets have changed since then, but the need to clearly define the problem your product solves has not. I want to hear the story of a better tomorrow where a customer is succeeding with your product in a new way.