Data engineers and analysts usually build data stacks for their own needs, while product managers are the people who need answers most often. Correctness, scalability, query speed, and maintainability are sensible priorities. Without correctness or scale, a stack eventually fails in difficult-to-reverse ways.
A stack tuned for engineers can be a poor fit for product managers, whose data questions are frequent and time-sensitive. The distance between available tools and actual PM needs is rarely addressed directly. Instead, workarounds accumulate, questions get delegated, and teams make decisions without data.
Before Mitzuo, I spent several years creating internal analytics tools at larger companies, and the same gap appeared each time. Seeing it clearly is the first step toward closing it.
For PMs, Data Means Questions, Not Models
Data engineers use the stack through models: staging tables, transformation logic, dimensional schemas, and materialized views. Their job turns raw data into dependable structures for querying. Knowing the stack means knowing its model layer.
Product managers approach data with questions: did this cohort retain better than the last one, is last week's feature being used, and what share of users who finish onboarding perform the core action within the first 48 hours. Their task is to link business intuition to measurable behavior.
These are distinct modes. A PM asking "how many users ran a query in the last 7 days" is asking for an answer, not a tour of the data model. Whether it comes from the events table or a pre-aggregated mart table is irrelevant. They need a trusted answer quickly enough to guide this week's decision.
Without that distinction, PMs either spend months learning enough SQL to query raw tables and produce unreliable ad-hoc queries, or send every question to an analyst with a queue and competing priorities. The outcome is identical: slower answers, narrower questions, and intuition-led product decisions because accessing data costs too much.
The Setup-Time Problem
Setup work is familiar to data engineers: installing a tool, configuring a connector, writing a dbt model, or waiting for a pipeline run. The investment makes sense because it creates infrastructure that will be reused.
Product managers cannot take on that cost any more than they can learn SQL from scratch. Their decisions follow a weekly cadence, and each has a limited window. If answering a data question takes two hours of setup, it is usually unusable. The decision or meeting may be over by then.
Most modern data stacks assume users face little setup. For a non-technical PM, the real cost is much higher than the docs imply. Connecting to a BigQuery table, finding the right database and schema, distinguishing "users who signed up" from "all accounts in the system," and setting up BI tool authentication are manageable alone. Together, they stop casual questions before they are asked.
The Freshness Mismatch
Enterprise data stacks commonly favor batch processing, with transformations and refreshes running daily or hourly. That works for historical analysis. It fails when a PM needs to know whether yesterday's bug fix changed the behavior of users who encountered the error state, since the answer is already a day old.
Product decisions, particularly those involving live experiments and shipped changes, move faster. Teams shipping code daily need freshness at that pace. It need not be real-time, but the key behavioral events should certainly be available within the hour.
Batch architecture is not inherently wrong. Batch transforms cost less, tend to be more reliable, and are easier to maintain than streaming systems. Trouble starts when PM access is bound to the batch timetable. Usually, the access layer should be separate: direct event queries with little transformation for PMs, and transformed, modeled, validated data in the warehouse for reporting and business intelligence. Both can coexist and serve their users better.
What PMs Need from Most Data Stacks
Before Mitzuo, I worked with product teams at three companies. The same list of missing PM needs appeared each time:
Plain-language access to behavioral data. The ability to ask "how many users did X after doing Y" without knowing the table names, without writing a join, without understanding the data model. This is not about abstracting away complexity for its own sake. It is about matching the access layer to the question type.
Instant answers for simple questions. Count, rate, average, filter by cohort, compare two time periods. These are the questions that product teams ask a hundred times per sprint. They are not complex analytically. They should not require a 15-minute query setup. For teams that use Mitzuo, this is the workflow we have built: ask the question in plain text, receive the answer with the query shown, move on.
Answer provenance. A PM who receives an answer needs to trust it and be able to explain it to others. This means knowing which data was queried, what filters were applied, and when the data was last refreshed. The "query shown" aspect of Mitzuo's design is a direct response to this need: every answer comes with the SQL that produced it, so the PM can see exactly what was asked of the data and share that context with their team.
Answers that follow the decision, not the queue. The sequence in most organizations is: decision gets made, data question gets submitted, answer comes back next week, answer is filed somewhere. The right sequence is: data question gets asked while the decision is in progress, answer informs the decision, decision gets made. For that to happen, the gap between question and answer has to be measured in minutes, not days.
Closing the Gap Without Rebuilding the Stack
The stack itself need not be rebuilt. The needed change is the layer between the PM and the data. PMs do not need the warehouse's full architecture. They need a defined, queryable layer covering the events and metrics their team uses, available without SQL and fast enough for real-time usefulness.
For most early-stage product teams, this layer can stay simple: an events table, a user properties table, and a basic map from event names to behaviors. The harder task is reliably turning a plain-language question into a query against that layer so the PM trusts the result.
Mitzuo is solving that translation problem. The aim is neither to replace the data stack nor to remove so much complexity that analytical power is lost. It is to close the access gap between product teams' questions and the data that answers them.
