As I’ve let go of being an individual contributor and focused my time towards a more formal leadership role, I’ve developed an appreciation for the art of conversation amongst product teams.
Conversations are a critical part of an organization’s toolbox. On average, people have 1.2 meetings per day. Managers have around 3 meetings. That adds up to about 45 hours worth of meetings per month for a manager. That equates to a lot speaking, listening, and responding, but that doesn’t necessarily equate to shared understanding.
When we think about product design tools, words like Jira, Sketch, or InVision quickly come to mind. You might also think about methods such as journey mapping, user testing, and other approaches that create tangible artifacts. There is one tool, however, that is likely one of the most powerful tools in your product design tool chest which people tend to forget. The words you and your team use to communicate and make decisions.
Words bring meaning, and meaning brings change. However, words are also subject to interpretation, so the changes words bring are sometimes unexpected, and here lies the issue with many of the conversations I’ve personally had, and have watched others have time and time again. The result…confusion, frustration, and loss of trust.
The words that we use in language split into 2 areas: internal and external. Every word you externalize via speech is comprised of dozens of other words that are processing in your mind internally. This same process happens in teams. Internal conversations that may include technical terminology (ie. API, journey map, etc) result in synthesized reports and narratives customized for stakeholders. It also is present at the organizational level, where the internal language shows up in goal setting frameworks such as Objectives and Key Results (OKRs), and external language manifests as marketing agency material, branding, and design systems. Ultimately, the conversations we have with ourselves, our teams, and our organization culminated in a product. For the purpose of this article, I will be focusing on cross-functional team language.
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations
Which is to say, teams that have a hard time communicating will be more susceptible to misunderstanding, misalignment, and delays, all of which eat away at time and trust, increasing frustration which leads to accepting more risk to hit goals, unclear prioritizations, ultimately resulting to poorer products. While focusing most of our time on our external (customer-facing) language might sound like the best thing to do for a product design organization, if we don’t have strong internal communication amongst our teams, our product will never reach its full potential.
Words and their meanings have been a focus of philosophy for centuries. What is love? What is knowledge? Socrates spent much of his time pondering these questions. As I started my quest for identifying areas of communication that teams struggled with I was directed to another popular philosopher, Ludwig Wittgenstein. Wittgenstein was not a fan of Socrates. In fact, he described that reading Socrates was a complete waste of time. To him, Socrates had wasted much of his life treating words as “things”, much like an apple or car. To Wittgenstein, however, there are many words, such as knowledge and love that are meaningless without the context in which they are used.
Think of words as instruments characterized by their use… – Ludwig Wittgenstein
One of the words that I picked out early in my investigation was “impact”. This word gets mentioned regularly across departments and organizational hierarchy. More importantly, it almost always shows up in crucial conversations that shape the trajectory of a product and organization. The potential wide-spread organizational Impact of the word impact is huge. The problem with this word, and many words like it, is that they don’t mean the same thing to everyone, yet they are used so much that understanding is assumed.
Extending my search to other words that sometimes create confusion I honed on the list below and categorized them by the underlying job the word is attempting to fulfill. In hindsight, the categories seem obvious, however, by looking at the similarities between each word in the group, we could start to come up with tactics that might help us better understand each other and come up with strategies to avoid problems.
Scale suffers from 2 issues that fuel misunderstanding: magnitude and lenses. Magnitude is defined as the distance between 2 or more objects. It visualizes “how much more…difficult/feasible/impactful/etc…” an item is when compared to others. This is very subjective and sometimes leads to unnecessary debate. I watched Daniel Stillman navigate this during a great facilitation class I attended where he had participants focus on relative values to create a force ranked list. Simple and effective.
Lenses are what enables a person to make sense of the word given their own reality. There are a couple of factors that influence a lens: role and experience. Below are a couple of scenarios that I’ve seen happen.
Scenario One: Experience Lens
Two people of the same role will answer a question on effort given their own experience with the problem. The result is a value that is either too high or too low. Agile teams use an interesting technique at the tail-end of t-shirt sizing. If any 2 engineers have a difference in opinion the Scrum master will ask the person with the highest and lowest score to explain their rationale to the group. This technique level sets experience by giving it a place in the conversation.
Scenario Two: (Absent) Experience Lens
For a variety of reasons, many engineers are not given the space to participate in early problem and solution discovery. At some point during these phases a team of cross-functional members, sometimes minus a developer will start to prioritize which idea the team will take forward to prototyping. A variety of factors will likely fuel this decision, however, (assumed) engineering effort is usually at the top of that list. With no engineer present, people in the room with no development experience start to estimate the effort of expertise that sits outside their area of specialty. In a previous post, I speak about the importance of having tech partners, creating “safe words” for them to give Scientific Wild-Ass Guesses (SWAG) early on the design process when there is very little certainty.
Scenario Three: Competing Lens
In cross-functional teams, each member of a group may be experts and provide accurate estimates. However, those estimates might be coming from a vastly different context. Let’s take a scenario where there are two competing ideas. One will require a lot of work from the engineering and not much from the content team, the other will require a lot of work from the content team and not much from the engineering. Being that the experts of both departments are in the room, the engineer voices that the engineering-focused solution gets a higher value and the content expert does the same for the content-focused solution. In the end, you have 2 solutions that are potentially mapped at a similar place on an effort scale. This mapping can be problematic when you think about what this value is attempting to communicate. More than likely a person looking at that value will interpret those values as either time, resources, or dollars. The problem is that the two roles are not an apples-to-apples comparison. In reality, the high-content effort could cost the organization much less (27% less) than the high engineering effort, making it a “Quick Win” (low effort, high impact) compared to “Big Bet” (high effort, high impact). This results in a missed opportunity fueled by miscommunication.
Questions to ask:
- Is everyone is using the same lens to evaluate the scale?
- Does the group have a mental model of what low and high look like?
- Can we get more specific to create shared meaning?
Status & Milestones
Status & milestone terms come in a couple of flavors, formal and informal. Informal status terms are everyday conversational words like ready, done, started, finished, etc. These words are used in regular conversation.
Are this designs ready for the developer?
Formal words map directly to a process. Epic and story grooming means something to developers in an agile organization. Empathize and Ideate means something to a designer using a Design Thinking process. Every department likely has words that are specific to their role.
In the case of design, it gets a bit more complex. Engineering tends to be much more formal about their language, especially agile teams. This language is baked into the fabric of Scrum. Design struggles a bit because, unlike scrum, there are many redundancies in the language. That means that 3 designers on the same team could be following 3 different approaches yet be doing the same exact things at the same time. Doing a quick search on Google for the design process will produce a sea of colors and shapes ranging from loops to spirals, hexagons to diamonds, all saying similar things in different ways. Here lies a problem, if you can’t name phases in a process then it is difficult to communicate expectations of these phases.
Our UX team as settled on phase names that sounded self-explanatory to non-designers. We also agreed, keep it simple…no arrows. This continues to be a work in progress, but currently, each of these is defined in our internal UX Glossary and has expectations and outcomes associated with them which are accessible to the organization.
Questions to ask:
- Does everyone understand what is expected of them in each status?
- What signals are we looking for to know that we have completed this status?
- Could the same term be used for multiple milestones? (ex. Ready…ready for what?)
The interesting thing I find about classification words is that usually, they are good enough…until they’re not. Here are a couple of examples of what I mean.
Scenario One: Problem:
When creating a new product or service your team will be introduced with many problems to solve. These problems will then get prioritized and user experience designers and researchers will start to intake each of them into their design process. One by one they take them through their checklist of experiments. While this approach might sound great in theory, there is a very serious tension that starts to develop between design research and go-to-market timing, causing frustration pointed directly at the design team. One approach we’ve been using is introducing Cynefin terms to properly map problems in terms of complexity. This enables for more strategic use of research and design effort.
Previously most of our research would be strong early on, but all it takes is one too many pivots and now you are off track and forced to make risky decisions. This is not the place we want to be.
Instead, we’ve introduced a way to “size” complexity of problems to give our designers a way to communicate why they plan to do little to (dare I say) no research on one “obvious” initiative, instead, making room in our plan to spend more time on a “complex” initiative with higher impact towards our goal metrics.
The thing about design, especially design problems that span across complicated and complex realms of complexity is that they are somewhat unpredictable and that unpredictability is what makes it predictable. For example, we know with pretty high accuracy that we will require much more effort in gaining business alignment with likely more design pivots in the complex domain, than in the obvious or even complicated domain. Since emergent means that there aren’t any experts to call on or set patterns that we could jump off from, alignment on “What” we are going to build and “How” we plan on building it will likely lack alignment and will require time and iterations to achieve. In the image below I attempt to demonstrate how you might adjust research effort across initiatives based on complexity, allowing you to be strategic by taking controlled risks that you and your team agree on.
Scenario Two: Prototyping
Stakeholder and cross-functional team members all have very different styles of getting their point of view across. I’ve run into several product owners and visionary-types that prefer a very tangible approach to communication. They have no issue opening up Powerpoint and quickly creating a low fidelity wireframe out of boxes and text. The problem presents itself when the product owner demos the wireframe to the design team and others in the business. Unless explicitly stated, it is not obvious whether this prototype is a directive or simply a communicational tool. This is especially confusing for a less experienced designer if the person presenting is of a higher rank in the organization.
Prototypes come in a variety of polish.
They are also used to experiment with various aspects of a product such as how it might look, the role it may take in a person’s life, how it might be implemented (also known as a dev spike).
Lastly, they help people fulfill many jobs such as:
- Tell a story: Prototypes used as props and visual aids.
- Formative User Testing: Prototype to test if we are “building the right thing”.
- Summative User Testing: Prototype to test if we “built the thing right”
- Provoke conversation: Prototype that is used to gather generative feedback by getting people to react positively or negatively.
- Presumptive Design: Design for failure, learn and iterate
- Communicate a long term vision: Prototype that paints a picture of a product’s idealized future
- Document Development specs: Prototype that is used as interactive documentation of design specification, flow, and micro-interactions which developers refer to as they develop.
With so many jobs a single word can achieve, it’s no surprise it causes confusion without context.
Questions to ask:
- Could people identify one type from another?
- Does a change in category correlate with an increase of effort? How much?
If your team wants everyone to share the same understanding of words that are used for decision and status conversations, then you will need to lead by example and be an advocate for those words. If you don’t use your words, then nobody will use your words.
Our team has had the most success at this by putting these words to work. By making words not only communicate but solve problems, helps others understand their value. This motivates others to use your words in the way you intend as well. For instance, here are a couple of experimental visualizations I created for using imagery to help with resourcing and scheduling conversations.
The standardization of language is not a new concept by any means. You currently see examples of this in the Agile movement through the use of “Ubiquitous Language”. Ubiquitous language (UL) is “the practice of building up a common, rigorous language between developers and users.” This language is embedded into documentation and code assuring it is used consistently across software.
Thinking about words has taught me the importance of “not only listening to what people are saying but being aware of what they are not saying”. A quote I heard on a recent podcast. Once you are able to do that you could avoid most of these problems by simply asking, “What do you mean by…”
At your next meeting listen for words that fall in any of the 3 categories discussed above. If that word in anyway impacts expectations of any person no the team or the direction of the product call it out. Are you all on the same page? If not take a moment to get on the same page. The cost of slowing down in the beginning of a conversation (minutes) is a fraction of time compared to the time required to remediate problems and misunderstanding that might occur as the project is underway (hours, days).
If you you identify other word themes that I have not mentioned in this article, and how you plan on addressing it, please add them to a comment. I would love to learn from you.
Special thanks to Daniel Stillman, of The Conversation Factory and Innovation Leadership Accelerator, and co-worker Aaron Houssian at Macmillan Learning, who both helped me organize my thoughts through thoughtful conversation. Also a big shoutout to Asbury Agile , I am humbled to be given the opportunity to speak with such talented individuals.
Check out their conference next year. I found it to be well rounded and thought-provoking.