A founder I know spent two weeks waiting for her data team to pull a report on which paid channel was producing the worst-quality leads. By the time it landed in her inbox, the next budget cycle had started, and the offending channel had eaten another forty thousand dollars.
Sixty percent of the answer in a day would have saved that money. The "right" answer two weeks late didn't.
This is how most companies under two hundred people fail in slow motion. Not bad strategy. Not bad people. Just too slow to act, because the data they need to decide isn't reachable.
Why fast business decisions win
Jeff Bezos has this old idea about two kinds of decisions. Type-1 are one-way doors. You can't take them back. Type-2 are two-way doors. If you walk through and it doesn't work, you walk back.
Almost every operational call in a small or medium business is a two-way door. Should we cut spend on the underperforming Facebook campaign? Walk it back next week. Should we change the email subject line? Test the old one Friday. Should we offer the new pricing tier to existing customers? Roll it back in a release. Bezos's argument was that two-way doors should be made fast, by one person, with about seventy percent of the data you wish you had. Waiting for ninety percent costs you optionality you can't get back.
The framework is right. The reality I see is different from the framework.
People aren't moving slowly because they're being cautious. They're moving slowly because the data isn't reachable. You have a hunch that customer X is about to churn, but you can't pull the activity history without bothering an engineer. You suspect the new pricing page is converting worse, but the analyst is buried until Thursday. You'd cut the ad spend tomorrow if only the dashboard wasn't six dashboards across three tools that don't agree with each other.
"The decision isn't slow. The data is slow. We confuse these all the time."
The hidden cost of slow data access
Run the numbers on the calls you didn't make in time.
If your CAC on a paid channel is eighty dollars and you keep spending for two extra weeks while waiting for an answer, you've burned through ten or twenty leads' worth of budget on something you'd have killed on day one. Multiply that across the seven or eight micro-decisions a real operating week contains, and the cost compounds. None of it ever shows up on a P&L line called "decision lag." It shows up as bad CAC, sluggish growth, a team that feels busy but isn't winning, and the feeling at the end of a quarter where you can't explain why the numbers didn't move.
I watched a friend's company miss a quarter because the head of marketing couldn't get attribution numbers in time for a board meeting. Not because the answer was hard. The answer was in their database. It was a fifteen-line SQL query someone could have written in an hour. But "someone" was the head of data, who was buried, and the marketing lead didn't know enough SQL to write it himself.
The damage wasn't the missing answer. It was that the wrong campaign kept running another six weeks because nobody could say in time that it was failing.
Why the data is slow
In most companies, the path from "I have a question" to "I have an answer" looks like this.
You ask the data team. They put your request on a queue. The queue is long, because everyone is asking. Three days later they get to your ticket. They ask you what you actually meant, which turns out to be different from what you wrote down. They write the SQL. They run it. They send back a screenshot. You realize the question changed two days ago, but you'll deal with the new answer later. You make the call from intuition anyway. The data arrives. It was already wrong.
The other path is the BI tool. Someone built dashboards last year. The dashboards answer last year's questions. The thing you need right now requires slicing the data in a way the dashboard wasn't designed for. You file a ticket. See above.
None of this is the data team's fault. They're solving the wrong problem. They're trying to be a service desk at human latency for a workflow that needs to run at chat latency.
Self-service data analytics: ask the database yourself
I build Datologist, so take this with the appropriate salt. But the thing I keep hearing from people who use it is some version of: "I knew the answer was in there. I just couldn't get to it."
You connect a database — PostgreSQL, MySQL, Snowflake, BigQuery, or any other supported database. You ask a question in plain English. An agent inspects your schema, writes the SQL, runs it, and shows you the answer plus the query it used. The whole loop is under a minute.
What this changes isn't the depth of your analysis. Datologist isn't going to replace a data scientist on a hard modeling problem. What it changes is the cycle time of the cheap, frequent decisions that quietly drive most of your outcomes. The "is this campaign working" question. The "how many trial signups came from that LinkedIn post" question. The "did the new onboarding reduce week-two churn" question. The questions you'd ask all the time if asking were free.
When the cost of asking drops to near zero, you ask more. You catch problems on day three instead of day fifteen. You kill bad bets before they compound. Teams start running on evidence instead of stories.
Move fast on these
- Paid channel optimization
- Pricing page A/B tests
- Email subject and copy
- Onboarding flow tweaks
- Feature rollout to a cohort
- Anything you can roll back by Friday
Move slowly on these
- Hiring a senior executive
- Choosing a fundraising path
- Signing a multi-year contract
- Public commitments to customers
- Architectural decisions with high switching cost
- Anything that ends a relationship
When fast decisions are the wrong call
Worth saying out loud: speed is the right move for two-way doors. It's exactly wrong for one-way doors.
Hiring a senior exec. Picking a fundraising path. Signing a multi-year contract. Making a public commitment you'll be held to. These deserve the careful treatment. Not because the data is harder to gather, but because the consequences of being wrong don't unwind.
Most of what fills your week isn't like that. Most of your week is reversible by Friday. Those are the ones where speed compounds.
Teams that win compete on decision speed
Operators won't beat the dashboard companies on dashboards. They'll beat them on cycle time. When the person who feels the pain of the decision can also answer the question that informs it — without filing a ticket, without waiting for Thursday, without learning SQL — the whole rhythm of the company changes. That's what faster business decisions look like in practice: not heroic intuition, but a shorter loop between question and answer.
That's the bet behind Datologist. See how it works, or look at pricing.