Can a data analyst become a business analyst? Yes, Here’s How

A career in data is a good idea these days. Workers with data and similar analytic skills are expected to grow by 31% from 2019 to 2029 according to the U.S. Bureau of Labor Statistics. But data analysts aren’t the only ones looking at data, and their skills are in high demand across a growing number of jobs. A very popular example is business analysis.

This article discusses the transition from data to business analysis. We’ll look at how to do it, as well as the importance of requirement elicitation, documentation skills, and domain knowledge in the transition.

Can a data analyst become a business analyst?

Yes, a data analyst can become a business analyst, as long as he/she is prepared to learn business analyst skills which include requirement elicitation, documentation, and industry-specific (or domain) knowledge.

For the most part, a data analyst already has the requisite technology and logic skills to perform the business analyst function. For example, they are good critical thinkers, are good at data cleaning and interpretation, and understand coding logic and agile methodologies.

However, most data analysts need to learn requirement and documentation skills, as well as how to integrate domain knowledge into their work. The latter can be particularly difficult, since data analysts usually rely on statistical and numerical independence to provide unbiased results, rather than relying on domain-specific knowledge to find solutions.

How does data analysis help in business analysis?

Of course, a data analyst needs to learn new skills — we’ll cover those below. But more importantly, data analysts bring some serious value to the table with the skills they already have.

In short, data analysis helps BAs understand and validate the efficacy of proposed projects and features.

To understand better, we need to know what business analysts do. In short, they work on three steps:

1. Requirement elicitation
2. Validating efficacy of the solution with descriptive and predictive analysis
3. Delivering the functional and non-functional requirements to achieve the product goal

Let’s get the easy ones out of the way. Requirement elicitation, #1, is a way of understanding what the product needs to do and how it must perform. Delivering the functional requirements, #3, is a question of execution — the actual implementation of the determined needs.

Validating with data, however, is the way in which business analyst with deep data skills can determine if the provided requirements are a good idea. It helps the company save time and money by avoiding mistakes and pinpointing opportunities.

Imagine you work in a wholesale watch company that wants to launch a new product: a luxurious pink watch targeted at working women. Luckily, the company has a huge database of customer purchasing habits. With a simple cluster analysis, you could identify customer profiles that are most likely to buy the product and investigate what kinds of watch features they like. By identifying these data clusters, you help the product by showing what is most and least likely to work.

Of course, business analysts can always create tickets with the data teams to understand the solution, but this is an interdepartmental dependency that slows things down. BAs with data skills get projects moving faster. In industries where time is of the essence, it can mean the difference between success and failure.

How can a data analyst become a business analyst?

The good news is that you won’t need to get a special degree to become a business analyst. In fact, you may not need any special training if you’re already familiar with how tech companies work (agile framework). Instead, you’ll just have to self-learn a few hard and soft skills. We’ve already highlighted some, but here’s a longer list with explanations.

Hard Skills

1. Requirement elicitation. Requirement elicitation is the process of gathering functional and non-functional requirements about a product from all stakeholders involved. You may need to understand, for example, what the product needs to do for the customer from a business team, and what code must be used to create it from a technical team. BAs then summarize these requirements with the product owner in a short text called the “Product Goal.” Common stakeholders include:
   • Company direction (CEO, owner)
   • Business leads (product owner, sales manages)
   • Technical leads (CTO, senior developer)
2. Documentation/Technical writing. Documentation is the process of writing down requirements and the steps used to achieve those requirements. It’s about communicating through various medias and finding the best way to convey an idea. Key components include:
   • Clarity, concision, and precision. Documentation should never be fancy. It should be clear to the point that everyone involved understands exactly what the writer intends. It should be concise so that nobody spends too much time trying to understand. It should be precise so no information is missing, and there’s no ambiguity.
   • JIRA and confluence knowledge. When we say “document,” you probably think about Microsoft Word. But that’s not the way business analysts store their records. Instead, they use special software called “corporate wikis” that keep all records stored in light-weight pages located within a single platform to which all employees in an organization have access. Confluence is one version of these wikis. JIRA, on the other hand, is a software ticketing system in which tasks can be assigned to individuals in technical departments. Together, corporate wikis and ticketing systems allow business analysts to keep themselves and their teams organized.
   • Use of pictures. Pictures are an underutilized medium, but they bring huge value to communicating ideas. Whether it’s a graph, model, or simple drawing, BAs use pictures to show their teams what needs to be done.
3. UML Diagramming. UML stands for Unified Modeling Language, and it’s purpose is to provide a standardized way of visualizing the design of a system, in most cases a software or hardware system. It’s a skill that not all business analysts have, but that can really set you a part. UML modeling is, in some way, a technical literacy, and technical teams will appreciate you knowing it.

Soft Skills

1. Speaking software developers’ languages. Perhaps one of the biggest obstacles facing business analysts today is the gap between technical teams (developers) and non-technical teams (business, including BAs). In short, technical teams typically focus on the quality of the product they build with little regard to its commercial success, whereas business teams focus on how well it performs its Product Goal, which is usually making money.
2. Interpretation & reading between the lines. There’s a famous quote by Steve Jobs that goes “A lot of times, people don’t know what they want until you show it to them.” This is true for business analysts. They hear “wants” from several players on a regular basis, but those people often don’t know what they want. The ultimate skill is interpreting what people say, and reading between the lines to decipher what results will please not only the company, but also the customers who consume your product.
3. Domain knowledge. Domain knowledge is nothing more than deep knowledge of the ins and outs of the industry in which you work. This doesn’t mean only understanding how the technical, product-linked of the industry — but ALL of it. These are all questions you should be able to answer in detail if you have strong domain knowledge. And having it will make you that much better at fulfilling the specialized role you play as a business analyst.
   • How do your customers perceive value?
   • Who are the up-and-comers? The longstanding incumbents?
   • Who are the company’s suppliers? How dependent are you on them?
   • What new technologies could disrupt the way you do business?

What next?

If you’re convinced, you may be wondering what to do next. A good place to start is reading through articles on BAs, which will help you get a better understanding of the ins and outs of the role. At AnalystAnswers.com, for example, we have a whole section of the website with free content on business analysis. Thanks for reading!