Your boss is obsessed with terminology? You probably deserve it!

My first boss was fanatical about using the right terminology and industry jargon.  

He was right. 

I recently came across an interesting post by a product manager, complaining that her CEO freaks out whenever a wrong term is used in a document, a meeting, or even worse, in the product. 

It reminded me of my first CEO who repeatedly urged all of us (sales, PMs, developers, QA engineers) to use the terminology and jargon used by the industry our products operated in.

He used to argue with us, correct us, waste time on explaining that words are more important than features, and he even fired someone for using Disney-style terms in a product demo (true story!). 

He was fanatical about terminology, and while it felt like madness 20 years ago, today I know he was right and we were all wrong.

Reading that young PM question (and some of the answers), convinced me to write this post and emphasize why product leaders, developers, UX Writers, and basically anyone who's involved in developing software should MUST also be fanatic about terminology. 

It all comes down to communication, authority, credibility, and alignment. 

1. Communication 

When you and your product speak the right terminology, your customers don’t need to spend brain-power on translating your creative/over-generic/tech-savvy terms into their day to day jargon. It streamlines the communication, eliminates potential obstacles, and helps them focus on the content itself.

When you, your product and the customers speak the same language - the interaction feels authentic.

And authentic is good for conversion.

There are plenty of cognitive biases to support this claim:

