The Cook’s Customer

I was perusing Anthony Bourdain’s Appetites; a cookbook. In it, he asks a few questions about his customers, and he is shockingly honest about the answers to those questions.

What is it that “normal” people do? What makes a “normal” happy family? …

I had little clue how to answer these questions for most of my working life, as I’d been living it on the margins. I didn’t know any normal people. From age seventeen on, normal people have been my customers. They were abstractions, litterally shadowy silhouettes in the dining rooms of wherever it was that I was working at the time. I looked at them through the perspective of the lifelong professional cook chief—which is to say, as someone that did not have a family life, who knew and associated only with fellow resturant profesionals, who worked while normal people played and played when normal people slept.

Do those of us in the software community have this problem? Are our customers still abstractions even if we’ve met them, spoken with them, engaged them in an ethnographic field study? Does their corporate culture look like our culture? Is it true that we work while they sleep? Do they use the same software we use? No, of course not. Do they seek value whee we seek it?

Do they use the same software we use? No, of course not. Do they seek value where we seek it? No, of course not. Do our customer personas point out the differences between us and them? This gets harder with the technical enthusiasts because they seem much more like us than our users or our economic buyers.

Where do we define the closeness of our abstraction, the gap between an atomic bomb and a hypodermic needle? We go with the atomic bombs too often.

Make no mistake, sure I’m asking product managers, but really, I’m asking the developers because we leave this in their hands. And, when we “fully load” those developers to capture all the effort that we can, are we not failing to leave time to know the customer, know the carried content, or even know the carrier. We do tend to make time for our developers to know the carrier.

Developers don’t come to us experts in our carried content, our users, or our economic buyers. They need to learn those things which reach well beyond the “learning” the Agilists mention and experiment towards: was it used; was it used sooner, rather than later (was it successfully learned); does it deliver the value it was supposed to deliver to the entity it was supposed to be delivered to?

Once those questions get answered, tighten the limit, so the gap becomes a fence, rather than a borderland, and answer the questions again. Find the questions tied to the scale of the gap. Enjoy.

I’m sure after working with too many developers that thought that their users were just like them, that your answers should surprise you, just as Anthony’s answers surprised him.  Enjoy.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: