In many companies, the data analytics/BI team is seen as a background team, separate from Product Design and Product Engineering. They inherit production data as it’s copied to a data warehouse, and they build reports from it based on requests, but they often don’t get to drive design. That’s a mistake.

BI teams naturally discover a lot about customer behavior as well as internal staff needs. These discoveries are information for another facet of product strategy and innovation. Close the feedback loop – include BI in planning discussions for new features. They will help Design teams remember to ask “What reporting does this feature require?” And, they will also spot places where workflow design influences analytics and reporting capabilities that are a value-add for the customer, such as completion status recording and reporting, time-to-completion and ROI metrics, error handling workflow reports, and possibilities for the predictive power of data.

Because the reporting team is deeply involved in cleaning and querying the data, they’re also the front lines in the battle for data quality. They know where the trouble spots are, they know the history of the legacy systems, and they know which data is painful to use. Most data quality problems need to be solved at the source, rather than patched after the fact; patches just add more tech debt and more fragility to an already stressed system.

This means that the reporting team’s information about data quality pain points needs to go back to the production engineering teams who own the sources of that data. They may make their own decisions about whether to consider it tech debt to handle, rewrite with a new feature, or do a data migration to integrate historical data with fresh data in a cleaner data model. But either way, they do need to hear about the issues and the relative priorities of data quality concerns.

While a product engineering team owns the source data, they are responsible to a variety of stakeholders for making that data valuable, reliable, and timely. Stakeholders include:

1. Customers, who are paying us to address specific needs with our services and products;
2. Internal department leads, who handle the internal business workflows involved in serving customers;
3. Business strategy and product design leads, who need to know which product areas are well-used or struggling; and
4. BI teams, who need to build out warehousing, reporting, and predictive models using that data.

This means that, as a downstream consumer of the data, BI is also a stakeholder to Product. They should be included in decisions about data and API models, historical data migrations, and event schema designs. They need information about priorities and sequencing, the same as any peer engineering team would, to plan their own roadmap and workload.

Data warehousing, data reporting, analytics, and predictive model needs should be considered as part of the project specification for a new feature or product, to ensure that all stakeholders and all related work is considered during planning. This means the project specification template (or epic, or story concepts, or design) must include questions such as:

1. Consider what data this feature produces. What reporting will the customer need to see from that? What reporting will internal staff need for workflows that service the customer, and which staff members?
2. Does this feature need to collect or use PII? How do we know that we’re done with the customer’s data for a given request, and therefore it’s valid to delete per GDPR and data expiration policies?
3. Does this data indicate an important user clickstream activity, such that it can tell us something about customer satisfaction or frustration? How do we know if our new feature is working well versus poorly?
4. Does this data have the potential to feed a predictive model or KPI that helps us track success rates or improve outcomes?
5. Does this obsolete any other data or processes we have, or will existing reports need to be modified to match, as of a certain release date?

Taking data into account during product design gives a more robust product and a more complete picture of who all the stakeholders are for a new process. It helps us to identify all downstream users, including the workers who will use internal reports to service customers directly on a daily basis. It greatly reduces last-minute requests to secondary teams with work they weren’t anticipating. Sometimes, remembering that customers will need reporting over the data the feature produces even results in changes to site navigation and visual presentation of the feature. In some cases, the report itself becomes the anchor or starting point for navigating the feature.

Data science can be involved, too. They can analyze clickstream and customer satisfaction data, creating behavior prediction and customer satisfaction predictive models, which help ensure that customers are happy to stick around. They can discover KPIs and test them mathematically, contributing to reports that go back to business leaders in every department to help inform their progress.

Data and Product are partners in the design of software that serves customer needs. Close the feedback loop; include the data analysts/BI teams and their collaborators in the Product Design planning and engineering discussions. They have a lot to add and find a lot of value in listening, as well.