Leveraging the “Final Vocabulary” of your Users
By: Adrian H. Raudaschl
Tags: Product Management, Management, User Experience, Design, Work

Most product managers have been in this position at some point. Maybe we thought we understood the problem we were solving, but as time passes the issues just keep multiplying. It’s a mess, but I think it stems from something deeper. We have never really been taught how to understand the problems of the users we are trying to help

You can have the world’s best engineering team, but without understanding a user’s world view, you have nothing worthwhile to build.

I’ve been pondering this subject a lot recently, and think I have some ideas that can help. By the end of this article, I hope to provide you with the mental tools for thinking about user problems that I believe will not only improve our chances for building more successful products but also becoming better people in the process.

Product management or Product Translator?

In many ways, the job of a product manager is the job of a translator. The language our user speaks may be the same as ours, but understanding how they express that language it is where the critical details lie.

In many ways, we are trying to learn this language while educating others (engineers, designers, etc.) on how to speak and use it. This is demanding of us at the best of times, so its understandable we unintentionally take ‘mental shortcuts’ to get the job done.

These shortcuts take the form of a personal filter we use to navigate the complicated world around us. Usually, this filter helps us function and form decisive action, but it’s also a curse — limiting our ability to understand and empathise with others.

“But I’m not like that?” I hear you cry. Nobody thinks they could be so polarised in thought as to lose sight of the bigger picture. But often we are so focused on solving the most complex issues head-on, we miss a deeper understanding of the simple problems.

The ‘Final Vocabulary’ of the product manager

I have started to rethink how honestly non-biased I am when speaking with any given person. What are the components that make up my biases? The American philosopher Richard Rorty provides a toolset of sorts for understanding this, one central idea he described is an individual’s Final Vocabulary’.

Everyone has a final vocabulary. It’s the set of words we use to understand the world around us and our place within it. It’s called ‘final’ because the things that make it up are often, very final.

People (like you and I) can reach a stage of life where we believe our view is sufficiently developed that no further effort is required. We have all the stories, narratives, metaphors and discourses we need to justify our actions and thinking (thank you very much).

Given enough time and skill to argue for your world view, you would be hard-pressed to agree that anyone else’s world view is better than yours. And here, is where we arrive at the challenge of understanding others.

Understanding the user and building the real product

How can we understand a user’s problem if we can only describe it from our own perspective? What information are we missing? What pain points are hidden?

This ‘final vocabulary’ of ours shapes our speech and behaviour. Our language is the functional limit, and in turn, forces us to limit our thinking. Understanding this is the key to overcoming these limitations.

We essentially need to go into every interaction with an acceptance that our final vocabulary is as fallible as anyone else’s. At any time we might need to rethink and update it.

For a product manager, this can be counter-intuitive. We are actively rewarded for decisive decision making, which is an exercise in reason. But breaking out of our final vocabulary requires us to expand our imagination.

If we want a better understanding of our user’s, it’s a talent for speaking differently, rather than for arguing well that will help us innovate. It enables us to describe and think differently about the problems we encounter.

How do I change my ’Final Vocabulary’?

Let’s start at the beginning. Everything you were taught on how to treat your intellectual development, was wrong.

Plato’s allegory ‘The Cave’ is an excellent place to start. You know the one. We spend our whole lives watching an imitation of life with its shadows projected on the wall, and the truth of the world is only revealed when we step out into the light.

In much the same way, we are taught that only after we have studied, fraught, argued, worked or read a thousand books will we have finally done the ‘work’ for the truth of the world to be revealed to us. In this process, Rorty argues we are not finding the truth of existence, but rather are just making our final vocabulary.

Our development should not be seen as a linear goal to the truth, because when it comes to humans, there is never a single truth. Your view was still created by you, a human being and ultimately is as fallible as anyone else’s.

Understanding this is the challenge we need to overcome.

Applications in the product lifecycle

So what I a good test for demonstrating an understanding of the problem? Well, written, user stories.

I’ve learned that when I write these stories, I’m trying to do so from the user’s perspective. When I can’t, I know there is a problem. A limitation in my view and understanding. My preferred story structure is the Role — Feature — Reason format, also known as the Connextra format:

As a role I can capability, so that receive benefit

Another version of writing a user story:

As a particular user, I want to be able to perform/do something so that I get some form of value or benefit.

Think about it. As product managers we are effectively translating a given set of user stories to a range of audiences all the time: pitching to managers, collaborating with UX, quantifying with analytics, transcribing into user stories for engineers etc. Performing this task well not only requires us to understand the vocabulary of our user’s, but also our stakeholders.

A user story should give your team a different perspective that helps them understand the intricacies of what’s needed to ship quality features. They effectively grow your teams ‘final vocabulary’, and a shared ‘final vocabulary’ will form the base of better collaboration and problem-solving.