Proposal: Borrowing from the Anthropologist's Toolbox

I'd love to participate in this session... especially in regards to how to apply the principles in practice (with the usual small budget!)

The more I learn about product management, the more I see how deeply anthropology should be incorporated. In fact, learning more about why a decision is made is something I'm very curious about. It brings to mind the example of the Ford Focus; It was designed for the young consumer (early 20's), but was most sought after by the middle-aged crowd. Many products find a completely different niche than their intended purpose. How can we as Product Manager's help to identify such gaps, then assist with realignment?

The biggest challenge is taking the jargon and large concepts and distilling them into simple, quickly consumable and non-technical phrasing. While I'm very interested, that's what has stopped me from spending much time exploring the concepts.

I think the challenge is gaining the anthropological or "people" perspective. In one group of training we did with about a dozen people, only one individual had taken even one introductory anthropology class in college. I think up until now, anthropology and the social sciences were seen as disciplines that were not necessarily applicable to good business practices. It makes me wonder when the "people", or customers, became irrelevant?

Market segments are not ethnographically based. Market segments are not about culture. Market segments are not about meaning. They are about numbers--statistics. If you want to understand the meaning, thinking and using of thought tools like software applications, you first have to find the population that subscribes to that meaning. The boundaries are cultural, which are rarely fall within the bounds of demographical or psychographical defined segmentations.

There is a truck culture. There is a muscle car culture. Truck culture has urban, ag/kicker, pro, and other subcultures. The way people think about their trucks will change across those subcultures. It is unlikely that you can find a single demographic to isolate these subcultures.

Applying cultural discovery tools, aka ethnography, doesn't improve cultural alignment when used against demographically delineated market segments.

Artifact cultures are real cultures. A truck carries meanings, because that truck is a media, a media with communicative intent, repetitive training events built into their use, communications channels, and community. Even software has an artifact culture. Artifact cultures are, however, after the fact cultures that arise after purchase and use. Aligning to a real culture or subculture with the artifact under development is another matter.

Use ethnographic studies to discover the ontology, the sortables, the criteria separating members of the culture from outsiders, the learning necessary to become a "thinking like" member of the culture ("in") well beyond the introduced ("on"), knowing, but not thinking like a member. Consider the term capital: economists use the term to mean the ability to leverage cash, accountants use the term to mean cash--capital is a cultural divide. But, when we code the term capital in our applications, economists probably know better than to think we mean "their" capital.

Art designers aim to create culture, aka artifact culture, rather than culture alignment. They have used ethnographic research for a long time. The anthropology firms serving them don't necessarily aim for culture alignment or meaning fitness.

If we coded to the thinking, the conceptual models of users, they wouldn't need to read manuals, do tutorials, learn the software, because it does what they intend and expect it to do. We elicit requirements without respecting their thinking, because we aggregate their dissimilar thinking. We prioritize stakeholders and end up smearing meaning, so even with ethnographic elicitation, we still end up smearing meaning.

Contemporary requirements elicitation practices originated in an era where programmer efficiency determined what got built, not markets, not market segments, not users. Requirements volatility resulted from these requirements elicitation practices when the executive sponsor reprioritized the stakeholders. Political wars get fought over which department's meaning will be sacrosanct. Worse, negotiation skills of people in different departments differ, so some departments always lose their meanings, which increases their operational costs. Since operational costs continue and eventually exceed development costs, so focusing on programmer efficiencies doesn't pan out.

Economics has reduced programming costs. The technical means to code meaning exists today, which when combined with ethnography will take use to respecting the meaning of your uses. This will provide vendors, users, and the customer organizations with great benefits.

Paula, Market segments let us treat people as numbers. Economic indifference enables us to treat employees as numbers. Management soft skills inserts sociology and psychology into the workplace. And, the design community, particularly advertising firms, have used anthropology for a long time. the design community has used ethnographic research in the websites that they've build going back to the early days of the web.

The math-based developers, however, find themselves beyond the reach of ethnography to their detriment. CS and EE developers are different from each other, and different from IT programmers. These differences stem from training, focus, and personality. These populations actually think differently from those outside their groups, but so do people in the humanities. These partitions are functional cultures. As developers we average requirements by not keeping each populations requirements distinct. We average the differences out in defining the base population from which we derive requirements, and we don't honor meaning. We don't keep their terminologies separate. The means to do these things exist today. We need to adopt both ethnography and the technical means in order to reap the vast benefits an ethnographic approach can yield.

This topic is completely foreign to me, would be interesting to learn more about it. I wonder if this is at all similar to the personas?

It's similar, but real ethnographies are not personas. And, this is more a matter of how the users think and what they mean, rather than the stuff I've seen in personas. I'm thinking more in terms of Ontologies, but more in line with the philosophy version, ontology markup, rather than the AI ontologies built for inter-agent communications.

I'll review some personas. Personas, as a practice, were adopted by designers long before developers started using them. Designers have long used ethnographic research.

I'm proposing a session on the topic of meaning fitness, something we've chatted about on Twitter under the #aopm hash tag.

Haig, while personas are useful in representing a particular demographic they are, ultimately, fictional representations. They lack the complexity and depth of information that interaction with a real human can yield. One of the key components of an ethnography (an in-depth study of a group of people who share a similar culture) is participant observation. Observing and participating with the subjects (individuals) can yield far more information than their demographic data.

Unfortunately I won't be able to make it to PCamp. I found out Parents' Weekend at my son's university falls on the same weekend.

We'll definitely miss having you, Paula. I can see many of us were looking forward to your anthropology & product management chat. I hope you have a great weekend with your son!

I practice contextual inquiry, a tailored form of ethnography, for product definition. I'd be happy to share what I know on the subject.

Dave, Paula who originally proposed this session can't attend. We'd welcome a ethnography session. Up for facilitating it?

I'm curious what you all are interested in learning since I can see a number of approaches to take in a session: an informal discussion on capturing and using behavioral data, a more narrow talk on contextual inquiry interview principles and techniques (this would be an advanced topic), an overview of the contextual design process from interviews to user-validated product definition, or ??

I think what might get the most traction is a ethno topic that few have been exposed to, but not too intimidating for the uninitiated.

How about something like this, expanding on Paula's original idea:

"Do you know what your customers really want?"

More companies are utilizing anthropological methodologies to gain a deeper understanding of their customers. How can we gain new insights into consumers' needs and wishes by decoding their behaviors and opinions? When done right, a company can uncover the needs of an entire market with only a couple dozen ethnographic customer interviews. It is, however, much more than just going out and watching people work and live: how do you choose who to talk to? How do you elicit the right information? How do you organize and use what you learned? And how do you validate resulting designs? I'll introduce the contextual design process as a framework to stimulate group discussion.

I'd definitely like to participate in a session covering what you describe. Sounds both interesting and practical.

Dave, "uncovering the needs of an entire market with only a couple dozen ethnographic customer interviews" is a fascinating topic! I'm looking forward to this session tomorrow. I hope you'll take on the task of leading it.

This link contains the slides I presented: http://incontextdesign.com/talk/. Thanks to all who attended!

Thank you for posting the link to the slides.