Ask anyone what McDonald’s sells and you’ll hear: burgers, fries, McFlurry, chicken nuggets.
But burgers and fries are not the real product of McDonald's.
The real product is
- reliability
- consistency
- availability.
You know what you’ll get. It will taste the same. It will be ready fast. It won’t surprise you.
McDonald’s doesn’t win because of what it sells. It wins because of how it sells it.
And that’s exactly what data teams get wrong.
Most data teams focus on outputs
- Dashboards
- Analyses
- Pipelines
- Closed tickets
- Data models
All of that is important.
But all that stuff is not the product of your data team.
If you lead or work in a data team, this shift in thinking changes everything.
It did so for me.
It changed how I hire. How I prioritize. How I automate.
Here’s the sentence I want you to internalize:
The product of your data team is not dashboards.
The product of your data team is easy and speedy access to trustworthy, understandable information that helps the company make more money and helps your stakeholders and you live better lives.
Read it again.
Not pipelines.
Not infrastructure.
Not SQL queries.
Access. Trust. Speed. Impact.
That’s the product.
The real driver behind McDonald’s scale
McDonald’s became one of the most successful businesses in the world because of its operating system.
In simple terms:
→ Perfectly predictable components
→ Tested in controlled environments
→ Rolled out at scale only after validation
They don’t experiment directly in thousands of restaurants. They test changes in controlled branches first. Once proven, they roll them out to production.
The result?
Anyone can operate the system and produce the same quality.
That’s the key.
The system is so strong that the outcome does not depend on individual heroics.
Now compare this to many data teams.
Everything depends on:
- The senior data engineer who knows “how things really work”
- The analyst who built the original model
- The data architect who retired 3 years ago
That’s not an operating system. That’s tribal knowledge.
And tribal knowledge does not scale.
The Missing Piece: Management Systems
If your product is “easy and speedy access to trustworthy, understandable information,” then you need systems that reliably produce that outcome.
That’s where management systems come in.
A management system is:
A set of automations and standard operating procedures (SOPs) that help your data team consistently and reliably make your company more money and help your stakeholders and you live better lives.
In simple words:
It’s a standardized way of doing things.
Ideally automated.
Like working through a checklist.
The best mental model?
A checklist where items are ticked off manually or automatically by a machine.
If this → then that.
Cause → effect.
Predictable.
The Four Pieces of Every System
Every good system has four components:
- System prompt
- Execution steps
- Path and filter rules
- End state
And each execution step uses:
- A template
- A tool (or method)
Let’s make this concrete.
Example: A Dashboard Request System
Imagine a stakeholder requests a new dashboard.
Most teams jump straight into building.
That’s a mistake.
Your system could have three components:
- Understand the stakeholder problem
- Define and validate the solution
- Build and ship the solution
Let’s zoom in on the first one.
System Component 1: Understand the Stakeholder Problem
This step is often skipped. And that’s expensive.
Let’s break it down using the four system pieces.
1. The Prompt
The prompt is simple:
A feature request or dashboard request from a stakeholder.
That’s the trigger.
2. Execution Step
First execution step: Ask questions to truly understand the problem.
But don’t improvise every time.
Use a template.
For example:
- A standardized problem screening interview
- A fixed set of questions
- Clear criteria for urgency and business impact
Your goal is to understand:
→ What decision will this support?
→ What business goal does it link to?
→ What happens if we don’t solve it?
→ How often will it be used?
The tool can vary. Some use Jira. Some use Google Forms. The tool is secondary.
The template is what creates consistency. Here are some tips for asking the right questions.
3. Path and Filter Rules
Now comes the crucial part.
You define rules that determine whether the request moves forward.
For example:
If the request cannot be mapped to a business objective → stop.
If the problem is not important or urgent → stop.
If required information is missing → return to stakeholder.
This is your quality gate.
Without it, you become a dashboard factory.
With it, you become a value engine.
You can keep it simple at first:
One execution step.
One validation rule.
Two possible paths.
That’s enough to start.
4. End State
Every system must end clearly.
In this case:
- Yes → Problem validated → Move to solution validation system
- No → Problem not validated → Inform stakeholder
And here’s the important part:
The end state of one system becomes the prompt of the next system.
This is how you build an operating system for your data team.
Why You Should Build Systems as a Team of One
Many people think: “We’ll formalize this once we grow.”
That’s backwards.
You should create these systems when you are a one-person data team.
Why?
- You practice consistency early
- You reduce cognitive load
- You make onboarding easier later
- You reduce dependency on yourself
Document:
- Which steps are manual
- Which steps are automated
- Which steps work well
- Which steps need improvement
Over time, you automate more.
The goal is not complexity.
The goal is predictability.
Just like McDonald’s.
From Outputs to Operating System
Let’s connect this back to the bigger idea.
Most data teams measure themselves by outputs:
- Number of dashboards shipped
- Tickets closed
- Pipelines built
But McDonald’s does not measure success by “number of burgers flipped.”
It measures consistency, quality, and scalability.
You should ask yourself:
- Can anyone in my team follow our systems and produce the same quality?
- Do we test changes in a controlled way before rolling them out broadly?
- Are our processes documented and partially automated?
- Do we have clear filter rules for incoming requests?
If the answer is no, you don’t have a scalable data team.
You have skilled individuals.
That’s not the same.
The Bottom Line
If you remember one thing from this newsletter, remember this:
The product of your data team is easy and speedy access to trustworthy, understandable information that helps the company make more money and helps your stakeholders and you live better lives.
To deliver that product, you need management systems.
Not more dashboards.
Not more tools.
Not more tickets.
You need:
- Clear prompts
- Defined execution steps
- Strict path and filter rules
- Explicit end states
Start small.
Pick one recurring process this week.
A dashboard request.
A data model change.
A new data source onboarding.
Map it using the four components.
Turn it into a checklist.
Then improve it.
Test changes before rolling them out broadly.
Build your data team like McDonald’s built its restaurants: predictable, controlled, scalable.
Because in the end, your competitive advantage is not what you build.
It’s how reliably you build it.
