Find the Signal: How We Shape Up Our Solutions
A cleanup program was about to sort 450,000 data tables by hand... Until one question changed the plan.
AI makes building fast and cheap, so it's tempting to skip that question and go straight to the work. But building fast amplifies whatever you point it at. Point it at the wrong problem and you get the wrong result sooner, and often a more convincing one.
That's why the first part of our work with clients happens before anyone builds: working out which problem is worth solving.
Start with the problem
At DataChef, every piece of work starts with three questions.
What do we want to solve? Requests usually arrive as a solution: a tool, a dashboard, a model. We look for the problem behind the request first.
Is it the signal or the noise? Some problems are worth solving, and some only look urgent. We want to know which part of the work will actually change something for the client, and how much that change is worth.
What's the simplest way to act on it? Once the real problem is clear, the answer is often smaller than the original plan.
These questions sound obvious, but committing to them is really hard. They're also the first thing teams skip when building is cheap, because building feels like progress. A demo looks good in an update. A better question doesn't.
The tables nobody used
At one of our clients, a global retailer, a legacy displacement program planned to go through roughly 450,000 old data tables, assign them to value stream teams based on their content, and ask the teams to analyze the best way to migrate them to a new technology.
Before the sorting started, one of our engineers invested less than a day to find out which of the tables were actually still in use. Turns out, 96% hadn't been accessed in over a year. That was the noise. The signal was the small share still in use.
So he proposed a usage-based rule at the top of the funnel. Unused tables are quarantined and their last users are notified. If nobody claims them, they're backed up and deleted. The program adopted it, and value stream teams now focus on migrating only the tables that still matter.
How we make it a habit
That question came from a habit we build into every project, and Shape Up is how we keep it. Shape Up is a way of working published by Basecamp. Its first step, shaping, happens before building anything.
Shaping is what our engineer did with the legacy displacement program. We look past the request (sort 450,000 tables) to the problem behind it (clear out what nobody uses). We decide how much time that problem is worth, which Shape Up calls the appetite. Then we sketch the simplest approach that fits, like a usage rule instead of months of analysis. The result is a short pitch that says what we want to see at the end and leaves the implementation details to the team.
Only then do we commit to a fixed cycle, traditionally six weeks (now less, with AI in the mix). If the work doesn't fit, we don't extend the deadline. We look at what we learned and decide whether to continue, reshape the work or stop.
We don't treat Shape Up as a rulebook. It's the most effective way we've found so far to solve the right problem in a fixed time. If we find a better one, we'll switch.
What AI won't do for you
Those tables could have been sorted in days with AI. But humans at the other end would still receive an incredibly noisy output.
AI will keep making the analysis faster, but it won't tell you which tables matter. That part is still our job, and it's why our projects start with shaping before anyone builds.
So before your team starts its next AI project, take the time to find the signal and filter out the noise. It's the cheapest investment you can do, but it's also the most valuable.
Sources
- Basecamp, Shape Up