Meaning Fitness

Back about two years ago, Trevor Rotzien (@trevorrotzien) and I led the Anthropology of Product Management, #aopm, tweet chats. Trevor handled the internal facing uses of anthropology. I handled the external facing uses of anthropology, or more specifically, ethnography.

Since then, I participated on an Anthropology of Product Management panel at the 2009 Orange County Product Camp. I’m not an anthropologist. I’m not in retail. I’m a software guy. I’m an AI guy. I’m a software engineer with a deep interest in requirements elicitation. I’m a Argentine Tango dancer who took on the cultural aspects of that. And, through that came to know an ethnographer, and read ethnographies. During our panel discussion, I showed how attention to meaning, aka cultures, or more specifically functional cultures could lead to better requirements.

In 2010, I attended the Austin Product Camp. I went to a session on retail anthropology. Anthropologists tell us to observe. But, anthropologists spent ten or more years working through a PhD where they were taught frameworks for observation. They entered into a functional culture and internalized the meanings of anthropology. They know how to observe.

We know how to code. We know our frameworks. We learned those frameworks during our education and career as developers. But, if I stood there and told an anthropologist to code. They’d code, well sort of. Likewise, we observe, sort of.

I think it’s the product camp rule against selling that gives rise to this glossy advice to observe. The real advice should be hire an ethnographer. Here is how. Here is what to expect. Here is how to specify the project. Here is how to use the results. The Austin presenter shrugged off my question and never answered it. Another product manage asked me is he answered the question. That product manager wanted to know.

During those tweet chats I laid out a long and very code and industry specific argument about why market segmentation generates average functionality. Meaning is specific, cannot be traded off, seemingly expensive, and contrary to the goals of software engineering and even requirements elicitation, reducing developer costs. I said seemingly expensive, but that was then, back when software engineering was a hot topic, requirements elicitation likewise, and developers were expensive. Today, developers are not costly, or certainly are not the cost drivers they used to be. No, today we pick our cost. We can get code for free. We can let someone else develop a critical component and leverage it even if we have no resources to do it ourselves. We can pay for it, but only as much as we want to pay. Methods and architectures, like Aspect-Oriented Programming, have come into practice, as well, that enable mass customization around meaning possible. Other benefits of these architectures makes this mass customization around meaning highly beneficial to the business case side of things.

I argue with the notions of integration apps and knowledge management techniques that negotiate meaning away. Sorry, meaning is important. Meaning is key. This thread of the argument demonstrates how much meaning is traded away, and how the most data centric of enterprise users actually have little to say about the data and functionality they actually get out of a development process.

I argue with the notion usually expressed as “It’s the Interface, Stupid.” Sorry, no. Meaning is in the model and the view, but the interface stops at the view. Fixing the interface is not enough. And, interfaces can be fixed, so that they serve the averaged populations defined by market segmentation.

Very early in my career, I came across Gartner’s efforts to define the Total Cost of Ownership (TCO). They defined a category called negative use costs into which all non-productive interactions with an application were placed: self support, user time spent on tech support call, reading manuals, desktop training, compensating efforts for holes in the application. Later, as an ITIL change manager, I spent hours reworking data to get the answers I needed. No, we were not getting applications consistent with the meaning of the work we did. Gartner ditched this cost category, but these negative use costs, estimated at 15% of operational costs, demonstrated just how much our applications wasted our time, because of the gap between meaning and doing.

Today, we encode doing, rather than seeing doing as the ritual centered around the meanings that a user population is wrapped in. We encode meaningless doing. We ask users and customers about meaningless doing and call that observing. We can do better.

I run across the same issues tied up in the data quality movement. Sorry, data quality is independent of the meaningfulnesss of the data. Some tweeter on data quality actually blogged about the need for fitness to use. ?Yes!

Back in the #aopm chats, I came to use the term “meaning fitness.” In the past, I came to Saul Worman’s notion of information design as the act of increasing the fitness of use of the underlying data. That has very little to do with graphic design as information design now finds itself being eased into–the difference erased.

It was in Kimble’s book on real-time data warehouses where I came across the idea that the data users would negotiate the meanings of the data items in the data warehouse. Kimble expressed it simply as

Negotiating Away Meaning, The Simple Case

Negotiating Away Meaning, The Simple Case

But, Kimble is assuming that there are only two parties, and that those parties are equals in their ability to negotiate and get what they want. Negotiation class taught me otherwise.

That negotiation class presented me with a research-based framework, which showed who won, who lost, and by how much. Negotiation power classifies populations into those that win 55% of the time, those that win 35% of the time, those that win 8% of the time, and those that win 2% of the time. Putting names on these groups: business unit execs (55%), functional unit managers (35%), functional unit workers (8%), and deep data geek (2%). Ouch. The deep data geek ends up with data skewed towards generalists, so they must do tons of compensating work to just do their jobs, the jobs that were supposed to be automated.

A product manager can catch these compensatory efforts in the customer’s request for export to and import from Access and Excel, the tools used to make the necessary compensations to bring the data back to meaningfulness.

So why didn’t negative use costs become an issue? Gartner found no data to support the existence of these costs. Yes, we incurred them. The August issue of most IT periodicals for the decade before the Web were full of stories about how IT was not delivering the expected productivity improvements. CIO’s knew intuitively what numbers could not tell them. Negative use costs were invisible, implicit, tacit. Negative use costs couldn’t be managed or eliminated. They simply embedded themselves in the cost structure of the organization where they live forever–a cost virus, increasing the labor costs of the functional units while costs were off the IT budget.

Well, CIOs are now dealing with this. But, product managers think nothing of pushing costs off on customers. Hell, the customer doesn’t see those costs. The Web and the Cloud won’t change this.

Ethnography is the way out. Building applications that recognize meaning and don’t trade it off is the way out. But, that is just the cost argument. There is a revenue and profit argument. Mass customization around meaning means reaching more customers, enlarging our markets, without vastly increasing the cost structures of the vendor, us.

Enjoy. Comments?



Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: