THE PRODUCT MINDSET IN ACTION: BUILDING A DATA PRODUCT CAPABILITY
Analytics has long been touted as the answer for organizations floundering in a sea of data. But internal data solutions have often fallen short for a variety of reasons. External offerings have a far better track record, which is why thinking of data as an asset and data analytics or data delivery as a product can help companies ramp up the value they derive from their internal solutions.
We see significant payback when companies build internal analytics solutions with a product mindset. It’s an approach that will help ensure your analytics answer the most important questions and drive desired outcomes. But doing it once in one corner of the organization only goes so far. How can companies adopt a product mindset consistently, so that it is embedded in the fabric of the enterprise? The key is to develop a data product capability.
Organizations with a data product capability are able to strengthen the connection between the development of internal analytics products and the delivery of ongoing, long-term value. Because they have taken the time to develop a moderndatastrategy , they have a scalable framework for collecting, gathering, structuring and processing information. And because they treat information delivery as a product, they are continually on the hunt for ways to improve it and harness it for better decision-making.
In our experience, there are several critical steps to developing a data product capability. While these may sound simple, they require companies to make some significant changes to how they view and develop their internal data analytics solutions.
UNDERSTAND AND SIMPLIFY THE DATA LANDSCAPE
One of our large retailer clients was managing its merchandising operations on a legacy data platform that provided no analytics capabilities whatsoever. The company was maintaining multiple data feeds, more than 600 standard reports, 1,200 tables, and some 800 views. As a result, there was considerable confusion. For example, it turned out that the same metrics were being reported differently in different reports, leading to head-scratching mismatches and conflicts over data integrity.
In addition, the company’s internal customer team was juggling countless ad hoc requests for different types of reports, dashboards, and other forms of support. They spent all of their time reconciling the differences in various reports and trying to fulfill these new ad hoc demands, versus developing valuable insights to improve decision-making. The ongoing barrage of requests for data tools also meant continual re-inventing of the wheel.
It was clear that before attempting to build anything, we would need to get a handle on what data different groups were using, why they were using it, how it was being fed into the system, and a broad range of other questions.
To be sure, such a discovery process can take time, but it is central to a product approach to solution development. Understanding end-user needs–from manufacturing to sales and marketing–is essential to determining what the final solution will look like. Furthermore, asking the question “why are things so complicated?” is what puts you on the path to simplification.
The simplification process includes cleansing the data, defining key metrics, and streamlining the various data sources. Once the data landscape has been simplified, each metric will have a single definition for all stakeholders, and each will reside in a single place that multiple parties can access when developing solutions. Having a single source of truth for every metric gets rid of the data mismatches that occur when developers build ad hoc extraction mechanisms.
CREATE A SCALABLE DATA PLATFORM
The platform is where a company’s data strategy hits the road. Building a data platform allows organizations to create solutions repeatedly and quickly, leading to faster and better decisionmaking. The platform is the foundation on top of which all of the subsequent tools and technologies are built. Because the customer- or end-user-facing tools are all built off of the platform, this approach ensures that all of them are tapping into the same analytics layer, and there is no need to build an extraction mechanism from scratch for every solution. The platform enables the organization to take more of a “plug and play” approach to solution development.
With a robust data layer, solutions can be built on top that then distribute out information to individual groups and teams with diverse sets of problems and needs.
The good news is, it is not necessary to build out the entire platform before tools can be built on top of it. Rather, you start with a core set of problems or decisions that have to be made –these are your highest value products. You can then iterate, strengthening and deepening the data layer as additional stakeholder needs emerge or rise to the top of the backlog. For example, we worked with one manufacturing company that was maintaining separate data platforms for different functions, resulting in inconsistent reporting and sub-optimal decisionmaking.
Our goal was to move to a single cross-functional platform, but we started with financial and operational data for one division of the company, building the platform so that data from other areas could be continually ingested. The next release of the platform will be for a separate division, meaning we will be augmenting the same platform to create analytics for this new team. The icing on the cake: The stepped approach to developing the new platform has allowed savings from each phase to fund subsequent phases.
BUILD THE RIGHT TEAM
Developing a data product capability means taking a structured approach to how resources are allocated and prioritized, as requests for different solutions flow into the internal customer team. No more grabbing the nearest business analyst and asking them to build you a dashboard for inventory in the East Coast warehouse. Developing a data product capability also means establishing specific roles and responsibilities for each team member.
In some larger organizations, the team responsible for building the data platform may be different from the team(s) building the various solutions sitting on top of it. Nevertheless, it’s important to keep teams as small as possible when filling the roles below. If there are more opportunities to drive value, then create additional teams, not larger ones:
Product champion: While some of the roles listed here may already exist in the organization, chances are this one does not. The product champion is not the project manager. Rather he or she is a strategic linchpin for the entire process—the individual who decides what products get built, and when—based on the company’s data strategy (not the clamoring of individual stakeholders). Product champions are also accountable for ensuring the solutions developed deliver value to the organization, which is one reason why they have the authority to decide to pivot as different or better valuecreation opportunities emerge.
Project manager/team facilitator: The project manager, not surprisingly, is responsible for maintaining the project schedule, budget, and scope and making sure everyone on the team understands their responsibilities. In an Agile or hybrid environment, this individual may also assume the role of an agile coach, and will usually be the scrum master. This is a more traditional role, but nevertheless an important one.
Platform architect: The architect is responsible for designing the platform, with a focus on simplification. The architect provides guidance and development expertise on the ingestion, transformation, and structuring of the data from source to target, and ensures the data feeding into the platform is accurate and clean.
Platform engineer: The engineer is in charge of building the platform, specifically developing the code that transforms the data from source to target for consumption by the visualization tools that sit on top of the platform.
Visualization developer: The visualization developer builds the consumer end products, such as tools and dashboards.
Business analyst: The BA liaises with the business to gather and communicate business requirements. The BA is also responsible for quality assurance testing.
The primary benefit of organizing roles in this way—and particularly thebenefitof separatingtheprojectmanagerfromtheproductchampion is that product strategy now drives the team’s priorities, and team members can focus on what they do best. The product owner makes sure that strategy alignment stays on track, while the project manager keeps individual initiatives running smoothly.
Companies that commit to developing a data product capability can not only realize big savings in terms of development hours for individual solutions, but they will see significant improvement in the quality and efficacy of their internal data analytics. Armed with better tools and dashboards, all drawing on the same datasets, leaders will be able to make more rapid, informed decisions that deliver measurable and sustainable value to the business.
David Mobley
Chief Practices OfficerDavid.Mobley@aspirent.com
Howard Chalmers
Principal & Product Management Leader
Howard.Chalmers@aspirent.com
Mark Hodgdon
Principal & Senior Client DirectorMark.Hodgdon@aspirent.com
ABOUT ASPIRENT
Aspirent Consulting partners with the world’s largest organizations to simplify their most complex analytics and digital product development challenges—helping them cut through the complexities that slow progress, stifle innovation, and limit growth. Through a mix of proven frameworks, experienced teams, and unbiased technology expertise we deliver clientspecific solutions that simplify and speed the path to success. Learn more about us at www.aspirent.com
COPYRIGHT© 2023 ASPIRENT. ALL RIGHTS RESERVED. WWW.ASPIRENT.COM