4 MINUTE READ
As a Product Manager, effectively communicating what you’re building is an integral part of the role. Whether you’re creating a business requirements document, commenting on a design or conveying your product vision to marketing and sales, it’s almost impossible to avoid semantical differences in terminology.
Let’s start with the typical scenario that plagues agile technology companies every day. A new idea is conceived through internal conversation – it could be the next killer feature of your product. As the ideation phase commences and thoughts are put on paper, the feature begins to take shape. The idea starts becoming reality. Over the following weeks, workshops are usually held amongst the team to generate documentation and designs. This is where the issue begins.
Developers call feature “x” one name and design call it something different. Marketing then use their creative naming prowess, while sales tweaks it again for the pitch (to sweeten the deal, of course). Your original feature now sounds like a Swiss Army Knife. Sound familiar?
Every in-person conversation from this point forward now requires a translator (usually the PM) to clarify what people are referring to. This takes a tremendous amount of time and focus away from the most important issue – solving the user’s problem. This is a hassle during face-to-face conversations but try going through this via email or text. It’s downright painful.
As a last-ditch effort, most individuals resort to grabbing a piece of paper or dry erase marker, scribbling a sketch with their personal nomenclature to describe the feature and its desired functionality. The team looks at the sketch and each person applies their own label to the image. The meeting ends and, still, no two people call the feature the same. When you extrapolate all the time spent over 100s of conversations the sum total is mind-boggling. The issue has been systemic since the inception of the feature and the release date for your product has to be pushed back.
An audio-visual solution
To rectify this problem and make the process more efficient, we take a different approach at CrossCap. When we are holding our initial workshops with various teams, we work together to build a terminology document that defines a name for each part and the feature as a whole. By introducing the document as early as possible in the product development cycle, we ingrain the correct terms from day one.
As we add in the matching visual designs, everyone knows what we are discussing during future workshop meetings. It’s the same model Rosetta Stone use to help people learn new languages. Repeatedly presenting images alongside terminology is by far the most powerful way to learn and remember new words. When someone does use a term incorrectly or tries to inject new words, they are corrected by the team. We now walk away from our meetings feeling energized rather than mentally taxed from endless interpretation and confusion.
Overall, we’ve noticed a substantial decrease in the amount of time for team members to comprehend what people from other departments are referencing. This leaves more time for us to focus on the problem at hand; creating the best experience possible for our users.