Cultures in Our Markets

A comment on my last blog post, woke me up to the difference between developing within a culture, and developing from outside a culture. It took email exchanges and tweets to further develop that idea. I’ll show you what I mean in this article. And, thanks to Greg Yankelovich, who tweets as piplzchoice, for that comment.

To make sense of the within and outsider notions of culture, we need a way to visualize a culture. I’m focused on culture as containers of meaning, and hence practice, the stuff of software use.

Philosophers conceived of meaning as “The Ontology,” as if there were only one central structure of meaning. AI researchers have taken on ontologies as agent communications vocabularies. Information architects differentiate ontologies from taxonomies as well. Ontologies are about concepts. Taxonomies are about things. A thing’s place in a taxonomy is based on the decisions used to classify the thing, the taxons. Similarly, A concept’s place in an ontology are based on its definitional differences that philosophers called sortables, and that I’ve come to call ontons. You end up with decision trees. I call the leaves of these decision trees infons. I will say that this vocabulary is not mine. I found it on some Perot Systems or EDS website eons ago.

So to visualize an ontology, we will use a decision tree.

Visualizing Culture

Visualizing Culture

In the figure we start with (1) the usual decision tree, a binary tree. (2) Shows a more abstract representation of the usual decision tree. (3) Moves the binary tree to a multiple branched decision tree, which leaves us with a cone. (4) Shows how a culture contains subcultures that contains subcultures.

The rightmost diagram (4) encodes a cultural terrain. This is the key visualization we need to begin mapping out the cultures within a corporation.

You have the corporate culture, the priority culture among the functional cultures that compete for the “market leading” cultural position. You might find yourself working in an engineering culture, a sales culture, an accounting culture–I hope not, or a marketing culture. That will depend on tradition and the CEO. The corporate culture would provide the shell in any representation. The corporate culture would contain the management culture, and the numerous functional cultures.

The functional cultures may contain specialist subcultures. IT would be a functional culture. Engineering might be a separate functional culture even if it is staffed with IT people. The goals and reporting structure would separate IT from Dev. Your technical writers would have their own functional subculture, since as a population they share meanings, goals, tools, practices, and processes. Their distribution into development teams wouldn’t alter their functional culture. The same goes for the developers, QA people, marketers, and whoever else may be on your team or report to you. Such is culture in a matrix. Consider the culture of your team to be your responsibility, yes, a human, soft-side management responsibility is yours.

Then, you have your boss and his boss and his boss–the lineĀ management structure organized within the management culture of your company.

But, let’s skip from where we work to where we sell, to our customer’s organizations. They look similar to your organization in terms of their cultural terrain. Your product has stakeholders all over their cultural terrain. Marketing and sales deals with all of them, and in the late market, where offer expansion is key to success against the fast following, price competitors, you will deal with all of them as well.

My prior post and last week’s discussion on the #aopmtweet chat was about how requirement elicitatin could be improved by focusing our market populations on the cultures that we usually ignore and crosscut. The above visualization provides some hints to the boundaries that statistical aggreation ignores.

Moore’s technology adoption lifecycle also hints at functional culture as a segmentation mechanism. It shows up in how one would bring a discontinuous technology to market. Moore tells us to start with a custom application. Adding stage gatting to Moore’s model, we can use the client’s vertical as our statistically aggregated population and verify the number of seats and the number of dollars available in that market. An important distinction in these custom applications is that they are products. We should already have our technology.

Our technology is the realization of our idea. We coded to our own specification. Software engineering emerged from engineers and computer scientists who coded for themselves, so they coded within the specifying culture, which enabled them to get away with ignoring culture. They didn’t have executive stakeholders or requirements volatitlity to deal with, and neither do technology developing companies. Culture intrudes when you go to market. That’s when you find yourself and your team coding from its culture for those in another culture. They are coding products.

Now, when we start a custom application gig, we might not yet have our technology platform, so we will have to develop it, as we develop the custom application. If you can, separate the technology platform from the custom application. Separate the container from the contained, the automation from the automated, the channel from the message. Deal with the bifurcated development processes: one based on engineering for engineers, another based on engineering for functional practitioners. You’ll need two teams and two different elicitation processes. One will focus on the technology platform. The other will focus on the customer application riding on top of the technology platform. Build the custom application to the last release of the technology platform, to the last API, rather than the latest API.

So we have started down the Moore’s technology adoption lifecycle (TALC), which consists of sequentially organized, risk orientation-based markets. The TALC is shown in the next figure.

TALC with each market's culture count annotated

TALC with each market's culture count annotated

Starting at the left, you release your technology platform to your technical enthusiasts, or geeks. You provide free betas, because they will not pay for code. They will debug it for you. They will figure out what it can be used for. They will advocate it to their IT bosses and corporate management in terms of interesting applications that solve real problems in their workplace. They help you find the early adopters that will pay for custom application development. You code for people in the same culture as yourself, when you code for the technical enthusiasts.

To make money, you need to find a paying client. You do this in the next market, the early adopter market. These people are business executives that run an organization that will be functionally oriented, or possibly line oriented. Here you will code for people unlike yourselves. You will code from your culture for use in other cultures.

