"We need a data strategy" usually means one of two different problems wearing the same sentence. Sometimes it means the organization has data scattered across systems that don't talk to each other, and the fix is architecture: pipelines, a warehouse, ownership of definitions. Sometimes it means the organization has perfectly good data and no agreed answer to what it's for, which decisions it should inform, who is allowed to act on it, and what it would mean to monetize it rather than just report on it. The first is an engineering problem. The second is a strategy problem. Hiring for one when you have the other is how a data initiative spends a year and changes nothing.
The test: is the constraint access, or judgment?
Ask the question directly before scoping any engagement, internal hire, or vendor contract: if every relevant number were sitting in one clean table tomorrow morning, would the organization already know what to do with it?
If the honest answer is yes (the models are agreed, the decisions are defined, the only thing missing is getting the data into a usable shape), the problem is access, and the fix is engineering. Buy or build a pipeline, hire for the plumbing, and resist the temptation to also relitigate strategy while you're in there.
If the honest answer is no (the data would arrive and the room would still argue about what it means, which team owns the definition of "active customer," or whether the company is even organized to act on what the data would say), the problem is judgment, not access. More pipeline work will not fix that. It will just make the argument happen faster, with cleaner numbers.
Most organizations that stall on "data strategy" have quietly been buying engineering to solve a judgment problem for several budget cycles running.
What each path actually requires
If it's an access problem: the work is architecture: deciding where data lives, who owns each definition, and how governance keeps the warehouse from becoming the same mess as the systems that fed it, just centralized. This is buildable in-house if you have the engineering depth, or a well-scoped vendor engagement if you don't. It is the more commodity half of the two problems, and the market for solving it is mature.
If it's a judgment problem: the work is deciding, before any pipeline gets built, which decisions the data needs to serve, what "good enough" looks like for each one, and who has the authority to act once the answer is known. Skip this and the eventual pipeline gets built to a spec nobody actually agreed on: technically correct, and still unable to settle the argument it was funded to end. This is strategy work, and it has to happen before the architecture decisions, not after them, because the architecture should be shaped by what the data needs to do.
The single most common failure mode is buying the first kind of help to solve the second kind of problem, because engineering has a clearer scope of work to write a purchase order against. A judgment problem is harder to put a line item on, so it gets deferred instead of solved, and the pipeline ships without an owner for what it's supposed to prove.
Evaluating rigor before you trust the output
Whichever path applies, the same discipline underneath the decision matters: does anyone actually check whether the analysis is right, or is a plausible-looking output being taken on faith? At AfterQuery, that meant building LLM evaluation frameworks for financial reasoning: grading model output against more than 1,500 valuation and accounting question sets rather than trusting a confident-sounding answer. The same habit applies to any data initiative: before scaling a model, a dashboard, or a reporting pipeline past its pilot, know specifically how its output gets checked, and by whom. An organization that can't answer that question is scaling on hope regardless of how clean the underlying data is.
Where this fits
Data strategy consulting is the judgment-side work: architecture, governance, and monetization decisions scoped to what the organization actually needs the data to do, before any pipeline gets built. It sits next to AI implementation consulting, where the same access-versus-judgment question decides whether an AI program is solvable with a vendor tool or needs the operating-model work first, and IT & software consulting for the architecture and systems decisions once the strategy question is settled.
If you're not sure yet whether your organization has an access problem or a judgment problem, that is worth thirty minutes before either gets funded. Start a conversation: we would rather help you scope the right one than help you build the wrong pipeline faster.