Vocabulary
Develop the words that define what is needed — the shared language your operations are built on.
I have spent sixteen years watching teams build software before they could agree on what to call the thing they were building. The invoicing team and the billing team meant different things by “customer.” The word was never written down, so every API, every schema, and every conversation quietly encoded a slightly different version of it. Discovery starts here, with words, because the words are the cheapest thing to get wrong early and the most expensive thing to fix later.
When I do vocabulary work with you, I sit with your teams and pull the language of your operations out into the open — whatever your business actually runs on. We name things once, define them plainly, and write the definitions down where everyone can see them and argue with them. Not a taxonomy handed down from an ivory tower — a working vocabulary your teams recognize as their own.
The goal is not a glossary that rots in a wiki. It is a shared language your interfaces, your standards, your policies, and your stories can all point back to. When the words are settled, everything downstream gets cheaper and calmer.
What you walk away with
- A documented, versioned vocabulary of the terms your operations depend on
- Plain-language definitions your business and engineering teams both agree on
- A single place — a Git repository — where the language lives and evolves
Related reading
Let's work together
If you are building on top of words nobody has agreed on yet, that is exactly where I like to start. I would love to talk it through.
