Data Leaders, It’s Time to Try something Different to Succeed—Design Thinking

Data Leaders, It’s Time to Try something Different to Succeed—Design Thinking

Insanity is doing the same thing over and over again and expecting different results.
—Albert Einstein

While there appears to be widespread corporate acknowledgment of the importance and value of data to competitiveness and innovation, there is still relatively limited success in implementing data-related projects. A recent survey by NewVantage Partners shows that over 77% of executives report that business adoption of Big Data and AI remains a challenge. This percentage increased from the previous year, indicating attempts to fix this problem are not working and projects are becoming even less likely to succeed. This is just one of many surveys that demonstrate that a large percentage of these projects are not meeting expectations. In addition, critical data technology foundational programs with no direct ROI, such as master data management and data quality, struggle to get or continue funding.

Looking at this lack of customer and stakeholder support through a product management lens, you have to start asking, “are we developing the right products?” and “why aren’t our customers excited about these products?”. One of the techniques commonly used in product development to address these questions early in the lifecycle is called Design Thinking. Perhaps it’s time for Chief Data Officers, Chief Analytics Officers, and other Data Leaders to start looking at this methodology to improve their products’ adoption.

Why Design Thinking?

When following the Agile methodology, high-level requirements are captured in User Stories. These stories form the basis of the backlog and subsequent development work. The development of User Stories is led by a Product Owner who acts as the voice of the customer and represents their interests. However, there often are critical pieces of missing information. While the User Stories describe what features the customer wants, they usually do not specify how they plan to use them and how they fit into the broader strategy. Without understanding these components, it’s understandable why adoption can suffer. Improving this adoption and developing innovative ideas is where Design Thinking comes in.

Design Thinking is a process that you can use in conjunction with Agile, Scrum and Lean. It is a robust process that concentrates on what to build and how to incorporate the product to solve a problem. It emphasizes the human elements of the requirements. For customer-driven projects, Design Thinking helps generate user stories and backlog that more closely align with the root cause issues and aspirational goals.

“Design thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.”
—Tim Brown, CEO of IDEO

When dealing with other types of programs Data Leaders routinely are responsible for, such as business analytics, AI or data management programs, CRISP-DM – the CRoss Industry Standard Process for Data Mining – is one of the popular methodologies to use. It also has the same deficiency as Agile. It addresses what the customer says they need, but not to how they will use it. It may falsely identify what problem to solve. There is also a high risk of implementing a solution that is not readily operational.

Design Thinking 30,000 Foot Primer

There are many different interpretations of the Design Thinking methodology. For our purposes, I look at it as four main stages. They are:

  1. Developing profound empathy for the customer
  2. Ideation with an appropriate group of stakeholders
  3. Rapid design and experimentation through multiple iterations that provide learning
  4. Implementation and storytelling

Design Thinking is not a linear process, but a series of feedback loops that cross different phases to form an iterative approach. It seeks to identify alternative strategies and solutions that might not be apparent with the current level of understanding. Below are two different representations of the process that I find useful.



The first stage focuses on developing an understanding of all of the probable customer segments and defining the problems they are trying to solve. Furthermore, the process elicits what a good solution would look like, how it could be leveraged by the various users, and what are the constraints and conditions in which it must work. In this stage, you also look to understand the experiences and motivations of the target customers, exposing the “why” and not just the “what.” The second stage brings together representative groups of stakeholders for facilitated brainstorming. The team develops problem statements in human-centered terms. Typically, visual and interactive techniques are used throughout this phase to help grow these understandings. The third stage consists of rapid prototyping and experimentation. These prototypes sometimes need not be more than paper mockups to trigger valuable reactions and inputs from the users. The important part is to test, gather user feedback, and test some more. The fourth stage is where you implement the ideas and concentrate on user buy-in. However, since this is an iterative process, this is not necessarily the last stage. In this stage, you create Minimal Viable Products (MVPs) and pilot them within the organization. You also incorporate insights discovered in your design thinking process to your business or operational model. This is a stage where methods like Agile can complement the process.

When Design Thinking is successfully applied, it

  • Captures the mindsets and needs of the people who will use the solution.
  • Paints a picture of the opportunities based on their needs.
  • Leads you to innovative new solutions starting with quick, high-level experiments that provide learning and gradually increase in maturity.

Sustained use of design thinking will improve user adoption and will also lead to more innovative products.

Applying Design Thinking to Data Projects

Every product or service delivered by the Data Leader’s team has customers. Sometimes they are explicit and obvious, such as when developing risk models or production reporting for specific business functions. Other times it’s not so clear, such as building a data lake, executing master data management, or launching a data quality program. However, wherever a project is on this spectrum, there are ultimately a set of users who are going to need to use and adopt the product deliverables. Using Design Thinking where empathy, ideation, and rapid experimentation are part of the process will undoubtedly better achieve the customer’s actual goals and improve acceptance.


Through techniques such as interviewing and observation, the design leader develops an understanding of all of the different subsets of stakeholders and how they are involved in the ecosystem. The goal here is to understand what really matters to each customer and the opportunity they are trying to optimize.

A Data Leader’s organization has a very diverse set of products and customers. Internal users include business analysts, data scientists, risk modelers, application developers, product managers, compliance officers, and pretty much everyone in the organization. Anyone who uses data or systems requiring data within a company is a customer; it’s hard to think of someone who does not.

