Issue #28 – The Data Product Deep Dive (Part 3 – How to Build Them)
Defining the operational process to building Data Products effectively
Read time: 18 minutes
Have you ever built a data product for your business stakeholders?
Do you notice that often they want something super bespoke and unique…
…Even though something that does 80% of what they want already exists?
Yup, this is a problem. The thinking that we need a bespoke, new thing every time.
And unfortunately data teams work this way, often building from scratch and creating new products with an unscalable approach.
We need to change this perception. Thinking from a ‘the business is always right’ or the ‘end user knows best’ mantra is 60% correct but forgets 40% of the equation. Namely, (1) business stakeholders don’t know how to build data products (or much about data and analytics in general), and (2) end users don’t care about scalability; they care about what they get right in front of them.
So today, we will break it down and explain how to build production-ready data products with a proper delivery process. Buckle up, data friends!
The Right Data Product Mindset
In a previous issue, we defined data products as tools or solutions from which end business users can draw insights and make decisions.
This idea is crucial. Products that provide insights to business stakeholder decision-making (like dashboards, models, reporting tools, AI products, etc.) are the products, and the data that feeds them are raw materials. These raw materials are processed and curated to enhance the value of the end products that business stakeholders use.
However, companies haven’t found a suitable delivery model for these products.
The classic waterfall process doesn’t identify the evolving business needs, and shouting agile repeatedly without implementing the proper processes doesn’t work.
Moreover, data products are more complex than regular material products—data raw materials are constantly shifting and evolving, requiring an operational delivery model that considers this variability.
This idea differs from material products, whose raw materials are quite static. Even technology products are built on software principles that only shift when updates are pushed through.
So I believe organisations need to adopt a certain mindset, or set of principles, before building data products:
Adopt a value-first approach – Data products are about outcomes, not outputs. Start with the business outcome you want to achieve, not the data or technology you want to use. Every data product should enable users to solve a specific business problem or capture a clear opportunity.
Consider the holistic product landscape – Understand how your data product fits into the broader ecosystem of solutions. No data product exists in isolation—consider integration points, shared data assets, and how users might need to work across multiple products.
Change is inevitable – Accept that source systems, data structures, and business rules will evolve. Design your data products flexibly, building mechanisms to adapt to upstream changes without breaking downstream functionality.
Appreciate the complexity of cross-functional collaboration – Building effective data products requires orchestrating diverse teams with different priorities, skills, and ways of working. Handling this complexity is crucial, and success depends on creating shared understanding and alignment across technical, business, and data teams.
Think product, not project – Move away from the "build it and forget it" project mentality. Data products require continuous iteration, maintenance, and evolution based on user needs and changing business requirements.
Build for scale and sustainability – Design data products with future growth in mind, considering not just current needs but how the solution will advance as data volumes grow, needs evolve, or the product adds features.
I get frustrated when companies don’t seem to understand these principles. If you start building products with the wrong mindset, you will fail. Yet, even with the perspective of past failures, companies continue to make the same mistakes and don’t appreciate how to shift their thinking to be more proactive with data product builds.
Foundational Data Product Components
Even with the right mindset, you still need the foundations to allow data product managers to live by those principles.
I defined these four foundational elements in a previous Data Ecosystem article, so here I will just share an abridged version of these capabilities that you should have in place before the design, build and production phases:
Strategic Alignment – Understand the broader business goals, the data strategy that underpins that and the needs of your business stakeholders.
Infrastructure, Architecture & Engineering – Set the foundational tooling below the data product. Here, teams need to consider four things in sequence. First, what is the overall enterprise & technology architecture within the organisation? Second, build some semblance of a conceptual, logical and physical data model connected to the business model or the most pertinent business processes for the identified data products. Third, think about the solutions architecture, which translates business requirements into technical specifications and the functional requirements, specifically how the data product design/ build will align with the organisation’s infrastructure. Fourth, the engineering team should be able to design and build high-quality data assets that can scale as per data product requirements and are optimised for performance and cost.
Data & Product Governance – Governance is about ensuring your data and underlying products product are built with quality, security, scalability, and usability in mind. Frameworks should outline ownership for products, linking those to relevant data owners & stewards.
Data Management – With the governance established, data management is required to maintain the quality of data feeding into the product. This should focus on master data management, data quality standardisation, and observability. Without this component, you will get the classic “garbage in, garbage out” result.
The Data Product Manager/ Owner
The last thing I want to outline before getting to the Data Product Operational Delivery Model, is the role that brings together all the activities within the delivery model.
This is the Data Product Manager or Owner.
In my head, I define these two roles separately:
Data Product Owner – A tactical role focused on day-to-day execution and delivery of a specific data product
Data Product Manager – A strategic role focused on the overall vision, lifecycle, and success of one or more data products
However your organisation defines this role (for simplicity, I’m going to refer to the Data Product Manager or DPM, as this is more common), the DPM is one of the hottest jobs in the market right now.
And for good reason! The job brings together business needs, underpinning technology requirements, and the data enabling it all. This thinking is holistic and enabling, exactly what the Data Ecosystem needs!
So what does a Data Product Manager do? This is a great description that I will borrow from an HBR article by Thomas Davenport, Randy Bean and Shail Jain:
They need to have the ability to manage a cross-functional product development and deployment process, and a team of people with diverse skills to perform the needed tasks. They must also be able to communicate effectively with the business leaders whose operations are going to be changed by the model and the programming surrounding it.
I also like the four Product-ness dimensions Nick Zervoudis outlines below. He defines four elements DPMs must focus on (opportunity discovery, solution design, solution delivery, and value realisation) to succeed. What I like about this representation is that there are many different ways DPMs might operate (e.g., proactive vs. reactive, deadline-driven vs. continuous, etc.) depending on many different factors (e.g., culture of their organisation, working style/ experience, quality of teams). Ultimately, there is no one way to do a product; it is a sliding scale between these four elements.
You will see similarities between these dimensions and the different steps in my Data Product Operational Delivery Model process. This underscores the importance of the DPM role to successfully deliver any data product, especially at certain stages requiring cross-functional collaboration.
I will likely write a further article on Data Product management because it is a hot topic that needs further definition. But I will leave you with this infographic about how I see the role.
A DPM is the bridge between the data, technology and business teams. They need to (1) understand the business needs and requirements to (2) guide the development of new data products while (3) ensuring they fit within the technical capabilities of the organisation.
There is a lot in that sentence and role, but I will leave it to another article to unpack further. Until then, the next section, operationalising data products, will represent much of what a DPM needs to do.
Data Product Operational Delivery Model
Okay, it’s finally time to build! You ready? Let’s dig in!
The crucial part to execution is building a product that the consumer/ end user will use. Data people sometimes forget this and aim to create something technically superior to what is required. Or something they think is pretty, even if it doesn’t have the right specs.
Why does this happen?
I hypothesise that people treat execution and delivery as standalone processes. Teams go off and DO without thinking about the Why and How. What you get is delivery in a vacuum, devoid of the existing strategic foundation and critical thinking needed to make it impactful.
And this is especially prevalent in data, where siloed working is extremely common due to misaligned organisational structures.
This is why my version of the operational delivery model is so detailed. The three distinct phases (with two steps each) outlined below address the primary considerations within a best practice delivery approach (and trust me, I’ve overseen the delivery of quite a few products). Each step has multiple activities and deliverables that should guide organisations on what they need to deliver and how:
The first phase is Scoping the Data Product. This involves defining the why and how behind the data product. Before going off and building the thing, teams need to conduct discovery of the problem/ opportunity and scope out the design of the data product to add value to the business.
Step 1 – Discovery
Understand what problem this data product is trying to solve or the opportunity it presents to the larger business
Every data product must start with the business's Strategic Goals and the Problem Definition of what it solves. The best reference point for this is an existing Data Strategy or the Business/ Team Goals that help dictate why the product needs to be built.
One of the best ways to ascertain this is to conduct Stakeholder Engagement interviews, requirements workshops, or primary research (e.g., user testing, process mapping, etc.). A huge (and often forgotten) part of this is understanding the Roles and Responsibilities of key business/ data stakeholders (i.e. what are they trying to achieve, how do they do that). Summarising the insights from this exercise provides the basis for what the product needs to do and how it might function.
These insights from the strategy and stakeholder consultation feed into determining the Business & Technology Feasibility. Not all products can be (or should be) built. Resources are often scarce and reasons to do things need to be properly assessed. Here is where the product delivery team and DPM needs to determine the priority and potential value of the data product, input their expertise into the effort required to build it, and decide whether it is feasible to begin designing it.
Deliverables:
Business Requirements – An understanding of what the data product needs to deliver to enable business value and what KPIs it will measure (or be measured against)
Interview Report – Insights from stakeholder interviews into their current business needs, pain points in existing processes, and potential solutions they have identified
User Stories – Captured requirements in stories demonstrating how different business and product users will interact with and use the product
Step 2 – Design
Turn insights from the Discovery stage into requirements and design documentation to provide clear guidance for product delivery
Within the design phase, the product team should continue adding to the Business & Technology Feasibility with non-functional and functional requirements. This will also feed into an initial Product Wireframe/ Design that provides a view of how the product should look, what it does, what data would feed into it, the relevant KPIs it answers/ displays, etc. Mapping and verifying the design with end users is crucial, but it is also essential not to over-engineer this phase and ensure feedback is constructive rather than debilitating.
Next, the Data Product should be aligned with the organisational data model and Platform/ Solution Architecture. Ensuring the product is built in a way that is consistent with other products and the overall platform enables efficiencies, scalability, and interoperability. This design should consider data assets/ sources, storage access points, other data products and the overall data model.
With the design foundations in place, the next step is to create a realistic Delivery Plan. First when designing the delivery plan, consider the optimal Delivery Model (how are teams set up to deliver initiatives and what the approach is) and how that can be aligned to this product development. Secondly understand the Workflow and Delivery Processes in place to properly collaborate with all necessary stakeholders and ensure the dev phase is executed effectively. Reporting Lines and the organisational structure should enable this understanding across teams, helping determine who needs to be involved and the leadership required to guide the delivery.
Deliverables:
Data Model & Process Maps – Conceptual and logical views of the data or business process model. Schemas and process maps should be built to communicate how data fits into the business process
Product Requirements – Technical and data requirements of the product, linking the business needs with the actual data delivery work
Delivery Plan – A detailed plan on how the dev team will build and test the product, including involved stakeholders, experts, governance and timelines
The second phase is Building the Data Product. This should be done iteratively, allowing for business stakeholder feedback. At the same time, it must leverage existing foundations, with testing and validation playing a pivotal role before rushing to production.
Step 3 – Development
Use validated designs to iteratively develop the data product (both the back and front ends), building in sprints to ensure alignment with users and relevant stakeholders
While many companies talk about building in an Agile manner, genuine agile delivery is much more complicated. The Agile Delivery Sprints start with the Delivery Plan, which is constructed during the design phase. Designed in 1-2 week sprints, agile delivery means taking a user-centric approach (e.g., user stories, user testing & feedback) with flexibility in mind, allowing teams to reprioritise based on updated requirements from the business/ users. Agile delivery is led by a scrum master or delivery lead (which may be the DPM) who defines clear success metrics, plans agile ceremonies (sprint plan, standups, reviews, retrospectives), and leverages a cross-functional team to bring the right expertise to the data product development.
The first two development activities within the Agile Delivery Sprints are Data Sourcing & Pipeline Integration (the backend) and Feature Development (the frontend).
On the backend, data engineers build the pipelines to connect the primary data storage solution and the proposed frontend solution. Engineers should consult any Data Governance & Management experts or guidance to ensure quality standards are set and maintained within the ingestion process.
Next, on the front end, analysts should leverage the user stories, interview report, and product requirements/ wireframe to build the required features that teams will interact with. Incremental builds and check-ins of the features are important here to ensure the data product will be used, that users are bought into the process/ end solution, and that the data analysts are sharing their expertise to users on why things are being built in a certain way.
In true agile fashion, both the backend and frontend teams should collaborate with one another to ensure the two workstreams are done in an aligned manner.
Deliverables:
Proof of Concept (POC) – Preliminary version of the product solution to demonstrate its feasibility and potential. This version needs to demonstrate value to warrant further investment
Minimum Viable Product (MVP) – Basic version of the data product that includes most features. Allows users to provide feedback for the dev team to iterate and improve upon
Frontend Application – A user-facing part of the data product, providing a more tangible solution for feedback. This would be included in the POC and MVP development
Step 4 – Testing & Validation
Ensuring data that feeds into the product meets quality requirements, while confirming the frontend requirements for business needs
This whole step still falls within the Agile Delivery Sprints, with the main delivery team verifying what is being built is working as designed.
There are two sides to the testing and validation. Data Quality Testing & Stagegate Implementation should occur and align with the data sourcing and pipeline build. Continuous Integration and Continuous Deployment (CI/CD) approaches will ensure pipeline development has automated processes to detect code issues. This should align with quality standards set by Data Governance or Management teams. Data quality stagegates within the data lifecycle can also be set up to verify that the data running through the pipelines to the end product meets requirements.
The other side of this step is User Acceptance Testing in which analysts and business stakeholders ensure the product meets their needs. This should be done at the end of each sprint with workshops to bring together ideas and ideate on how to improve usability.
Iterative Refinement is the culmination of testing. After collecting feedback, the team should refine and improve the product. In reality, this is an ongoing activity that will have happened throughout the Agile Delivery Sprints.
Deliverables:
Product Validation – A product that has been tested by users, with detailed specifications on how it has been tested and improved upon
Go/ No-Go Decision – Leadership decision about whether the product is ready for production based on UAT results and other feedback
The third phase is Operationalising & Optimising the Data Product. This entails careful monitoring of the product launch to prevent last-minute glitches or problems. Then the team needs to ensure users understand how to use the data product and whether it delivers against stated goals, helping inform further improvement.
Step 5 – Productionisation & Deployment
Deploying the data product into a live environment ready to be used by end users
To this point, the data product has been developed in a sandbox or offline environment (or Jupyter…). In preparation for go-live, the team should ensure Environment Alignment. This entails activities to match the development/ testing environment with the production environment and should include:
Configuring production servers and databases
Setting up necessary software and dependencies
Granting the right access controls
Creating security rules and measures
Verifying integrations and connections work in the production environment
A failure of junior Python devs is relying solely on Juptyer notebooks
Finally it is time for the Final Deployment, moving the Data Product to the production environment. Before pressing the go button, the dev team should do any final checks and validations. If necessary, a phased rollout might also be considered, especially for more complex launches (e.g., multi-country, partner launches). Teams might also include a rollback plan in case of unexpected launch issues. Oh, and don’t launch on a Friday.
Monitoring Setup provides the guidelines and tooling to understand the data product's performance, usage, and issues. Error tracking, logging, usage dashboards, critical issue alerts, and performance thresholds might be considered within this.
In parallel to monitoring, User Training & Documentation should be rolled out to any data product users. Develop these training materials during the agile sprint phase. Support channels for user questions, training sessions, product champions/ owners, and user manuals are all things that need to be factored into this activity.
Deliverables:
Live Data Product – A fully operational product accessible to end-users
Product Testing Plan – A plan to test and understand how the product team will monitor the data product after go-live. This includes setting the metrics and KPIs, along with the underlying processes and methodology to do so
Step 6 – Continuous Improvement
Seeking out feedback of the live data product and implementing updates to enhance and optimise its effectiveness
Continuous improvement isn’t a real step; it is more of an approach to the continued evolution of the data product (remember the product not project principle!). This is enabled by a User Feedback Loop, where the DPM collects ongoing comments, suggestions and performance data to input into future designs/ iterations of the product. The loop extends beyond users to other data teams, as changes in security policies, data quality standards, platform infrastructure, etc., will all impact product management.
In addition to the user feedback, product owners/ managers should stay on top of Product Tracking & ROI Reporting. Being data-driven should extend to knowing whether your data products are helping deliver value and meeting business goals. This builds on the Monitoring Setup and is the process of the team adjusting the product to hit KPIs better and showcase the value the tool is delivering.
Deliverables:
User Feedback – Insights from users about existing pain points, opportunities for improvement, and best practice to inform product updates
Product Updates – Recommendations to the product based on user needs and KPI outputs. These should be tangible and executable to facilitate expected improvements
Usage & Value KPIs – Accurate metrics via dashboards or reports that demonstrate the performance of the data product against business objectives and needs
Data Products aren’t easy to discuss or build. Hopefully this article (and the previous two) provides a foundation for operationalising your organisation’s data products in a scalable and sustainable way.
Next week we will take a break from The Data Ecosystem content with a Special Issue! This article will talk about the next step in my career, where I will draw back the curtain on how I progressed in my data career to where I am today, what I am doing next, and share as many career learnings as I can for all you lovely people.
Thanks for the read! Comment below and share the newsletter/ issue if you think it is relevant! Feel free to also follow me on LinkedIn (very active) or Medium (increasingly active). See you amazing folks next week!