Domain Knowledge is Overrated

Sep 11, 2016
7983 Views
7 Comments
28 Likes

Visit any active discussion forum for business analysts and aspiring BAs, and invariably you will find at least one thread asking how to develop domain knowledge, either in a new industry, such as health or insurance, or a new business function, such as marketing or supply chain management. Alice just got a job working for the first time in financial services, and is worried that her lack of experience in this domain will get in the way of her doing a great job. Bob keeps getting his resume ignored for analyst jobs in government agencies because most of his experience is in ecommerce applications. What to do?

Because of the vast number of industries and domains I explored over the years, from government to innovation startups, B2C ecommerce to healthcare and social media management, I know that domain knowledge is not a pre-requisite for getting the job or performing well in a BA role. As business analyst with a history of delivering results, you can be highly successful defining requirements for solutions in an entirely new field.

The best approach to use to achieve superior results in a new business domain will vary depending on what challenge you’re currently facing. Is it trying to secure a job interview in an industry you don’t have any experience with? Overcome the imposter syndrome and establish yourself as a valuable team member while still learning a new business domain? Avoid feeling incompetent or overwhelmed with the amount of information you don’t yet know about the new business process you’ll be working on?

In Parts 2 and 3 of this series we’ll tackle the first two challenges. In this first article let’s deal with the latter issue:

How not to feel incompetent or overwhelmed when changing industry or business domain (Part 1)


Tip #1: Embrace the “rookie mindset”

In the book Rookie Smarts: Why Learning Beats Knowing in the New Game of Work, Liz Wiseman describes how being a novice can be an asset and lead to better results, especially in work that's innovative in nature. According to her research, overall, inexperienced people tend to outperform people with experience by a small margin. But where they really outperform is when the work is innovative in nature: rookies are capable of achieving results a lot faster than people with experience. And one of the chief reasons is that novices tend to seek advice and input from a variety of sources, thus getting exposed to many more data points and diverging ideas than experts, which makes them much more open to new possibilities.

This is exactly what happened when I took a lead BA position in the healthcare industry. Even though I started from zero knowledge about things like quality of care indicators and patient handover processes, not only I developed domain knowledge very quickly, but my level of ignorance about the industry and business domain actually helped me develop better solutions for my user groups, which included healthcare executives, nurses, and patients. The applications built based on my specifications received high praise from end-users, and in the case of a system meant to improve the efficiency of the management of hospital beds, caused an influx of requests to IT to speed up the implementation in hospitals on the wait list based on word-of-mouth among the nursing staff.

How is that even possible? Remember, a good question beats a good answer. When I started working in healthcare, I looked for opportunities to talk to anyone willing to spend time with me, from hospital housekeepers to the chief nurse. One of the people I interviewed was an unconventional doctor with new ideas on how to help physicians avoid making a mistake while interpreting lab results. A BA with more experience in healthcare might have found it enough to write requirements for a new patient records system based on what he already knew about the domain plus a couple of interviews with key stakeholders. By making a point to gain exposure to as many sources as I could, I ended up finding a great opportunity to introduce a more intuitive data visualization method to help doctors avoid the risk of medical error due to misinterpretation of patient lab results.

As you start a new project, whether you’re already familiar with or new to a business domain, make a point to surround yourself with people with different perspectives on the problem you’re trying to solve. Taking this approach will help you look at situations more holistically and examine issues from all perspectives, which in turn yields ideas for more creative outcomes. As an industry or business domain novice, by adopting this “rookie mindset” you’ll find yourself making larger contributions than any specialist alone would be able to achieve.

Tip #2. Get smart about how you absorb information

Imagine trying to learn everything there is to know about “financial institutions”, or even a niche domain like “bond syndication” during the course of a project. There is no way you’re going to absorb all the available knowledge about your new domain in such a short period! Instead of trying to drink from the fire hose, focus on answering a single question:

What is the one vital piece of information I need today to make progress?

In one of my healthcare projects, I was writing the specification for a “quality of care dashboard”. There was a large number of “quality of care” metrics that needed to be collected and monitored (from acuity index to changes in patient cognitive function). It was pretty clear that if I tried to develop a deep understanding of each of these indicators, I’d never finish writing the requirements in time for the project to stay on schedule. My first vital piece of information was to understand for whom we were building the solution (care teams composed of physicians and nurses). Next, to clarify the desired outcomes for the solution (allow the intended audience to monitor patient care, identify trends, and promote timely interventions to ensure the best possible health outcomes for the patients being treated).

