Skip to content

Problem-Solving Skills for Data Analysts

Solving data analytics problems often requires the expertise of multiple teams. And that means the path from problem to solution can get pretty convoluted. There’s rarely one right or perfect answer that works for every team.

This video teaches a structured, methodical process for finding a workable solution to complex problems.

You’ll learn how to:

  • Understand the full problem-solving cycle
  • Retrace your steps when you get derailed or blocked
  • Improve at both the art and science of problem-solving
  • Avoid “data puking” by answering the right questions
  • Document your problem and solution to save time on future questions

About the speaker: Ella Nguyen is an analytics leader who straddles the line between technical and strategic. She has served as the Digital Analytics Association Chicago Chapter Leader and a board member of MeasureCamp San Francisco.

Hi everyone.

Thank you for joining me on this talk as we go over some of my favorite problem solving strategies that I use every day as a consultant at Bounteous.

Before I take a deep dive into this topic, please allow me the opportunity to introduce myself.

My name is Ella.

I am part of the experience practice Development or XPD team at Bounteous which is essentially an R&D department.

Our mission is to develop delivery programs and processes from our tech solutions that require the effort of multiple teams.

An example of this are customer data platforms.

To fully leverage the value of a customer data platforms, we would need to assemble a cross capability teams that include members from the data engineering, the data analysis and the data activation team.

As you can see, we love solutions where the applications are limitless.

From my description of the X PD team, you can deduce that I essentially spent a lot of my time figuring how to solve problems that require the expertise of multiple teams.

As a result, the path from the problem to the solution can get pretty convoluted because there often isn’t one right or perfect solution for the problem at hand.

What I want to share with you today is a process for finding solution.

As I go through this process, a lot of you will recognize that you’re already using some of these methods, if not all of them.

The reason I present them to you in a structure way is because I want to emphasize the importance of being methodical when you are solving a problem, especially a complex one.

When you follow a process, you can easily retrace your steps when you find yourself derail or block.

Let’s get started.

Let’s start by looking at the problem solving cycle, its entirety, starting with the first phase, which is to define the problem so that you can understand the problem.

Surprisingly, this is often a major barrier.

Whenever you find yourself at a loss in trying to solve a problem, it is likely that you don’t know what you’re doing, what you’re solving for in the 1st place.

Trying to remember an instance when you were stuck in a problem and sought help from another person, did you notice that just by describing the problem to this other person, you somehow gained clarity and knew what you were supposed to do next?

It is because by describing back to them the problem, you finally understood what it is that you’re trying to solve for.

After defining the problem, the next step is to break it down into manageable chunks.

There are two reasons why this is important.

First, it allows you to leverage your team members expertise efficiently by allocating them to the appropriate subset of the problem.

Second, it allow you to create specific and well defined goals, giving you the ability to both monitor progress and to step back and reset and reassess how each component fits into the greater whole.

Once you have all the pieces of the solution, you can start to string them together into different combinations, resulting in multiple potential solutions for the problem.

At this point, you should pick the best solution possible based on the current situation and execute it lastly sharing the results.

It’s an important phase of the problem solving cycle because it allows you to reflect on what you have learned, identify common problems and pitfalls.

In the future, when you encounter similar problems but with differing details, you will know how to approach them.

There you have it.

This is the problem solving cycle.

It’s an entirety.

Before we move to the next step, I want to emphasize that problem solving is a science well as an art.

By approaching a problem in a structured way, as I’ve outlined here, you will learn how to be more efficient.

However, much of the process depends on a nuance and attention to detail that can only come with experience.

Much like a master baker who know exactly when the bread is ready to be put into the oven, the experienced problem solver develop an intuition intuition of exactly how to break down a specific problem or properly implement a solution.

As with any art, the only way to get better is to keep challenging yourself.

With that in mind, let’s take a deep dive into each phase.

The first step in the life cycle is to define or understand the problem.

This is arguably the most important phase.

One of my first assignment as a consultant was to help a client understand how successful their newly redesigned website was.

The website initially was a technical space.

It contained many useful articles and attracts students, engineers, academic, etcetera.

However, they needed a marketing site and so they underwent A rigorous redesign to attract the right type of audience, IE the people who make the decision to buy their product.

So the first task I was asked to do was determine what are people doing this site.

You can see where I’m going with this story, right?

Of course, the next thing I did was build a fancy report with top 10 pages, bottom 10 pages, page depth, time on site, content, velocity, whatever metric you can think of, I create beautiful tables and graph it.

