A practical guide to data product design, with a worked minimum viable data product brief.
By Manas Jain
At a fictional retailer, the fulfillment team starts each morning with a familiar question: which orders need attention before they miss a delivery promise? The answer sits across order records, warehouse updates, and carrier tracking. This scenario is where data product design begins: with the decision people struggle to make.
A dashboard shows open orders, but staff still open several systems to establish what has happened. Some orders have shipped in parts. Some carrier updates arrived yesterday. An order can look complete because one parcel was delivered while another is still waiting to leave the warehouse. Publishing another table will help only if it makes those checks easier.
The retailer proposes a data product for at-risk orders. Its purpose is to give the exception-management team a maintained, understandable view of orders that may need intervention. The example throughout this article is illustrative; the rules, service expectations, and pilot choices represent proposed design decisions, with no claimed business results.
Start data product design with a decision.
Before choosing a platform, watch how the consumer works. Who reviews delivery exceptions? What can they change? When is it too late to intervene? If the team can contact the warehouse before an afternoon dispatch cutoff, information available the following morning has little operational value.
Write the need as a decision: “The fulfillment lead needs to decide which open orders require investigation or escalation during each exception review.” That gives the design a boundary. The first release helps people prioritize attention; customer compensation and automated rerouting remain separate processes.
Then ask what a wrong answer costs. An overlooked order may miss its promise. An unnecessary alert consumes scarce investigation time. A long list with no explanation can make the team repeat the same manual checks it already performs. Those consequences should influence the rules, interface, and support expectations.
A data product is a maintained offering designed around an identifiable consumer and use. A table, dashboard, file, or application programming interface (API) can deliver it. The delivery format alone tells us little about whether someone can rely on it.
I covered the wider shift from data assets to data products in an earlier article. Here, the useful next step is to design one small product closely enough that a consumer and an engineering team can discuss how it will actually work.
Build the smallest answer the team can act on.
For this retailer, begin with a read-only operational view that supports filtering and links back to the order system. The fulfillment team already works there, so a separate analytical workspace would add another place to check. Publish the same maintained table behind the view for approved analytical consumers if they need it.
An optional daily exception file might suit a team that works in scheduled batches. An API could support another application later. Each additional interface creates testing, access, and support work, so introduce it when a consumer needs it. A product can have several interfaces while keeping one owner and a consistent meaning.
Define the grain, meaning what one row represents, before joining anything. For the first release, one row represents one open order. Evaluate its undelivered parts individually, then bring the relevant reasons back to the order. One delivered parcel must not hide another parcel that threatens the promise.
The minimum output includes an order reference, promised delivery time, latest relevant fulfillment status, risk state, reason, and timestamps. A link to the authorized order record lets staff investigate without copying customer addresses or telephone numbers into the shared view. If there are several reasons, retain them rather than choosing the first one that appears in a join.
Turn source facts into an explainable risk state.
Three source groups contribute different facts. The order system supplies the current promise and order state. Warehouse records show what remains to be dispatched. Carrier updates provide shipment events, exceptions, and estimated arrival times. Shared order and shipment references connect them, and source timestamps help the consumer judge their age.
Use a small set of rules the operations team can explain. In this example, an open carrier exception, an arrival estimate beyond the promise, or a missed dispatch cutoff can mark an undelivered part as at risk. Agree on how local delivery dates become cutoff times before comparing timestamps. These are candidate business rules to agree with fulfillment specialists; there is no universal dispatch threshold suitable for every retailer.
Missing shipment references, unmapped statuses, or critical data older than an agreed freshness limit create a needs review condition. Preserve the exception separately from the risk flag. Where a known exception and incomplete information coexist, show both. No current risk detected means the agreed rules found no risk in sufficiently current, usable inputs; it does not guarantee on-time delivery.
| Illustrative order | Available facts | Consumer-facing result |
| A104 | One parcel delivered; the remaining parcel has a carrier exception. | At risk. Show the exception for the outstanding parcel. |
| A105 | No usable tracking update is available within the agreed source-freshness limit. | Needs review. Explain that the current evidence is insufficient. |
| A106 | Current, usable inputs; no carrier exception or missed dispatch cutoff; all undelivered parts expected within the promise. | No current risk is detected under the agreed rules. |
Ensure that orders already past their promise remain visible as overdue exceptions, or route them explicitly to an existing queue. Silently dropping them when the date changes would make unresolved work disappear. Completed and cancelled orders leave the active view according to agreed source definitions; any audit history has its own retention requirement.
De-duplicate source events using stable identifiers and apply the agreed event sequence so an old update arriving late does not overwrite newer knowledge. Reconcile the output against the expected open-order population. Otherwise, an apparently tidy list can conceal orders lost during a join. The distinction between a successful pipeline and fit-for-use data is explored further in When Green Pipelines Still Deliver Wrong Data.
Source facts become useful when the maintained interface gives fulfillment staff enough context to investigate and act.
The logical flow is straightforward: collect the facts, resolve identities and event order, apply the agreed meanings, publish the maintained answer, and review the resulting exceptions. The product owner stays accountable for the meaning and usefulness of that answer. Engineering operates the service, while source teams remain responsible for the upstream facts they provide.
Make freshness visible at the point of use.
Hourly publication is a reasonable candidate to discuss with this fictional team. It is useful only if source systems update often enough and staff can act at that pace. Faster processing adds little value when the carrier provides a daily file or when operations review the list only once each morning.
Show the last successful product refresh and the relevant source-update times. A view rebuilt at 10:00 can still contain a carrier fact last updated yesterday. Refresh time and source freshness answer different questions, and the interface should make both understandable.
If publication fails, mark the previous snapshot as stale and identify its last successful refresh. If a critical source becomes too old, flag the affected orders for review. Agree on who receives the incident and what the consumer should do while the problem is investigated. An hourly target needs an operating window and a support route before it can become a credible service expectation.
A worked minimum viable data product brief
The brief below captures the first design conversation in a form a consumer, product owner, and engineer can review together. “Minimum viable” means enough detail to decide what to build and support. Every threshold and review period remains an illustrative proposal for this fictional retailer. Before a pilot, replace role placeholders with named contacts and agree on operating hours, source-freshness limits, and incident response.
| Brief field | Worked at the Risk Orders example |
| Product name | At-Risk Orders |
| Consumer and decision | Fulfillment lead and exception team. Decide which open orders need investigation or escalation before a delivery promise is missed. |
| Output and grain | Read-only operational view backed by a maintained table. One row per open order; assess every undelivered part. Add other interfaces only for a confirmed need. |
| Essential information | Order reference, current promise, relevant status, risk reasons, review flag, source timestamps, product-refresh time, and authorized order link. |
| Important meanings | At risk: agreed exception, late estimate, or missed cutoff. Needs review: critical evidence missing, unmapped, or stale. No current risk detected: usable inputs with no triggered rule. |
| Source dependencies | Order and promise records, warehouse dispatch status, and carrier shipment events. Agree on identifiers, event ordering, freshness limits, and upstream contacts. |
| Accountable owner | The product owner for the fulfillment domain owns meaning and usefulness; assign a named individual before pilot launch. Fulfillment data engineering runs the service. |
| Update expectation | Candidate: hourly during staffed operations. Validate source cadence, operating hours, and action windows with consumers before committing. |
| Fit-for-use checks | Reconcile expected open orders; prevent duplicate order rows; validate status mappings and identifiers; expose missing or stale inputs. |
| Access | Role-based read access for approved teams. Exclude unnecessary customer personal information; enforce permissions on order-system links. |
| Discovery and first use | Searchable entry with purpose, example, definitions, access steps, limitations, and a short walkthrough of the existing workflow. |
| Support and change | One fulfillment data support queue. The owner is responsible for addressing meaning questions and resolving engineering triage failures. Notify affected consumers before consequential changes. |
| Evidence of usefulness | Proposed four-week pilot: baseline manual checks and identification time, then review repeat use, actionable alerts, missed exceptions, and consumer feedback. |
| Limits and lifecycle | Risk flags are fallible and depend on source updates. Keep overdue work visible. Review operating cost and usefulness; combine or retire with consumer notice. |
Copy and adapt the brief.
Use these prompts for your product. Write specific answers before choosing additional technology.
- Consumer and decision: Who needs to decide or do what, and when?
- Output and meaning: Which interface fits that workflow? What does one record represent, and which definitions matter?
- Dependencies and limits: Which sources supply the facts? What could make the answer incomplete or misleading?
- Owner and operation: Who owns the usefulness, who runs it, and what update behavior can consumers expect?
- Access and support: Who may use it, how do they start, and where do issues and change requests go?
- Evidence and life cycle: What would demonstrate usefulness, and when would you improve, combine, or retire it?
A compact work brief for discussion. The complete text above remains available to copy, search, and read with assistive technology.
Treat the first use as part of the product.
A catalogue entry can help someone discover the view. The entry should explain the question it answers, show an example, name the owner, and provide working access instructions. It also needs to state the limitations clearly enough that a new consumer does not interpret an absence of alerts as a delivery guarantee.
Walk the fulfillment team through a few representative orders, including an incomplete one. Observe whether staff can explain a risk reason and reach the operational record. If every first-time user needs an engineer to interpret the status column, the interface still depends on undocumented expertise.
Keep one route for questions and incidents. Consumers should not have to decide whether an unexpected result is a source problem, a transformation defect, or a misunderstood definition before asking for help. The provider can make that distinction during triage.
Later, a change from an order-level promise to parcel-level promises may alter the meaning of the output even if all column names stay the same. Identify affected consumers, explain the change, and allow them time to adapt. Detailed contract design deserves its own treatment; the immediate responsibility is to avoid surprising people who depend on the answer.
Measure whether the decision becomes easier.
Agree on the pilot questions before the launch. Observe the current workflow, record the number of manual cross-system checks, and measure how long it takes to identify orders needing attention. Repeat the observations during the proposed four-week pilot and ask users how the view changed their decisions. These are proposed measurements, not evidence that the example has already delivered an improvement.
Separate adoption from outcome. Repeat use by the intended team suggests the product has entered the workflow. Fewer manual lookups, earlier identification of actionable exceptions, and clearer prioritization suggest that the work may be improving. Compare similar operating periods and discuss changes in volume or staffing before attributing an improvement to the product.
Query counts alone are ambiguous. An automated refresh can generate thousands of requests without helping anyone, while a weekly review can be essential despite low usage. Track meaningful use at the workflow level and respect access and privacy controls when collecting telemetry.
Review false alerts and missed exceptions together. A quiet list may be pleasant to use while overlooking important orders; a noisy list may cause staff to stop trusting it. Even a well-used product may not reduce late deliveries if operations lack the capacity to intervene. That finding should change the scope or investment decision rather than disappear behind an adoption chart.
Decide when a simpler deliverable is enough.
Suppose the same retailer needs a one-time extract to investigate a historical warehouse incident. A controlled report with clear definitions, access, and retention may be sufficient. Giving it a permanent product identity would add support and life-cycle work without an established recurring consumer need.
Repeated decisions with continuing dependence are stronger candidates for a maintained product. Several consumers can justify shared investment, but a single operational team may also have enough value at stake. Count the ongoing cost of source changes, access, incident handling, and consumer support alongside the development cost.
If two products answer substantially the same question, consider a shared, maintained answer with different views. If a product has lost its consumer, investigate whether the workflow moved or an infrequent obligation still depends on it. Retire it only after checking those dependencies and giving affected consumers a clear transition.
Clear meaning also matters to AI consumers.
Machine-readable descriptions can help make product expectations explicit. The Open Data Product Specification 4.2 provides a vendor-neutral model for describing data products. Completing a specification is useful documentation work; whether the offering helps a consumer still needs testing in use.
Snowflake’s 3 November 2026 announcement emphasizes business context and governed definitions for AI agents. It is a vendor announcement, rather than independent evidence of business outcomes. My design implication is straightforward: an agent reading this retailer’s view must understand the risk states, freshness limits, and permitted actions just as a person does. Any authority to act requires separate boundaries and verification.
Put one brief in front of one consumer
Choose a recurring decision that people struggle to make today. Fill in the brief, walk through difficult records with the intended consumer, and agree on one maintained output and one useful measure before expanding. The most revealing review is whether the team can use that answer, explain its limits, and get help when it fails.
Build data products because someone has a repeatable need worth supporting. Let evidence from that use determine what you build next.