Last week I talked about the importance of domain knowledge. I asserted that if you are building, supporting, or selling something, that it was important to understand the domain that you were working in. Otherwise, you would face challenges. 

But that’s the ideal use case. What about the pragmatic reality of the situation, where this is not true? The reality is you or your team may not have the contextual knowledge of what it is you’re building or supporting. So now you are in a situation where you have to work through that. What can be done about it? Well, here are a couple of things you can do.

Create a one-pager

Assuming that you have at least some people on your team that have contextual knowledge, task them with putting together a one-page document on the contextual knowledge. This needs to be quick and succinct and provide some contextual knowledge on the domain. A format that works well is when the top of the document is a list of bullet points that talk to who the customer is, what the business goals are, and similar high-level items.

In addition, a set of frequently asked questions is also valuable. Try to think of the top typical questions that might be asked. Talk with the team, or with the subject matter experts, or even some trusted customers, about the common questions that might come up either when you are working with the product, or that the customer might ask you. Then have some simple answers ready to go, even if the answer is just acknowledging the question and telling the customer that you will get back to them on it.

A crash course

What this means is, find some YouTube videos, some online articles, some books, some self-directed training courses, and take some time (not a lot of time, just a couple of hours), and learn what you can about the domain. I know this sounds simple, but as I’ve stated before I have worked on teams that did not even do this simple level of self-education on the customer and domain they were working in. This is a little bit more detailed than a one-pager, but it gives somebody on your team the opportunity to at least understand a little bit about the customer, the business, the domain, and so forth.

For example, let’s say the software your team is building is a web-based application designed to help electricians and plumbers schedule and plan their jobs. I’m sure you can find plenty of YouTube videos for a professional plumber or electrician showing you a day in the life of their work. And this will help you learn some important things. Do they mostly work out of cars and trucks? Do they stop a lot, for example, at a coffee shop, so they can study and prepare for the next job? Do they usually work after dark, or in the rain, or only when it is daylight? Do they usually have laptops with Wi-Fi access points, or just cell phones, or tablets? A little bit of research will help you gain a lot of contextual knowledge of what your customers are looking for.

Reverse shadowing

This is not the easiest answer to implement, but it might be the answer that works the best. And that is that you might need to just have somebody knowledgeable with the domain as their primary task. This might be having one or two people that have a strong understanding of the domain, and it’s their job to be present in all the customer-facing meetings, even if it’s just in the beginning and in certain events to be able to establish trust, foster communication, and correctly gather and understand the key requirements and design specifications. But if you’re going to use this method, then other members of the team must attend and pay close attention and start trying to learn as much as they can about this customer and business domain.

All of these methods still require that you recognize the importance of understanding your customer’s business domain, and being intentional about taking the time to learn and understand the domain. Because as we’ve discussed, if you don’t understand the business domain then how can you delight your customers and give them what they need?