Later, the vital pieces of information I needed were, “what patient data points need to be captured in order to produce all the required metrics?”, “what will be the best sources for the data points that need to be collected?”, and “what types of reports and alerts are going to be most effective for the care team to act upon this data?”. By tackling these questions one by one, while accepting the fact that I wasn’t going to become an expert in quality of care metrics during that project, I was able to deliver more value to users than if I had been a specialist in care metrics who wasn’t following a structured process to investigate the real need. My job was not to learn what each individual metric meant, but rather ensure we were focusing on the right metrics, and defining actionable charts and reports that maximized the results of the care team decisions.

When you start to feel overwhelmed with the amount of unfamiliar business terms, or worried that your lack of industry domain expertise will keep you from making valuable contributions to your team, ask yourself, What is the one vital piece of information I need today to make progress?

Focus on getting that vital piece now so you can keep your project moving, and trust that your ability to ask good questions will benefit even the experts who will have to think about the process being investigated as they prepare their answers.

Tip #3: Break out your narrow frames so you don’t become a victim of your past successes

Every solution is great in some circumstances and terrible in others. As you’re learning about your new domain, and following tips #1 and #2 to get exposure to different ideas, you’ll start forming an opinion about what approaches will work best for the problem you’re trying to solve.

The risk here is to stay attached to your trusted playbook of norms and best practices from your past experience. You may develop a blindness that will prevent you from seeing more viable options, or make you ignore facts that suggest you are on the wrong path. As you read a report, you may start glossing over the parts that contradict your beliefs. As you talk to someone with a different perspective of the problem, you may begin thinking about what you want to say before they’ve even made their point, rather than truly listening to find the holes in your current thinking.

I’ve witnessed a talented business analyst who had been very successful in determining requirements for invoicing systems in the credit card industry fail terribly after shifting to the telecommunication industry. Her mistake was to reuse what she knew to be true about invoicing in her previous industry while ignoring relevant information about the salient differences between billing customers for purchases they made using a credit card and for phone calls charged based on call duration.

Luckily, it’s possible to avoid the trap of holding too tightly to ideas and concepts from your past. The trick is to stay curious, humble and open, actively seeking out views and opinions that differ from your own, and looking for ideas that actually go against what you know to be true. Here is a useful question to guide your thinking, based on the premortem technique:

Imagine it’s one year after the release of the solution you’re working on. The solution turned out to be terrible. What caused this catastrophic failure?

The reason this question works is that a huge enemy of good decision-making is “confirmation bias,” which is our tendency to seek out information that supports what we want to be true (“our solution will be a huge success”), rather than go hunting for discomfirming data. This question compels us to look for contradictory information, increasing our chances of finding a potential deal breaker for our idea before it can cause any damage.

Example: One of my projects was an application whose job was to send out notifications to customers of a financial company. Such notifications could be anything from a notice of system scheduled maintenance to a marketing message highlighting new features coming soon. Stakeholders wanted the ability to schedule notifications so they could be sent out on future dates and times. On a first glance, this seemed like a great idea to improve the efficiency of the external communication process. I had worked in other notification systems in the past that supported scheduling, and everything seemed to make perfect sense. However, by doing a premortem and asking ourselves what would have made the solution a disaster, we were able to come up with a scenario that spelled trouble:

Imagine that a promotional message was scheduled days in advance to announce an upcoming release that would give customers a capability they had been waiting for. A couple of hours before the notification was issued, a system failure causes customers to lose revenue. The notification system is used to communicate the outage and explain what is being done to recover the system. While waiting for an update, customers receive the celebratory message that only serves to aggravate the recipients and cause even more damage to the company’s reputation.

With this scenario in mind, rather than rejecting the idea of scheduled notifications altogether, we designed an additional feature to make sure that when an unplanned outage happened, any pre-scheduled promotional notification would be placed on hold and require manual confirmation before it was released to the public. This turned what could have been an solution with high risk of negative impact to business into a valid enhancement that simplified the company’s external communication process.

# # #

Even the most talented expert can get trapped into the same points of salience, the same causal relationships. Their mastery may end up causing them to produce the same kind of resolution every time, even when the context demands something different. When you’re trying to learn a new business domain, and experiencing feelings of incompetence or information overload, remember that with the right mindset, you can actually increase the odds of your team quickly finding a creative resolution to the problem at hand. Use the 3 tips described here, and the next time you are in a meeting discussing how to fix a big business problem, as the person with the least domain knowledge you may find yourself coming up with a new angle that has the experts in the room saying, "huh, I've never thought of that!"


Author: Adriana Beal, Product Management & Business Analysis

Adriana Beal has developed a successful career in business analysis and product management, having lead the investigation of business problems, defined winning solutions, and written requirements documents for a large number complex software projects. She is also the coach of Crafting Better Requirements, a program that has helped hundreds of business analysts improve their requirements documentation and communication skills, and the author of the ebook Measuring the Performance of Business Analysts, which has been adopted by dozens of BA managers interested in improving the performance measurement systems in their organizations. Her most recent ebook, designed to help BAs struggling with getting the right information to analyze and use to specify their solutions, is called Tested Stakeholder Interviewing Methods for Business Analysts.

