Leaders are under pressure to do more with data, and most believe they already are. In a 2025 Salesforce survey of more than 7,600 business and data leaders, 63% of business leaders called their organizations data-driven. However, just as many data and analytics leaders said their companies struggle to use data to drive business priorities.
A lot of that gap starts with a reasonable question. I've watched it play out many times. A senior leader asks, "Why aren't we doing more with AI?" Instead of asking what the leader wants to accomplish, the person answering says they need better data. So the leader tells their team to get better data and stops there. Without a goal, "better" turns into "more."
This article follows two versions of that request through the same warehouse. One produces billions of rows of data nobody uses. The other produces a focused dataset that enables the team to find and fix what's slowing the work down. Better data isn't more data. It's usable data tied to a specific goal.
The Vague Ask: "Get Us Better Data"
The request for better data lands with the tech team, who will often call it "instrumenting" the process. That just means adding tracking to the systems the team already uses, so they record data like a timestamp when an item is scanned, a record when an order ships, or a note when a picker reports an item missing.
With no goal attached, the team does the reasonable thing and tracks everything it can. Developers are hired for their software expertise, not for running a warehouse. They know how to build tracking. Without that direction, they can't tell which data is most important, so "capture everything" becomes the safe default. The result is billions of rows of data that are expensive to store and hard to use, because the few numbers that matter are buried in everything else, and much of it is poorly documented. Analysts spend their time digging through it and figuring out what it means instead of answering questions.
In the best case, that's wasted money: storage, maintenance, and engineering time that could have gone somewhere else. In the worst case, it adds latency, the tech term for delay, and slows down the people the data was meant to help. Every time the system records something, it takes a little extra time. It's the difference between washing the dinner dishes and timing every step with a stopwatch: start the timer, pick up the scrubber, stop the timer, start it again, pick up a plate. You get a detailed record, and washing one plate takes far longer than it should. On the floor, that shows up as a scanner that lags. Measuring the work should never make the work harder.
The Specific Ask: "Reduce Pick Time"
This time, the leader starts with what they want to accomplish: "Reduce the time it takes to pick an item by 10% by the end of the quarter." It names the process and gives the team a way to know if it worked. In practice, most requests include several goals like this. We'll follow pick time to keep the example simple.
Go to the Floor Before You Go to the Data
With a specific goal in hand, the team doesn't start with a data request. It starts with the people who pick orders.
Walk the process together. Go through the work step by step: receive the order, walk to the location, find the item, scan it, move to the next one.
Watch the work. Someone who's done a job long enough stops noticing its friction. Time spent watching catches what a conversation won't. It's the same instinct behind the Gemba walks we recommended in Automation Missteps: go see the work before you trust the numbers.
Measure What Slows the Work Down
Find what drives pick time. The walk-through will show which steps slow the work down. Pick time is an output. The drivers are things a team can change, such as how far people walk, how long they wait on a scanner, and how often an item isn't where the system says it is. We've written about working backward from the output you care about to an input the team controls in The Five Foundations of an Operation.
If long walks between pick locations are slowing pickers down, the team needs data on travel time between them. It doesn't need a record of every screen tap. Let the goal inform which steps to track.
Put the Data to Work
Decide what will drive the change. Now the team has a focused list of input metrics that drive the goal. Once that data is captured, the team can see where pick time goes and choose how to fix it. That might be a process change, a program manager who owns the fix, or, in a complex operation, AI that suggests better pick paths and better places to store items. We covered where AI tends to pay off in The AI Sweet Spot.
Build reporting to track progress. Whatever drives the change, the team needs to see whether pick time is moving. A report on the goal and the input metrics behind it does that job. The Weekly Business Review That Actually Works covers how to review those inputs every week.
Before Your Next Data Request
The vague ask ends with a bloated dataset, slower scanners, and no clear answer. The specific ask ends with a focused dataset the team uses to cut pick time, and a foundation for AI.
The difference was deciding what to accomplish first. Before asking for data, answer four questions:
What specific outcomes are we trying to improve?
What can the team control that drives those outcomes?
Where does the work slow down today?
How will we track progress?
If you can't answer them, your tech team can't either. They'll fill the gap with everything they can capture.