The Data Leader many times also has direct external customers, being responsible for data integrations with their parties, monetizing of data assets, and other customer-facing deliverables. For Design Thinking, it’s essential to identify the customer who will use each product or service and fully understand how they will relate to your products.

Some of the information that gets documented as part of this stage include:

  • Personas—A summation of features about the different classes of customers.
  • Problem Statements— How each persona relates to the project as well as their respective motivations, hindrances, and tolerances for change.
  • Environment— What does the current data look like? Which systems are they using, and what processes are already in place?
  • Design Evaluation Criteria— What does success look like?

When a specific request comes directly from a business user, an excellent technique to start with is the “5 Whys”. You keep asking questions until you can fully document the nature of the user’s request, which potentially could be more than five questions. An example looks like:

  1. “I need a report”—Why?
  2. “I need to see these data”— Why?
  3. “It will help me determine profitability”—How? (not a Why but close enough)
  4. “I’ll combine it with other data I have in a spreadsheet”— Why?
  5. “Because I can’t get an aggregated view of the data I need”— What data is that?
  6. …and so on

Let’s take another example of the development of a Master Data Management (MDM) program. I have to admit that I have been guilty in the past of what I have seen in most of the MDM project I am aware of— there is little understanding and empathy for a large number of the expected user groups. Although most programs take into consideration the functional requirements of Data Stewards and maybe one or two other sets of stakeholders, for the most part, they are designed for operational efficiency of the CDO-type group. They don’t create the program with empathy for the casual report writer, the GDPR analyst, or the underwriting modeler. These users don’t want an MDM system; they just desire access to usable data to do their jobs. Left ignored, they will likely become reluctant users of a system foisted upon them instead of enthusiastic advocates that embrace the system to assist in their workflows.


Once you have a clear understanding of the problems to be solved or the opportunities to capture, this next stage focuses on determining what to build and how it could work. Facilitated brainstorming that includes participants from all customer segments is used to “Go Broad to Go Narrow”. The “Go Broad” leverages divergent thinking to create choices, while “Go Narrow” uses convergent thinking. The use of storyboards, problem statements, point of view templates, and other tools can assist in this phase.

Another term for this stage is “Expansive Thinking” because instead of trying to design just one perfect solution, the team is asked to look at the problem for all conceivable angles and get many possible solutions. A technique also used during this phase is “10x Thinking”, which challenges the team to think beyond solutions that would create an incremental benefit—such as 10% -, and strive for those that would make a substantial benefit— such as 10X!

For the Data Leader, using this technique can help identify different solutions, mixes of projects, or prioritize how these solutions are delivered. As I mentioned above, most customers don’t want a Data Lake, an MDM system, or even a report. Their end goals aren’t even self-service data access. They want to be able to make some type of fact-based decision, deliver a product, or take the best action. If the delivered products or services don’t directly address one or more of these goals for a customer segment, they will not view the project as a success.

Therefore, the optimal user-centered solution might not be a full implementation of one tool or project, but a composite of subsets of a few different tools. Data Leaders need to change their perspective from implementing a data governance tool, implementing MDM, or implementing advanced analytics. The products need to look out from the users’ viewpoint and how it helps them with their goals.

Design and Experimentation

There’s never been an easier time for CDO and CAO organizations to perform rapid and interactive experimentation. X-as-a-service providers, open-source libraries, and pay as you go models enable quick and easy access to relatively inexpensive resources to develop prototypes and other experiments. Even if the target product can’t use this same environment due to regulatory or other issues, as long as sanitized, non-production data is leveraged, there is minimal risk.

The team can experiment with potential solutions, like how the MDM proposed solution will interact with the reporting tool to give a user their desired result. Another example is how data arrive into the organization and becomes available to trigger an action that can be operationalized. Note that these need to be rapid, very high-level prototypes at this point.

It’s critical during this stage to have users involved and provide feedback. Feedback must focus on feel, not merely function. Not just how it may fit into their process, but how it promotes a sense of value beyond operational purpose. Simply, does it make them feel good? Empathy has been one element that is mostly ignored in these types of projects but is a significant driver in user adoption and success metrics. This feedback gets fed into another phase of the process as necessary.


Once you decide what to build and have the first usable version of your project, you begin to operationalize the solution and create a continual improvement cycle. Therefore, it’s critical to monitor usage and navigational metrics to determine effectiveness. This creates an environment where usage and performance feedback can be acted upon quickly to continuously advance the product’s design.


Chief Data and Analytics Officers can increase their effectiveness and adoption rates by adding Design Thinking methodology elements to their organization. Better understanding the motivations and processes of your customers will promote the development of more innovative and usable products. Combining Design Thinking with other system development methodologies lets you keep a focus on the question – Are we really building the right thing in the right way?

Data Leaders should incorporate tools like Empathy Maps, Storyboards, Problem Statement POVs and others into the program development and execution process. Design Thinking concepts are not very difficult, and there are plenty of resources available. You don’t need a new role on the team, just some additional skills.

Give it a try; the current methods apparently aren’t working too well. It’s time to do something different to get better results.

Andrew Sohn – 2019-10-13

1 Comment
  1. John Doe

    His verterem consectetuer consequuntur ne, no virtute atomorum usu. Eu quo nemore causae tacimates, eos viderer persequeris an.

Comments are closed.

Friends of isCDO