Like this article:
  28 members liked this article
Sep 11, 2016
7983 Views
7 Comments
28 Likes

COMMENTS

teslim balogun posted on Wednesday, September 14, 2016 9:54 PM
Interesting Piece..true
donotcross03 posted on Wednesday, September 14, 2016 10:18 PM
Adriana, it is a shame we are not getting you at IT Arena this year. Great article. I was a bit skeptical when I started reading it because I do value domain knowledge a bit. But at the same time I think your article is not just about lack or significance of domain knowledge.

The way I understand your key point is having the rookie attitude and being open to all opportunities and sources of information. Not just relying on industry best practices and prior knowledge.

If I understand correctly you are talking about a set of principles that a BA should apply regardless of domain they are working in:
1. Accept I as a BA won't become a SME unless project runs for years and therefore my task is to figure out the right questions other than just accumulate knowledge. Basically anywhere I go I start from my scratch and my head is tabula rasa in terms of problem I am supposed to address
2. Question a lot of things if not everything - best practices, current practices, information noise
3. Keep eyes and ears open - listen to different sources without forgetting about point 2
4. Don't assume without stating assumptions or validating them

Thank you for this article

Vlad
adrianab posted on Thursday, September 15, 2016 7:59 AM
@Vlad:

Perhaps next time it will work out for me to go to the IT Arena! And Thanks for the great summary in the form of a set of principles.

Like you, I value domain knowledge, and believe we should all strive to to develop it. What we want to avoid is stagnation, which will happen if we decide we already know a business domain enough and stop learning, or, in the other extreme, give up on learning a new field entirely because it's too complicated or will take years to master.

As usual, the virtue lies in the middle. We must accept that our knowledge as BAs will always have some limitation (because we are not our customers or end users, and therefore will never have the same level of understanding of their jobs, problems, and constraints), and keep asking good questions to attract more perspectives, surface more possibilities, and enlist more help--regardless of how much we already know about the problem space we're working on.

In my opinion, domain knowledge is overrated because of the amount of importance recruiters and hiring managers place on it, when the bedrock of all change and creativity is not having the right answers, but rather knowing the right questions to ask to uncover the real problem to be solved.
ryanmilligan posted on Thursday, September 22, 2016 3:39 PM
This is why it's so important for a BA to enter every new project with a systems-based mindset. I used to be a consultant, and every client I worked for was in an industry/domain that I had no prior experience with. It didn't matter, however, once work started on designing a database or creating wireframes, because variables are variables, business rules are business rules, and process flows are process flows - the verbiage is replaceable but the concept doesn't change. I don't think the expectation would be for a someone new to the team to immediately familiarize oneself with the "why", but rather the "what" and "how". Good business analysts will ask about the "why" as they make progress, and communicate effectively enough with business partners to the point where domain knowledge will gradually be acquired without even realizing it. It's at that point where you also become a thought partner and an incredibly valuable asset for the stakeholders.
Dtbanks posted on Thursday, September 22, 2016 9:33 PM
Hi Adriana!

There is domain *knowledge* and there is subject matter *expertise*. The former is prerequisite for business analysis, whether it be priori or acquired upon joining the project. The latter is not only overrated by employers, but also a burden to the problem solver just as you explained.
adrianab posted on Thursday, September 22, 2016 9:54 PM
@Duane:

We seem to be in agreement. My point here is that even domain knowledge is often overrated, with many hiring managers and recruiters making it a non-negotiable requirement to move a candidate forward when, like you said (and many of us have proven over and over), it can be acquired upon joining the project.

I'm also of the opinion that domain knowledge (even without expertise) may create blind spots for BAs who aren't careful enough to keep challenging their beliefs.

@Ryan:

Indeed, the focus on "why" is often what differentiates high performers from mediocre BAs.

Thank you both for leaving your comments!


wilco.charite posted on Monday, July 24, 2017 4:39 PM
"a good question beats a good answer. When I started working in healthcare, I looked for opportunities to talk to anyone willing to spend time with me, from hospital housekeepers to the chief nurse. One of the people I interviewed was an unconventional doctor with new ideas on how to help physicians avoid making a mistake while interpreting lab results. A BA with more experience in healthcare might have found it enough to write requirements for a new patient records system based on what he already knew about the domain plus a couple of interviews with key stakeholders".
Beware: Experience promotes Routine -> Talk to as many people as possible, however much experienced you are!
Only registered users may post comments.




Latest Articles

The Crucial Art of Pre-Project Problem Analysis
Aug 13, 2017
0 Comments
Business analysis is a broad discipline and we have a whole range of tools and techniques at our disposal. We may get involved within projects, but al...

Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC