Moving from interesting to actionable analysis
Have you ever worked on an analysis that stretched on for weeks, maybe even months? You put time and effort into producing some great insights. Then everybody patted you on the back for your amazing analysis. Period. That was the end of it.
No actions were taken from the insights you produced, and there was no impact on the business. Your beautiful analysis went on to sit in a folder unseen by anybody ever again. Let’s name this folder “the analysis morgue.” It contains more moribund analyses than it ought to because this scenario represents a common problem with data analytics teams, and by experiencing it you are not alone.
But there are ways to avoid it.
Understand the problem: The “What,” “Why,” and “Who”
The first and most important step in this process is being in the same virtual head space as your business stakeholders. When a stakeholder approaches you with a request for analysis, or when you’ve identified the need for one, start by building a common understanding of the “What,” “Why,” and “Who” as it pertains to the analysis.
What: Start with the goals of the business and the decisions that business stakeholders drive daily. Identify their relation to the analysis, and the actions the analysis is expected to drive.
Why: Identify the reason for the analysis. Is there an actual impact expected beyond just addressing an interesting question? Knowing this enables you to build a hypothesis and understand what the output of the analysis should look like so that it drives the decisions that business stakeholders need to make.
Who: This question is key but is typically considered secondary to the analysis — and yet it’s just as important. Who will take the actual action as a result of the analysis may not be the same as the business stakeholders who are driving it. Ensuring that those responsible for taking action enter the discussion early on is crucial to avoiding a result with insights but no action.
Note that a lot of the groundwork outlined above is related to the specific “action” the business intends to take based on your analysis. Your business stakeholders might not have considered these questions, and that is fine. But as the one doing the analysis and wanting it to make an impact, you must.
The business may not have the answers right away. Part of your initial effort around asking these questions can in fact be very helpful to business stakeholders in helping them think through how they can proactively use what you provide to drive impact in their area, instead of thinking of it solely as providing a retrospective understanding of their business. In many cases, the questions posed above will not only help you pick the right analysis, they will also enable your business stakeholders to think harder about the problem they are trying to solve.
Identify the actors and contributors and build a cadence
Once you’ve asked the questions and gained an understanding of the business problems, the next step is to identify and categorize the stakeholders who will enable you to deliver an analysis with impact. These are stakeholders who will:
- Help you with the analysis.
- Ensure your analysis continues to make business sense, and not go in a direction that is irrelevant to the business.
- Take the action.
If your project is specifically focused on finding insights to drive a strategic business decision or action, it is important to understand from your business stakeholders the strategic decisions currently under consideration. As you start the analysis, consider that while your stakeholders may be relying on you to indicate the action to take based on the data, they may have their own opinion about which business action will be most useful — or even doable.
Using this information to drive an initial hypothesis is key. The opinion informing the hypothesis might come from stakeholders’ experience in the field, or from anecdotal feedback from their subordinates, peers, or managers. As the data scientist, you can start to form a hypothesis by considering some of the business actions your stakeholders are contemplating and then testing them through an impact or sensitivity analysis. This provides an added benefit by enabling you to recommend improvements.
As important as it is to have those who will take action involved in the analysis from the start, it’s also important for them to be part of the ongoing cadence of the project. This helps to build consensus. Additionally, if the project is going to require time to converge into a set of outputs and actions for the business, consider having interim reviews with business leadership where your leadership is also present. This helps to ensure agreement on expectations and can help overcoming roadblocks when necessary.
Deliver, but don’t start with something complex
Business stakeholders spend a lot of time going over the problems and opportunities in existing and new business processes. They rarely get a chance to formulate the specific business problems that can be directly addressed through data science. As a result, when a data scientist engages on a new business problem, there’s likely to be a lack of clarity around the data, analysis, or ML Model that can help. Address this ambiguity by working with your stakeholders to break down the larger business problem into smaller manageable chunks, and then brainstorm a few prototype solution designs to zero in on a minimal viable product. These steps can help:
- Identify initial likely wins: Sit down with your stakeholders and understand the business problem in detail. Then ask what they think data science can deliver in the short term (think weeks rather than months). For example, if your stakeholders want to “growth hack” every stage of the customer journey, perhaps you can start by focusing on typical problems occurring at just one stage, identifying relevant insights and opportunities from historical data that addresses those problems. Succeeding at a smaller scale builds your credibility among stakeholders while helping you understand the domain a bit more, preparing you to tackle a larger portion of the problem.
- Focus on an MVP: Once you and your stakeholders agree on where to start, decide next on an MVP (minimum viable product). At this stage, keep the MVP simple. For example, let’s say your stakeholders want you to build a recommendation model and integrate it into an existing line of business application. You can start by decoupling the recommendation model from the overall engineering integration. The recommendation model becomes an MVP that you can deliver in the next two to three months. Once you have validated the relevance of the recommendations with your stakeholders, you can host the model output temporarily in an Azure WebApp, allowing your stakeholders early use and enabling them to provide feedback for further model tuning, all while you focus on building the entre integration pipeline.
- Scope stakeholder feedback into future iterations: Set expectations with your stakeholders early on that feedback from the model tuning stage, unless business critical or breaking the MVP, will be scoped for a future iteration. The goal is to be agile with the process and not try to deliver something perfect right at the first, making the deliverable better with every iteration as you and your stakeholders continuously learn from the experience.
Before jumping to build that beautiful but potentially unusable analysis, take a step back, know the decisions you are trying to influence, and identify the stakeholders who will take the actions so you can bring them into the project. This takes longer but allows you to prioritize your projects to avoid wasteful work and drive maximum impact.
But remember that even if you follow all these steps, some ideas you and your business stakeholders advocate may take some time for the overall business to embrace. That’s the time to recommit to a growth mindset, learning what you can for the next project.
For further help in understanding whether you are working on the right problems, and how you can effectively communicate the value of your work to your business partners, consider reading this great article called “Study your domain” by our colleague Matt Wright.