From Cultural Attributes to Personas and Stories

The topic of defining the cultural attributes of a company culture came up in a recent Anthropology of Product Management (#aopm) discussion on Twitter. There was also an earlier discussion about this on Linked In AOPM discussion group. The ideas that Art Petty and Pattie Vargas contributed to this discussion served as a starting point for my post. Thanks Art and Pattie for jump starting my thinking on this.

Cultural attributes are characteristics that define a culture. The idea is that you can use cultural attributes to help solve cultural problems. These problems, which are really people problems, can be anything from understanding a audience for a product to understanding how different groups interact in an organization. Many product and organizational problems are actually cultural problems, although they are often disguised as tool or business practice problems.

There are a unlimited number of attributes that can be used to define a culture. I think, however, that we should be cautious about applying the same set of  attributes to all cultures.  Each culture has its own particularities and the best approach is to derive the attributes from the particular culture you are studying— a bottom up or inductive approach as opposed to using a one size fits all.

To illustrate this inductive approach, let’s talk about a cultural attribute that is used frequently to describe business organizations. Patti Vargas suggested that thickness is a cultural attribute that should be used to study and understand organizational problems. Thickness/thinness is about whether or not a majority of employees support and believe in the company’s mission and philosophy. Let’s say for the purpose of this post that the culture in question is thin.  There is no question that thinness is a valid attribute to consider; however, the more important question is why does this thinness exist, and is it a symptom of a broader belief system at work?   For example, if I knew that a company’s thinness was the result of an unfair compensation practice that alienated many of the employees, I might conclude that there was a significant distrust of the organization. In this case, the more meaningful element to consider is distrust of the organization, not thinnessDistrust of the organization would say so much more about the culture than thinness and have so many more implications. However, if the culture were thin because many employees were previously self-employed consultants, who were naturally more autonomous, then thinness would have very different implications. Again, this just demonstrates the importance of the why rather than the what. Thinness just describes the problem while distrust of the organization begins to addresses the root cause.

Typically, the reason one defines a set of cultural attributes is to solve a problem. Therefore, it is reasonable to expect that someone, perhaps, several people would be required to use these attributes and, more importantly, internalize them in order to solve the problem. Internalize is the operative word here because the problem that needs to be solved is a people problem, not a math problem, and that requires empathy. That being the case, it is important that these attributes regardless of how they are derived be as memorable and as human as possible.  This requires something more than a list of attributes because attributes do not create empathy. In fact, the best way to communicate these attributes is not to use attributes at all. Attributes work well for solving a math or algorithmic problems, but not for people problems.

The best way to translate a cultural attribute into something memorable and human is to write a story. A story contains a believable character, often referred to as a persona, and a story line. Stories might seem odd at first but stories are something everyone including programmers and mathematicians can relate to.  We were all exposed to stories when we were young and that’s how we learned at a very early age. To create a story about how distrust of organization manifests itself in organization, you would create a character, let’s call him Mike, and tell a story about how Mike deals with his distrust of the organization. You would use the details you gathered while observing people in the organization to flesh out Mike and the story about him. Mike will probably represent bits and pieces of several people you observed in the organization in question. Since characters typically represent more than one attribute or idea, you might want to incorporate other elements about Mike that you’ve learned while observing the people in the organization.

It will take you a while to flesh out Mike but when you are done you should have a narrative that really shows what is like to be an employee of this organization. More importantly, it will help people who are trying to solve Mike’s problem, understand and internalize what it feels like to be Mike.


10 thoughts on “From Cultural Attributes to Personas and Stories

  1. You can find a thin culture in a startup where the founder insists on making all the decisions. That is a hard place to work.

    The notion of thickness and thinness should translate to the buying process. A seller would have fewer stakeholders to sell to, and fewer specification conflicts.

    Given that we are talking corporate culture, the priority culture here, there will still be a conflict between the corporate culture and the functional cultures of the end users. Given that a corporate culture is the priority culture, it’s thickness and thinness will vary as you move away from the priority culture. Some functional units may believe that they don’t matter. Been there.

    Cultures have entry points. Cultures have interfaces with the outside. Cultures have gradients and subcultural terrains within them. And, here as well, much like an object within another object, there are cultural interfaces as well. Those interfaces might be rituals. Did you get through the interview to become one of them. These gradients and terrains bound the density within.

    A corporation has an overarching culture that gave rise to the functional cultures within it even as those functional cultures were imported from the outside, and aculturalized within as they were built. The economic indifferent management culture is yet another culture within the corporate culture.

    In the mathematical sense, cultures do not suffer the packing problem. Any concept can be viewed from many ontologies, from many cultures. The totem is real, so it has a unique place in physical space, but meaning is infinite and not packable.

    If density is a matter of measurement along some dimension, the boundaries of culture are range delimitors. The dimension is not continuous acros cultural boundaries even if the measurement applies on both sides of the boundary.

    The multiplicities of cultures within a corporation would lead to different thicknesses among the same measurement. Is this meaningful, or meaningless would be the thickness question for a given attribute. The cultures make for a clumpy texture.

    1. Great post. I think that I am beginning to understand the relationship between organizational culture and the product and how managing that relationship falls squarely on the product manager’s shoulders. I feel for you.

      As a product manager, you would need to understand the different functional cultures (qa, marketing, prod mgmt, engineering) as well as the overarching corporate culture often referred to as the business (the CEO, the board of directors) to begin to identify where the conflicts exist, more specifically, among the customer needs and the multiplicities of organizational needs, and so on. Multiplicities is indeed the right word to describe this; it is not simple.

      To communicate customer needs to each functional culture, you will most likely need to create a separate interface for each culture. The interface would attempt to reconcile the conflicts between the given functional culture and the customer needs and between internal functional cultures if necessary.This is because each culture is different and they will need their own entry point or segue into the product. The overarching culture would need the same thing. If you can’t convince the leadership in each functional culture to embrace and internalize customer needs, then you must figure out how to minimize the interfaces between the functional cultures and the product and that can be tricky. Even if the leadership gets it, it doesn’t mean the folks on the ground are going to get it and that can be another challenge.

  2. Do you equate “story” with “use case”? Is it a fair comparison? The cultures can also be conflicting within the same enterprise – the best examples I’ve seen are around sales forecasting where sales and finance organization collide. @piplzchoice

    1. User stories typically more upstream. They illustrate the target customer or persona’s behaviors, values, and goals. You usually have more than one story because you have more than one persona. The real challenge is to avoid framing the story by the current product because the story will have limited value and become more tactical than strategic. I used the word “frame” because you may not want to exclude target product usage from the story. In some Agile worlds, user stories may have a different meaning. I tend to think of stories as being more cultural than system oriented.

      Use cases are typically more downstream and more system oriented. They are detailed flows of what actors (includes systems and users) do with respect to the target product’s features . There is a language, a library of symbols, that are used to illustrate these flows. Use cases typically require time consuming revisions because they are so detailed.

  3. Good article. Would love to see “Mike’s story” – I think it would really drive home your point to have a tangible example.

    The next thing I would want to understand is how to gain insights (or how other people would gain insights) from the story, and how to apply them to .


  4. Where Gibbs is saying culture, that would be a matter of population construction. The typical process uses mythical aggregate populations, and lead the development of average functionality.

  5. Insightful.. until the last two paragraphs. Pardon my criticism, but the “story” you crafted is not the one I imagined you were leading to.

    The story of Mike is a story of the faithful employee, the drone, the cog in the corporate machine. His attributes are generic, unlikely to relate to the personal stories of each employee and their role within the organization.

    I’d rather start with the story of our customer, a more likely candidate for applying the technique of the “persona”. Mike should be seen as the customer, a person who has a need, a question, a value system. This should be a much easier culture to pin down since our organization should already understand the target audience to which we are marketing.

    Mike-the-customer’s needs and desires drive him to our company. This is where the employee enters the picture. Each person in the company contributes to a part of Mike’s solution, and are thus a component of his story. An employee’s role have as much variety and personality as the employees themselves.

    Trust in the organization can be rebuilt once employees feel their company culture is solving a real customer need.

    1. The economic buyer is the customer only once. That for the intial sale. The users are the customers for every subsequent sale. And, guess where the software industry makes most of its money? The user, not the economic buyer.

      The things the economic buyer wants are beyond the realities of that the economic buyer’s enabling users want. There is a huge disconnect between the economic buyer and the users.

      There maybe a role for management in a given application. That still might not cover the needs of the economic buyer. Category issues well beyond the in-software management role would address the executive sponosors needs, but only the market leader can address them, and that doesn’t usually happen until something like the third wave of applications come to market.

      Gibbs isn’t talking about taking the typical approach here. The typical approach is very broken.

  6. You are not the only one who has mentioned that they would like to see Mike fleshed out, which I think by definition means something more human. Also,you bring up an interesting point, which if I have interpreted correctly, introduces the idea of user personas, which represent customers who use the product, and market or brand personas, which represent customers who buy the product. In the B2B world, these two personas can be very different. In the B2C world, especially the web,there may be a lot overlap between the two personas.

    I plan to post some topics soon that will expand on these ideas.

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