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.

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.

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.