Analytics Roadmap & Business Strategy Misalignment


Your analytics roadmap isn't all that aligned with your overall business strategy.  Don't fret - it seemingly happens to everyone.  But how do you spot it?  What should you do about it?  We recently hosted the first webinar in a series focused on the Top 5 Pitfalls to Avoid When Developing Your Data Science Team.  In this first webinar, we talked about the alignment between business strategy and data science/analytics roadmaps, how to spot a misalignment and a few techniques to achieve much improved alignment and, thus, a better business outcome.

See the webinar in full in the video below.  

If you’d rather read than watch, here are the cliff notes...

First, we discussed the path from data to value (as shown below) and how important it is to overlay a strategic filter on that path to make decisions around:

  • What data should you use?
  • What types of insights are you looking for?
  • What criteria should you use to prioritize actions arising from those insights and how should they be executed across the organization?
  • What areas of the company’s business have the greatest potential for value creation?

Path from Data to Value

Path from Data to Value

Without that strategic overlay, you are basically leaving your ultimate results up to chance.  Yes, you might end up delivering something, but the chances that it will align with your strategy and deliver significant value to the business are slim.  In a recent post in HBR, Thomas Redman argued that without a means to monetize, which he defined as “how you plan to use analytics to create business advantage and then execute”, companies will derive little business benefit out of their data.

So, what are the symptoms of this strategic misalignment?

  • Overbudgeted Projects - Projects delivered late and over budget
  • Missed Business Outcomes - Projects that are ultimately completed but don’t actually deliver on the business result expected from the project
  • Poor Customer Satisfaction - Customer issues caused by poor quality in the data, models, etc.
  • Misaligned Teams - Out of synch teams with some redundant work and generally not aligned in the direction needed to deliver great business results
  • Low Team Morale - The above issues cause churn within the team and ultimate reduce team morale

Together, these symptoms lead to the delivery of suboptimal business value.  Potential causes of these issues can be directly tied back to a lack of strategic alignment:

  • Unclear business need - Without clarity in the business needs and outcome expected, the project is like a boat without rudders, going whichever way the wind blows.  There’s no “true north” so to speak, guiding the project
  • High requirements churn - Again, without this clarity, there will likely be tremendous requirements churn, causing significant rework, ultimately leading to late and over budgeted projects.
  • Misalignment of metrics and poor decisions - In leadership, you often get exactly what you incentivize.  With ambiguity in the direction of the the project, its very difficult to set metric targets that are true measures of your success, thus you likely end up managing and incentivizing the wrong thing.  
  • Models directed at the wrong outcomes - With ambiguity in the outcome you are pursuing and a lack of clarity in the data you are using and the insights you are gleaning from that data, there is significant risk of error in model selection, model validation, etc.
  • Uncoordinated efforts across teams - it’s difficult to imagine having teams aligned and rowing in the same direction towards an outcome when that outcome isn’t clear.

The solution is simple, just take your mission, vision, and strategy, and map that down through your company-wide and team objectives and voila!  

Mapping Strategy to Action

Mapping Strategy to Action

Ok, ok, admittedly that’s not as simple as it sounds.  One thing that occurred to me recently is how similar these challenges are to the challenges faced by our colleagues in product and software development.  With data science and analytics being somewhat of an emerging field, product and software development has the benefit of experience and is a bit more mature in some of these practices.  Mind you, my background is in product and software development and we didn’t exactly have all of this figured out, but I do think there are a few things that segment of tech does well that we can learn from.  Below are a few that are particularly relevant to the issues at hand here.

Recognize the strategic value of product management and invest in it

It seems this role is not as prevalent in the field of data/analytics as it is in the product development world.  As we talk about mapping strategy to action/tactics, however, it’s relatively common to have product management own that function, or at a minimum at least be actively involved.  Product Managers have that great analyst mind and are adept at asking “why?” until they uncover the strategy reason behind something.  They typically have a cross functional skill/mindset and understand and empathize with customers, have a strong grasp and understanding of business strategy, and also are aware of what’s possible technically.  That’s exactly what’s needed here!  

The Essence of Product Management

The Essence of Product Management

As an aside, the common Venn diagram for the data scientist role represents a good data scientist as one that sits at the intersection of the Business, Computer Science, and Math.  Great, that should be super easy to find!  Ok, maybe not.  Instead of beating our head against a wall trying to find those unicorns with great tech/math skills and also great business skills/knowledge, why not embrace the value of product management and pair strong product managers with strong technologists/data scientists?  

A couple of must reads on this topic are:  

Inspired: How to Create Tech Products that Customers Love 

Monetizing Innovation

Consider organizing around product owner teams

I can hear you now - the description of product managers above is just as unicorn-like as the description of a data scientist, and I tend to agree.  Relying solely the product management function to represent customers, the business/strategy, and also what’s possibly technically, seems a bit unrealistic.  A great concept I learned from Jeff Patton on the product development side of the world is Product Owner Teams, consisting of Product Manager, who in Marty Cagan terms represents what is valuable, a technical lead, who represents what is technically feasible, and a designer, who represents what is usable.  If you are struggling decomposing your strategy into an action plan, consider forming a small swat team comprised of 3 roles (I’d choose mid-level leaders):

  • Product Management
  • Data Science / Analytics leader
  • Design / Visualization

Product Owner Teams - Adapted for Data Analytics

Product Owner Teams - Adapted for Data Analytics

Focus on the problems that need to be solved rather than digging into extreme details of solutions.  Have the conversations both top down driven (from the strategy) and also bottom up (from new technologies and ideas coming from the team) so you are sure to flesh out what’s possible that you aren’t thinking about.  Ask why, why, why... (i.e. start with why) so you truly map to both the strategy and also what the customer cares about.  Don’t forget to leave some room for experimentation - in many cases open ended analytics without a clear strategy can lead to discoveries that you wouldn’t have expected and positive disruptions of your business model (innovation), so make room for that.  Just don’t make that your entire plan and strategy.

Leverage OKRs for goal setting

I’ve found OKRs to be an excellent and lightweight goal setting framework for ensuring the work of teams is aligned with the overall strategy and objectives of the company, particularly when compared to more traditional goal setting approaches.  Here are a couple good resources describing the OKR approach and value:

Favor lean canvases over business plans for articulating the “business case” for your projects

It’s a bit odd that we write some of the longest documents about our approach to projects when we know the least, which is at the beginning.  Business cases are great examples of really long documents full of detail but we often forget that the detail is typically based on a number of assumptions, many of which we have little confidence in.  The Lean Canvas (a derivative of the Business Model Canvas) is a much lighter-weight but still very valuable approach to capturing your strategy in a way that considers the business model, the customer value prop, the problem you are solving, the proposed solution, etc.  Consider implementing the Lean Canvas and using the time you get back experimenting around the assumptions so you can validate or invalidate them before you get too far along in the project.

Lean in to transparent progress updates across the organization

Favor transparent communications of progress over just having closed door "management" status meetings.  That helps teams see each others work, which will be much more effective at surfacing any dependencies you aren’t considering and/or any potential synergies you might have between projects.  Beyond that, it helps the entire team see how the work of each sub-team connects together to deliver against the broader vision.

Think big, implement small

Consider working in small iterations vs. big bang projects delivered many months/years later.  Given that we’re talking about issues aligning your analytics roadmap with the company strategy, working in small iterations and then discussing your results transparently gives you ample opportunities to course correct and re-align with the strategy before you’ve gotten too far and wasted time and money.

There are certainly other techniques I didn’t include above (or that I'm not familiar with!).  I’d love to hear your thoughts about the techniques above or others that work well to align tactics with strategy.