• People tend to prefer the ones who share the same interests, language, and habits as they do (check out the likability effect). 
• People also tend to prefer things they are familiar with (it's called the familiarity principle). 
• Similarly, C-level executives prefer to do business with sales reps that speak their lingo
• End-users try to avoid uncertainties (ambiguity effect) and prefer products that are self-explanatory and feel familiar. 

Back when I was at ClickSoftware, our products dealt with field-service activities, scheduling and managing the work of thousands of field technicians. 

We used to call the field resource ‘engineers’, we had ‘tasks’ representing work orders, ’assignments’ representing the appointment part, and ‘calendars’ representing shifts. 

I guess those terms were all invented by the original engineering team because none of them were used by any of the companies we worked with…

In every product demo we had to begin with explanations about what’s a task (“it’s really a work order...”), an assignment (“it’s that booking part… well, yeah, because it’s object-oriented…”), and a calendar (“it’s a shift… see? a shift… you know what? let’s forget about calendars… let’s just call it a bloody shift…”).

As you can imagine, sitting in a sales demo with executives and managers who have spent their entire careers in field-service, trying to bridge those terminology gaps and wasting time explaining WHY a calendar is actually the shift - is not the best way to start a long term relationship…. 

Great communication is important for B2C products as well.
The product must speak the right language and use the right terminology.

When users don't feel comfortable with the UI (and these days, the text and microcopy are a crucial part of the design), many of them will churn, as there is no human representative to clear the ambiguity and convince them to stay. 

2. Authority and credibility 

Customers want to buy products from experienced vendors that know their business well and truly understand their pains and their goals. For that reason, software vendors must demonstrate authority and credibility.

Try to sell a product to an experienced executive who’s been in the field for years without using the business jargon… you’ll find that it’s impossible to build authority without being perceived as a market expert, and experts know the lingo. 

For example, marketers speak the language of "MAU, DAU, ARPU, ARPPU, OMBUBU, ARPUDU-BA-BA"… If it sounds like Wakandan to you, you’re marketing authority is pretty low… you won’t last 10 minutes in a UA discussion, they’ll eat you alive! (believe me... I know). 

You wouldn’t even try to use inaccurate terminology in a marketing optimization product, would you? Well, it’s the same for all industries, especially the ones that deal with low-tech. 

Professional terminology and jargon will help you establish the product’s authority and credibility. Both of them are needed to improve conversion rates and sell.

Real experts also know that the jargon varies between different counties and sub-industries, just like real football fans will never call it soccer. 

While the above may seem relevant only to sales and marketing people, the company must make sure everyone is aligned, including developers who barely see the daylight and prefer to break problems into generic nameless objects and services.

BTW, it's also important not to fall into the dark patterns trap.
Many times, as products are struggling to improve conversion rates by exploiting cognitive biases, they take it one step too far and use dark patterns to make users do things they didn't plan to.
There's nothing like a dark pattern to kill your brand's authority in a second - so this is a big no-no. 

Check out the YOUR most popular posts in here: 

The best of the Mobile Spoon 

3. Alignment and Consistency

Alignment within an organization is created when everyone understands the vision, the goals, and the path to achieve those goals. To reach a wide understanding and alignment, a company must use clear and consistent language across the board: in requirement documents, technical design discussions, bug descriptions, and of course, formal documentation, sales, and marketing material. 

The product’s terminology leads the way to all the above, so it’s crucial to carefully define it before the designers or the developers start their work. 

You can count on your developers to uncompromisingly select the WORST terminology possible, which means, someone else should do it before they do... 

When we started Missbeez we outsourced the development of our MVP to a brilliant team with a lot of imagination. We probably failed to explain the essence of our business (beauty and lifestyle services on-demand) because somehow our ‘business verticals’ ended up as ‘folders’ and our list of ‘beauty treatments’ ended up being called: ‘features’ (WTF!??). Although those were only internal object names - they managed to mess up things and be very annoying. 

Once the database (or the code) includes the wrong terms - it’s very hard to get rid of them. They spread like viruses into technical documents, API functions, integration services, and before you know it - they are everywhere. Ready to hunt you down!

Now think about a new developer who joins the team, spends a few hours reading the formal documents, getting to know the right terminology, but then... then he spends the majority of his training dealing with the code and the wrong terminology… what terminology will he be using eventually? 

Developers are not the only ones to blame. I've seen far too many marketing materials suffering from inaccuracies and linguistic errors. When the different departments are not aligned - inconsistency strikes hard.

It’s a dead-end, and that’s why terminology should be defined top-down, by the subject matter experts, and be enforced across the entire company - to create alignment and consistency. 

4. So what should you do about it? 

Be fanatical about terminology. 

I believe it's within the responsibilities of the product leader (the founder, the CEO, the PM, whoever leads the product in the organization) to put terminology in high priority and lead the way.

Whether you're working on an advanced version of an existing product or trying out a Piecemeal/Wizard of Oz MVP - terminology is super important.

1. Start as early as possible 

Terminology should be determined as early as possible.
Start working on your glossary file side by side with defining the user personas, the business problem, etc. Make sure to have it ready before anyone else (who isn't you) starts working on things that cannot be easily changed later on (i.e. code, object model, etc.).

2. Use multiple sources to capture the right terms 

If you are not familiar with the terminology of your business - make sure to close this gap ASAP.
There are plenty of ways to do it:

• Find at least one industry expert to work with
• Read professional articles and blogs
• Interview customers or potential customers - they are your best source
• Join professional groups on Facebook, LinkedIn & Reddit
• Follow thought leaders on Twitter
• Explore your competitors - what terms are they using? 
• Explore potential partners - what terms are they using? 

At the end of the day, if you're going to develop a salesforce plugin, you better align with the salesforce terminology. If you're going to develop a machine learning algorithm for healthcare, make sure to align with the terms used by healthcare products (ever heard of DICOM, PHI, and PACS?).

3. Create a glossary: a terminology style-guide 

Designer use style guides, UX-Writers use vocabularies, developers use coding style-guides, translation companies work with glossaries, it's only trivial that all of those guides will inherit some guidelines from a cross-company glossary.

The terminology style-guide should be defined by the product leader and be used as the basis for all the other style-guides that come later. If there's a UX Writer in the company - make sure they are part of this activity.

Don't make it too long (or people won't use it).

See some more UX Writing, microcopy and text design tips every product should know about.

4. Be fanatical about using the right terminology

Once set, make sure everyone is onboard, review early design documents to make sure the right terminology is being used form the very first mile. Once it's there - the rest will follow more easily.

Share the product's glossary and guidelines with your outbound counterparts to make sure the material they produce is aligned. This will reduce the number of inconsistencies often found in marketing materials etc.

Don't forget to maintain this document as more features are added and the product evolves to new domains.

5. Think about sub-industries and local jargons 

Some sub-industries use different terminology. Some areas use specific jargon.
If your product requires that level of flexibility - make sure to properly define it and develop that capability in advance.
See my guide for building flexible products for more information - one good technique can be to load all the resources and strings remotely from the servers - based on the users' characteristics (such as location, organization name, market, etc.).

6. Get deeply involved with product demos 

In some companies, the demos are created by a dedicated team. Make sure you spend time working with that team to make sure the demo is aligned with the company's official terminology style-guide.

Make sure the personas used in the demo are not named after some Disney characters or Marvel superheroes.

- - -



Hope you found this post useful. If you did, follow me on twitter @gilbouhnick, or subscribe to my newsletter to get my occasional posts directly to your inbox.


Read next: How to maintain your product momentum when you’re out of development budget