The User Ordered Pizza. We Delivered Pierogi.
Correct Ingredients, Wrong Meal
The user ordered pizza.
We delivered pierogi.
Pierogi are dumplings common in Central and Eastern Europe: dough wrapped around a filling, often potatoes, cheese, meat, or mushrooms. They can be excellent. That is not the issue.
The issue is that the user ordered pizza.
We can point to flour, water, cheese, mushrooms, and meat. We can say that the ingredients overlap. We can say the kitchen worked correctly. We can say the meal is edible. We can say the cook followed a process.
None of that changes the fact that we built the wrong product.
Data work has the same failure mode. A team can use the right sources, create a table, schedule a pipeline, validate the schema, publish a dashboard, and still deliver something that does not answer the user’s question.
The ingredients may be correct.
The meal may still be wrong.
Data Output Is What the System Produces
A data output is something the system produces.
It can be a table, a CSV export, a dashboard, an API endpoint, a notebook result, a model score, a scheduled report, a Power BI dataset, a dbt model, a Delta table, or a file dropped into a shared location.
Outputs are necessary. Without them, nothing concrete exists. A data team cannot serve users with intentions alone. At some point, a pipeline must run, a table must materialize, a report must render, an endpoint must respond.
The problem begins when we treat the existence of an output as proof that the user’s need has been met.
A table can be technically correct and still not useful. A dashboard can refresh on time and still not support the decision. An export can contain every requested column and still force the user to rebuild the logic manually. A dataset can pass validation and still leave the business question unanswered.
Data output answers the question:
What did the system produce?
That is an important question. It is not the only one.
Data Product Is What the User Can Rely On
A data product is not just a more polished output.
It is an output shaped around a user, a question, a decision, and a promise of use.
A data product should make explicit:
- who it is for,
- what questions it answers,
- what decisions it supports,
- what grain it uses,
- which definitions are stable,
- what quality expectations apply,
- how often it refreshes,
- where it should not be used,
- who owns it,
- what counts as success.
This is a different standard from “the table exists” or “the dashboard was delivered.”
A data product answers the question:
What can the user reliably understand or decide because this exists?
That word reliably matters. A product is something a user can return to. It has a boundary. It has expectations. It behaves consistently enough that people can build work around it.
A one-time export may be useful. A staging table may be necessary. A notebook result may answer an immediate question. But those things are not automatically products. They become products only when they are shaped for repeated use by a known consumer under known expectations.
Ingredients Are Not Requirements
In the kitchen, ingredients are not the meal.
Flour, water, cheese, mushrooms, and meat do not tell us whether we are making pizza, pierogi, pasta, a pie, or something else. They tell us what is available. They do not tell us what was ordered.
The same is true in data.
A list of sources, columns, joins, and refresh schedules tells us what can be assembled. It does not tell us what the user needs to understand.
An ingredient list does not tell us:
- who will eat the meal,
- what they ordered,
- when it should be served,
- what constraints matter,
- what would make it successful,
- what would make it unusable.
A data source list has the same limitation.
It does not tell us:
- who will consume the result,
- what decision they are making,
- what question keeps returning,
- what grain they act at,
- what definition they trust,
- what freshness is necessary,
- what mistake would be dangerous.
This is why a requirements conversation that starts and ends with columns is incomplete. Columns matter, but they are not the requirement. They are ingredients.
The Pizza and Pierogi Failure Mode
The pizza and pierogi mistake is not random. It is not a failure of effort. It is not even necessarily a failure of technical skill.
It is a failure of orientation.
The team optimized around what could be made from available ingredients instead of clarifying what the user had ordered.
This happens constantly in data work.
A user needs retention cohorts, but receives a customer table. The table may contain customer IDs, signup dates, plan types, and activity flags. Useful ingredients. Still not a cohort analysis.
A user needs daily operational exceptions, but receives a monthly KPI dashboard. The dashboard may be accurate. It may be visually clean. It may even show the right metric. But if the user acts every morning, a monthly view arrives at the wrong rhythm.
A user needs to understand margin risk by product, but receives revenue by category. Revenue is not irrelevant. Category is not useless. But the decision is about margin, not volume.
A user needs one trusted definition of active customer, but receives a flexible dashboard with five possible activity metrics. The flexibility looks generous. In practice, it transfers the semantic conflict to the user.
A user needs a monitoring product, but receives a one-time export. The export may solve today’s question. It does not create a reliable mechanism for tomorrow.
In each case, the output may be defensible. It may even be well built.
It is still the wrong meal.
The Wrong First Question
Many data projects begin with a question that sounds practical:
What do you want us to build?
It is not a bad question, but it can start the conversation at the wrong level.
Users often describe the artifact they imagine, not the need behind it. They ask for a dashboard because dashboards are familiar. They ask for a table because tables feel concrete. They ask for an export because they no longer trust the current report. They ask for “all the data” because they are trying to protect themselves against missing something later.
This is understandable. Users are not always trained to express analytical requirements. They usually know the pressure they feel better than the product that should solve it.
If we accept the artifact request too quickly, we may build exactly what was asked for and still miss what was needed.
The request “I need a dashboard” may mean:
- I need to monitor exceptions every morning.
- I need to explain performance in a weekly meeting.
- I need to reconcile numbers between systems.
- I need to identify which customers require action.
- I need to stop asking the analyst for the same number.
- I need a trusted definition of a metric.
These are different products.
They might all be called dashboards in the first conversation.
The Better First Questions
A better requirements conversation does not ignore the artifact. It delays it long enough to understand the use.
Instead of starting only with “what should we build?”, ask:
- What decision are you trying to make?
- What question keeps coming back?
- What will you do if the number goes up?
- What will you do if the number goes down?
- Who needs to trust this answer?
- At what grain do you act?
- How fresh does the answer need to be?
- Which definitions cannot be ambiguous?
- What would make this not useful?
These questions move the conversation from ingredients to appetite.
They reveal whether the user needs a monitoring tool, a diagnostic workflow, a curated table, a semantic metric, a dashboard, an alert, a one-time analysis, or a better definition.
Sometimes the answer is still a dashboard. Sometimes it is a table. Sometimes it is a data contract, a metric definition, a data quality check, a new grain, or the removal of a misleading existing report.
The point is not to avoid building. The point is to build the thing that matches the question.
Product Thinking Names the Promise
A data product should have a promise.
Not a marketing promise. A practical one.
For example:
This product helps regional managers identify which stores need attention before the weekly operations call.
Or:
This product gives finance one governed definition of paying customer for revenue and retention reporting.
Or:
This product lets support leaders monitor backlog risk daily and distinguish normal variation from action-worthy pressure.
These promises do not describe only the artifact. They describe use.
Once the promise is visible, design decisions become easier. The grain can be chosen against the decision. The refresh rhythm can be chosen against the workflow. The definitions can be stabilized against the expected interpretation. The quality checks can focus on failures that would damage the product’s use.
Without a promise, teams often compensate with more ingredients.
More columns. More pages. More filters. More sources. More export options. More metrics. More flexibility.
Sometimes that helps. Often it only hides the fact that the product does not know what it is for.
When Output Is Enough
Not everything needs to be a data product.
This distinction matters because otherwise “data product” becomes another inflated label for ordinary work.
Outputs are perfectly fine for many situations:
- internal staging,
- technical logs,
- one-off analysis,
- exploratory notebooks,
- temporary migration work,
- debugging,
- private analyst workflows,
- intermediate pipeline artifacts.
A pile of ingredients is useful in a kitchen. A prep station needs chopped vegetables, dough, sauces, fillings, and containers. Not every bowl on the counter needs to be a served meal.
The problem begins when an output is handed to users as if it were a product.
If a table is meant only as an intermediate artifact, treat it that way. If an export is a temporary bridge, say so. If a notebook result is exploratory, do not let it quietly become a recurring reporting process. If a dashboard is meant for investigation, do not sell it as an executive answer.
Output is not inferior. It is simply a different kind of thing.
Confusion starts when we do not name the difference.
Turning an Output Into a Product
If you already have an output, you do not always need to rebuild it from scratch. Sometimes you need to wrap it in product thinking.
Ask:
- Who consumes this?
- What question do they believe it answers?
- What decisions depend on it?
- Which definitions must be explicit?
- What assumptions are hidden in the transformation?
- What quality signals should be visible?
- What should users not do with it?
- What feedback loop tells us whether it works?
These questions change the shape of the work.
A table may need a clearer grain. A dashboard may need fewer controls and stronger defaults. A dataset may need a semantic definition before wider use. A pipeline may need quality checks aligned with the product promise, not only with schema validity. An export may need to become an owned, refreshed, documented source instead of a manually regenerated file.
This is where data contracts, semantic definitions, observability, and BI design meet. They are not separate rituals. They are ways of protecting the product’s promise.
Ask What Was Ordered
The goal is not to shame the kitchen for making pierogi.
Pierogi can be excellent.
The issue is mismatch.
In data work, the mature question is not only “what can we build from the data we have?” That question matters, but it is incomplete. The stronger question is:
What has the user actually ordered, and what would make the answer useful?
If we skip that question, we can produce something correct, fresh, documented, and impressive that still fails at the moment of use.
A data product is not a more polished output. It is an output shaped around a question, a user, and a decision.
Correct ingredients are not enough.
Someone still has to ask what meal we are making.