Don’t worry, I didn’t create any pie chart though.

Essentially I was data puking.

I present the visuals, receive a lot of oohs and aahs and great jobs.

Months later I find out that the report only has been looked at twice.


Looking back, it was quite obvious that it’s not that this was not what the client wanted to know.

I should have dug a little deeper and asked questions such as what would the client do if I told them the homepage has 70% of all page views and gauge their response to understand what information they were really after.

There’s a happy ending to this story.

Eventually I did figure out that the client really want to know if the right audience was finding their site and finding that the content is relevant.

The answer was no because acquisition strategy at that time was to drive prospects to a gated content page, then connect the prospect directly with sales when they complete a form.

Sales was doing the vetting and qualifying, not the interaction with the site.

I share with you this story because I want to demonstrate that by knowing if the problem you’re solving for it’s the right one.

It’s an important discovery that you will make as you try to understand and define the challenge.

So before you start digging through the data, ask yourself if you’re asking the right questions.

Over the years, I learned that the format that I outlined here on this slide worked best for uncovering the heart of most issues.

I will talk more about the first method, clarifying the problem by asking questions.

This is a really daunting task.

How do you know what to ask?

All the literature implore you to ask the right question, but what are those?

It’s important to realize that your client are often too immersed in their own expertise and that they will not be able to predict exactly what you need to do, what you need to do your job.

You have to be ready to help them give you the right information.

To help you ask the right questions, I recommend that you acquire domain knowledge.

I’m not talking about the analytic tool, which is important too.

I’m talking about learning the industry that you’re analyzing.

What is the best practice in that industry?

What are the goals and challenges?

What are the important metrics?

What are the benchmarks for those metrics?

The more you understand the under industry, the better you will get at asking the right questions so that you can do the right analysis.

The next step is breaking down the problem into manageable pieces.

If you are at an early stage of your career right now, you may find this step tedious and might be tempted to skip over it.

But as you advance in your career and get better and better at solving problems, you will be asked to solve much more complex ones and you might find yourself overwhelmed.

I certainly did.

The more practice that you have with this step, the easier become to breakdown complex problem.

This phase has a lot of art to it.

Design on exactly how to break down a problem can be challenging.

I can’t outline the exact step for you to follow.

However, it can be helpful to use a framework so that you can break down the problem in a logical way.

For example, I like to think through each data problem using the analytic life cycle framework because we’ll help you break down the problem in a very specific way.

In general, the analytic framework is an approach for transforming data into knowledge for the purpose of decision making.

I will not go through the entire framework here, but if you are interested in more detail, the DAA has a lot of resources that explain the specific of this framework.

The first thing I do is identify where the problem lie in the framework.

Is it an analysis problem?

Is it a data problem?

If it’s an analysis problem which is later in the analytic life cycle, you must ensure that the previous steps such as data collection and data integrity is done correctly before you can begin to tackle the analysis.

Let’s walk through an example.

Consider this common act from a content team.

What type of content is effective at converting prospects?

Oftentimes the content team asks these type of questions so they can better prioritize their writers workload.

You can start to break down the apps into logical pieces starting with the first part of data analysis, which is do you have the data that you need readily available?

If yes, you can move on to determine which visuals would be best to describe the data.

If not, how would you get that data you needed?

A few years years ago I was asked a similar question and when I was inventorying the data for analysis, I found that the client was not collecting the type of data I needed to answer the question clearly.

Using this discovery, I was able to build a case for revamping data collection to reflect business needs and thus ensuring that we have good data.

So by breaking down the problem I am solving for one piece and pushing the other pieces that won’t belong.

The next step after defining the problem and breaking it down is to implement a tactical approach to form solutions to each component.

The final goal here is to gather a number of multiple solutions that can be strung together into a variety of combinations.

When I’m in this phase, I generally have an idea of where I should look for answers, and I usually start by looking at similar problems that have been solved in the past.

As is often said in academic circles, a few days in the library can save a few years in the lab.

Fortunately, this adage also hold true for Google searches, which make our lives significantly easier.

One of the best resources for this phase are the blogs of the experts in the field, and often these are the 1st place I start looking for ideas.

In addition, Internet message boards, discussion groups, also varying in quality can often serve as a great way to broaden your repertoires of solutions by providing leads and vetting ideas.

Furthermore, if you organize, if your organization encourages vigorous documentation, which it absolutely should, you essentially have a treasured trove of past learnings that you can dig through.

We will talk a bit more about documentation in the last phase of the cycle.

