.svg)
.svg)
You know you’ve read a good book when it sticks with you hours or days after you’ve finished it — maybe a specific image was so vivid you thought you’d seen it yourself, or a dialogue so realistic you remember hearing the words. Sometimes an idea resonates so deeply that you’re compelled to reference it in casual conversation, or less casually, in a morning stand-up meeting. I recently found myself coming back to an idea inspired by philosopher Richard Rorty: “to change how we speak is to change who we are.”
After hearing a group of engineers discuss the merits of a naming convention in our API, the quote hit me again. For my teammates, language had an impact on their code — and if they changed the language, the outcome of the code changed too. This insight got me thinking about how important language is for software product managers.
One of the most important responsibilities of the product management function at Ridgeline is to help create a shared vocabulary the Product team can use to brainstorm, architect, experiment, and execute. The Domain-Driven Design (DDD) framework has powered high-performing engineering teams since Eric Evans coined the term in his 2004 book of the same name. I’ve also found it a useful framework for PMs to structure their own processes of customer discovery, documentation, and meeting facilitation.
A Familiar Challenge
One of the key takeaways from Evans’ book is that the way a development team talks about its code base should reflect the business domain for which they are designing (and the customer workflows as the customer understands them). Many enterprise product managers have experienced the age-old conundrum, “What I think I said may not be what the engineer heard and probably isn’t exactly what the customer said in the first place.” In fact, within each of these stakeholder groups, you will frequently discover different definitions for the same words, with only context-clues to discern them. Especially in the enterprise space, where organizations — and industries for that matter — often have their own lexicon, gaining a comprehensive understanding of their key terms can be near impossible.
It usually isn’t anyone’s fault. We write requirements that (supposedly) use the same language that the customer uses to explain their problem, yet we somehow end up communicating opaque terms that get baked into schemas and functions. Before too long, an application contains generic concepts like “account” and “transaction” that happen to carry significant meaning at both a technology implementation and industry domain level. And you’re left running a scrum where everyone has their own unique interpretation of the requirement, and you probably develop something that gets the customer 60 percent there.
This can be fixed, but I think the solution requires a reevaluation of the product process from one of feature wish lists and assumptions to one where the customer’s words take on a deeper meaning, our requirements reflect the reality of their lived experience, and in turn, our solution achieves their desired outcome.
A Repurposed Framework
When our technology organization started rolling out the DDD framework, our meetings were filled with discussions about “this aggregate” and “that bounded context”. Though they were mostly engineering concepts, I wanted to understand the overall approach, so I asked my tech lead to break down one of our features in terms of DDD. They explained that the framework asks us to identify the major entities, relationships, and flows within a feature and then build the services and information flow based on business logic. We decided to prototype a reconciliation function that compared a firm’s transactional records to their custodian’s post-trade settlement records.
They reviewed my use case, a few notes from customer meetings, and some low-fidelity screens from the Design team before diving into an “event storming” session. The Ridgeline Products & Engineering team uses the principles of event storming to break down business processes into their smallest components and organize the actions, commands, and outcomes of the process. It aligns nicely with the DDD framework, because it asks the team to approach development with a laser focus on the customer’s language and how that translates into their code.
The developer on the project created a generic set of rule-based functions that compared, matched, and reported on broken records — and for the most part, the requirements were fulfilled!
But, as we tested the functionality with the customer, we realized that there were inconsistencies in the way we spoke about the process and the way the customer understood their job to be done, even though we had information directly from the customer’s mouth. Walking through a lightweight event storm at the customer’s desk, we located the points of difference in our understanding, and we were able to use more domain-specific language that more accurately captured their desired outcomes. In that moment, this previously engineering-focused framework became a Swiss-army knife in my product management toolbox.
Discovery
In this case, the problems were a matter of semantics — simply swapping out the words in the function helped us to articulate a workflow that the customer understood. However, this kind of miscommunication isn’t always a matter of language and can lead to more critical product mistakes and technology debt. We learned that using DDD during the customer discovery process provides a number of benefits:
• Encourages us to use simple language that the customer understands.
• Better explains the customer’s firm-specific or domain-specific language.
• Puts their outcomes front and center, leading to value-driven product solutions.
Almost every PM I know is looking for more ways to incorporate customer interaction into the development process, and this proved a productive and accessible way to do so.
Documentation
As we explored the business domain further and covered more complex customer problems, we found that our ability to communicate across services and teams was hindered by a lack of agreement on the language we use to talk about the product. A transaction can hold a different meaning across the application — from trade order management to portfolio accounting to reporting — even though the data object itself is 90 percent the same across all three areas. Not to mention that the term has a completely different meaning to engineers working in the data layer! Luckily, DDD accounts for this very real development challenge.
By defining the “ubiquitous language” that a specific product area uses and identifying the language that crosses boundaries, or bounded contexts as DDD refers to it, engineering teams can structure their cross-service communication around real-world information flows and business processes.
The key to keeping this language straight is an almost militant dedication to documentation. We strive to track the use of domain-specific terms across features, backend processes, and cross-platform initiatives. One of the simplest methods we’ve adopted has been the addition of a product glossary that captures our major entities and flows and is updated whenever a decision is made about core functionality. We can even potentially use this glossary as an artifact in client workshops.
A Ridgeline Approach
While we’ve seen real power in speaking a language that bridges technology and industry, the Ridgeline team still finds itself defining and redefining the glossary almost every sprint — but that’s the nature of early-stage development. The more you learn, the more you evolve the product. However, there is a marked difference in the care we now take to get to the heart of our customer’s language than before this approach. And with that care comes deeper customer empathy. At the end of the day, this is all a PM can ask for.
Product teams interested in testing the DDD framework might start with these three principles:
• The Domain-Driven Design framework isn’t just for engineers — it empowers all members of the product development process from product management to quality assurance.
• Create and advocate for a common set of terms that allow customers, industry experts, and engineers to speak the same language.
• Frame meetings around specific domain terms to stay focused on outcomes rather than discussions.
With DDD in mind, perhaps a more accurate version of Rorty’s idea might be this: to change how we talk about customer problems is to change how we build value-driven solutions.
Like all startups, our product management philosophy is constantly evolving. We love experimenting with new frameworks that keep our customers’ perspective at the forefront — and are always looking for bright, ambitious peers to help us do so. If that sounds like you, please get in touch.
