Words Matter - ProductFTW #75

Picture this: You're on a launch planning call with your bank, your processor, and your internal team. Someone says "We'll be ready for alpha." Someone else says, "I thought this was beta." A third person asks, "So is this the friends and family launch?"

The bank calls the initial limited rollout "alpha" because you’re creating accounts in production for the first time. The processor calls the same phase "beta" because their alpha was the production setup and backend testing. Your internal team calls it "friends and family" because that's a common industry name for a first rollout. Nobody is wrong; you’re also not fully aligned.

Same launch. Three names. Suddenly, the conversation isn't about launch planning anymore, it's about translating vocabulary.

This is a small example of something I think about a lot as a product manager: language discipline. When people use different words for the same thing (or the same words for different things), the consequences can impact timelines, development, and trust between partners. Much of product work comes down to building shared understanding, and shared understanding is built (or broken) in the words we use.

Where It Gets Risky

In card programs, one of the places I see this frequently pop up is in flows of funds, especially around account naming and account structure. This is where language misalignment stops being mildly annoying and starts creating risk.

A warehouse lender, a program manager, and an issuing bank may all have requirements around where different types of funds are held and how they're allowed to move. Each party often shows up with a slightly different flow, different account naming conventions, and a different mental model of what each account is for. On the surface, the diagrams from each party can look very similar, but minor differences may reflect meaningful disagreements about control, obligations, or legal structure.

Without someone driving consistency in naming, the conversation gets bogged down defining things instead of resolving actual issues. This seems to happen often at exactly the point the program is trying to move fast to get to launch. In practice, that means someone (product) needs to create a unified flow that shows where each party's version aligns and where it doesn't.

Building the Translation Layer 

External parties are not going to adopt your terminology, or each other’s, and that's fine. The question is whether your team has a shared, written understanding of where the vocabulary overlaps and where it diverges, or whether that context only lives in the heads of a couple of people who've been on every call.

Product's job is to build the translation layer. That means asking partners early on in the process what they mean by terms you haven't heard before, getting ahead of common places where misalignments can happen, and flagging them out loud when they inevitably do. That usually means being the person in the room who says "Just to make sure everyone's on the same page…" and then providing the clarity that's needed. Also crucial: writing this clarification down somewhere everyone can actually find it.

How to Build the Habit

Anticipate where language will break.

While some of the examples above are specific to card programs, every project, whether cross-organizational or not, has communication weak spots. It can be phase names, status definitions, or even something as seemingly-simple as what “ready” or “done” means. Take note of where you see these happening on your projects so you can get ahead of them in the future.

Make sure everyone is aligned, and note where others use different terminology.

Often it's as simple as, "When you say X, what do you mean?" or, "Just to confirm, are we talking about Y?" If you're concerned that people will think you don't know what you're doing, be clear about your intent: "Thanks. I want to make sure my team knows what your team means so we can work together more effectively." Those small interventions clear things up in the moment, and over time they build a team culture where checking for alignment is normal, not awkward.

Document, document, document.

A simple table that maps your team’s terms to your partners’ terms is enough. The point is that the translation layer can’t live in your head and it has to be accessible to anyone on the team, especially the people who aren’t on every call.

Share it.

Put that table you made where people will actually look for it. Where exactly that is depends on your team. The best place might be in your project wiki, pinned in your Slack channel, or linked in your status docs. Wherever that place might be, make sure it’s there because a glossary nobody can find is the same as no glossary at all.

The key is to treat language not as a side concern, but as part of how product work gets done well.

About ProductFTW

ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.Same launch. Three names. Suddenly, the conversation isn't about launch planning anymore. It's now about translating vocabulary.