Although it may sound obvious, communication with your team is an essential component of this stage.

It allows you to tap into diverse expertise and pool of prior experience.

Make sure you are fully utilizing the resource available to you.

Of course, the problem you may be facing may be entirely novel.

If you find yourself facing a particular troubleshooting issue with one of your components, first take a step back to our second step and see if you can break this component down further.

Also, attempt a change in approach in perspective.

For example, working backwards from a solution can be very helpful.

Finally, reach out to the experts directly.

However, I want to leave you with this caution.

Be judicial, judicious.

When you seek expert advice, you need to come prepare, otherwise it is likely that you will not get the result that you’re looking for.

I’d like to use the S bar approach, a communication method developed in healthcare.

S bar stands for Situation, Background, Assessment and Recommendation.

Give the expert the specifics of the issue you’re facing, a bigger a bit of the bigger picture, your assessment of the problem, including things you have done and try, and most importantly your current recommendations.

In other words, your thought process as to how you are thinking of approaching the problem.

This avoids the unilateral of what I should do and show the expert that you are actively engaged in the issue at hand and are not just punting your problems to them.

Finally we all come that we all come that problems loaded with our preconceived notions and assumptions.

These are inescapable, but it is important to recognize this limitation, push yourself to actively question your assumptions and to always dig one layer deeper.

Doing so can be extremely difficult and takes a real concerted effort, especially in the hectic and fast-paced work environment where our attention is being constantly diverted.

But if practiced consistently, this approach will pay dividends in the future by arming you with a wealth of knowledge and experience that will help you tackle both current and future challenges when you reach this step, If you devoted enough time to the previous three-step in the problem cycle, this step would not be that hard.

I find that the greatest barrier to during this phase is to have the technical know how to execute the solution.

However, because I have devoted the right amount of time in the previous three-step, I already know what I am looking for.

For example, I can easily ask a JavaScript expert to help me write code for a particular difficult implementation if I already define the parameters.

Similarly, I can ask a visualization expert how to create a visual in a tool such as Tableau.

If I already know what visual I can, I need to create to answer the questions.

Lastly, at this stage of the life cycle, you may be tired of the problem you have lived and breathed in the last couple of days or weeks.

Depend on the complexity of the problem, you managed to find a solution that satisfy your stakeholder.

All you really want to do is close this chapter and move on to other pressing concerns like the items on your To Do List that have been on hold since you were focused on this issue at hand.

However, if you take half an hour to an hour, document the problem and solution, it would be a great resource later on for you and your colleagues to ensure that the documentation process is as easy as possible and encourage the process.

I recommend that you create templates in Confluence or in Google Docs that you can copy and fill out such similarly to a form.

The documentation can contain basis for describing the problem, the solution of the problem, and the resolution.

The documentation process accomplished two things.

It allows you to reflect on what you have learned and how you can approach it better the second time.

The 2nd is you now have a written record of solutions that you can draw upon if similar problems appear.

Bonus You can save a colleague time when they’re solving a similar problem because it’s already been solved before.

So there you have it, the process that I used to approach problems solving to approach problems that I’m tasked to solve.

And I want to leave you with two last thoughts.

First, when I presented the Problem life, the problem solving life cycle in its entirety, I had mentioned that the problem solving is both a science and an art and you will be better as you gain experience.

As this cartoon shown, the only way to gain experience is to practice, go around and look for opportunity to solve problem, ask the business team for questions that they may have and see if you can translate the data into information that they can use to answer their question.

Most of my experience are gained from solving random questions that people ask during conversation and not because my supervisor has specifically asked me to solve the problem.

Second, there are here are some readings that I hope you will find as enjoyable as I have.

The resource here are not how to books with step by step guide, rather they are reflection by the authors as they examine some of the most complex problems.

I find that it’s best to learn by following the logic and thinking of these masters and to emulate them as they apply them to my everyday workflow.

So thank you for spending this time with me.

I hope you find it useful.

About Digital Analytics Association Content

The DAA, a membership organization dedicated to fostering community, advocacy, and professional development for data analytics teams, ceased operations in May of 2024. Much of the evergreen content the organization created and curated will live on thanks to the Content Marketing Institute. Note: As the DAA content ages, links may break and presenters' titles may change, but the concepts remain sound.

Browse the DAA content archive.
See the latest analytics content from CMI.
Learn about the 2024 Marketing Analytics & Data Science conference.
Join theĀ Digital Analytics Society group on LinkedIn.