In the diagram, the custom application market is divided into eight different sections that represent the eight custom apps you will need in the bowling ally, or vertical markets.

Once your client’s period of exclusion expires, you can sell that custom application to other companies in the client’s vertical. The market would actually be a particular spot in the vertical, but it would be the same one occupied by the client’s company. The programming situation is still coding in one culture for use in another. The meaning problem persists here.

Once you leave the bowling ally or vertical markets, you once again sell to the IT market, a horizontal market. You move back to programming from one culture for use by the same culture.

Then, you move into the post-tornado, price-based, fast follower competition, or red ocean, situation. This may occur before your entry into the late market. From here on, until you consume the late market, you will code for both IT and functional users, so you will need the culture facing capabilities you might have abandoned as you exited the verticals. One red ocean strategy is mass customization, which has you focusing on functional unit meaning in the various industries that comprised your vertical markets, as well as moving up and down the industry stack or tree that constituted the vertical market. Lots of cultural boundaries need to be observed here.

We need an eliciation process that is sensitive to the functional cultures that comprise our markets. We need to understand and acknowledge the cultural boundaries in our development and marketing processes. We need to move away from aggregated populations that scramble meaning and lead to increased use costs by our customers. The survival of our industry depends on the latter.

Even where we code for our own engineering culture, we do not code for people like ourselves, otherwise, they would code the application themselves, rather than download and compile, or pursue funding by their management. They use an API when it is easier to learn that roll themselves. So even within the engineering or development culture there are subcultures. We need to be aware of these as well.

Let me know what you think. Comments help a lot. Leave a comment! And, for those of you using a feedreader, email your comments to, and I’ll post them here. Thanks!


3 Responses to “Cultures in Our Markets”

  1. Gibbs Barrow Says:

    Great post. This approach is starting to make sense to me.

    One question I have is whether the functional culture should inform the requirements elicitation process? I would assume that the customer cultures however they are manifested should drive requirements elicitation process. My question is whether the product company’s functional culture should play any role in this process. I would assume assume that product company’s functional cultures should drive the process by which you communicate these requirements and lead the project but should they also inform the product’s requirements elicitation process and how?

    This question applies to your ideas around the product company’s function culture. Would political (e.g whoever has the biggest stick wins) considerations drive this process or cultural considerations (e.g. alignment between functional cultures based on customer needs). I believe either could be used to implement an approach. In other words, you can consider functional cultures in your analysis but make decisions based on power and influence.

    Anyway, I would be interested in your thoughts.

    • davidwlocke Says:

      Gibbs, out on the #aopm chat there is a constant stuggle between using anthropology internally to help product managers manage their team, and using anthropology externally to define products. Both approaches are useful.

      When I talk about using functional cultures in the requirements elicitation process, I’m talking about the external facing use where I am eliciting from participants in the client’s functional cultures relevant to the intended application. The functional culture of the vendor is not relevant here. My aim in regards to functional cultures and anthropology in general is the improvement of the elicitation process.

      Adoption of a technology underlying a product is the goal of the technology adoption lifecycle. Under Moore’s technology adoption lifecycle, functional cultures are inherent in the process. You start by eliciting an early adopter’s users. If you pay attention to the functional cultures involved, you come out ahead of the game in the late market where you move to mass customization, and where you move up or down the industrials stack where the early adopter’s vertical is placed. Once you can market the early adopter’s custom app as a vertical app, you are selling to the same functional cultures performing the same tasks and activities around the same meanings. Moving from the vertical to the horizontal is another matter, as it sums your risk reducing custom applications to a single functionality based aimed at, typically, the IT horizontal, which means geek, and geek culture. The knowledge accumulated during the early adopter and vertical market phases needs to be preserved, because it will again be critical in the late market or even early market post tornado or post market leadership assignment and market organization that happens when the category is born at the end of the tornado.

      That you change cultures from functional to geek and back is critical to the success of your application. When we ignore culture, we tend to program for the geek, ourselves, and we tend to program functionality of average fitness.

      There is a parallel between functional cultures and the vendor’s culture servicing those cultures. In some sense, the functional cultures in the application is reflected in the elicitation, implementation, marketing, sales, and support services offered to the users. For a vendor to have a deep understaning of the meaning and practice of a functional culture is to hire it, learn it, capture it, use it, practice it. That the client’s/customer’s functional cultures play out in the process of adoption means that a vendor organization becomes a pipeline of functioinal cultures. Within the vendor, the whole culture developed in the custom application phase must be transferred to the vertial market facing organization when that market is entered. This happens again and again in the technology adoption lifecycle.

      You are right when you say that functional culture-based elicitation can be done regardless of a vendor’s internal anthropological practices. Internal processes that understand and operate via functional culture awareness would be better able to elicit such requirements and build applications that respect functional culture and the meaning of things once mathematically separate from meaning.

      Functional cultures-based elicitation would also force more awareness into the process of listening to the customer, because you would have to know the functional culture of the individual you are listening to.

      Aspect-oriented programming enables the development and implementation of requirements elicited in a functional culture aware manner. The resulting interfaces in such applications would have a fitness to use much improved over applications where the requirements were elicited from statistically aggregated populations.

  2. Choice Cultures | Product Strategist Says:

    […] Cultures in our markets […]

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: