What the role actually does
A data analyst turns questions into evidence. They model data from several sources so it can be queried coherently, investigate questions nobody has answered before, and build the reporting that lets other people answer the routine ones themselves.
The valuable part is the investigation. A good analyst finds things nobody asked about — that one acquisition source produces clients who churn at twice the rate, that margin varies by project type in a way nobody had noticed, that the metric everyone watches has no relationship to the outcome it is assumed to predict.
They also do a maintenance job that is invisible until it stops: keeping the data model working as upstream systems change. Every integration breaks eventually, and in a business with no analyst it breaks quietly and the dashboard becomes confidently wrong.
What they are not is the person who makes numbers arrive. Building a reliable weekly signal that reaches a founder without anyone logging in is an engineering and design job, and it is what most small businesses actually need first.
It is also worth noting how differently this role behaves at small scale. In a large company an analyst serves many internal customers; in a fifteen-person business they serve one, and one person's genuine open questions arrive in bursts rather than continuously.
When you genuinely should hire one
Hire when you have questions whose answers you cannot guess. That is the real qualifier. If there is a genuine pattern hiding in your data — about which clients are profitable, what predicts churn, where margin actually goes — and it would change decisions, an analyst is the only way to find it.
Hire when data volume exceeds inspection. Below a few hundred clients or projects, most patterns are visible by looking. Past that, the interesting relationships are not discoverable by eye, and the business is making decisions on impressions from a sample it cannot see.
Hire when several people are asking different questions weekly. One person's questions rarely fill a role; four functions each needing analysis does, and at that point the alternative is everybody building their own conflicting spreadsheet.
As general context, analyst salaries in the US market broadly run from around seventy thousand for junior roles to well past a hundred and twenty for senior ones, moving with technical depth. Loose orientation only — and worth noting that this role also has an unusually strong fractional and part-time market, which is often the right shape at small scale.
And hire when somebody credible outside the business is going to interrogate your numbers — a lender, an acquirer, a board. Withstanding that scrutiny is a specific skill, and it is not the same as producing a weekly report.
Where the hire fails
It fails when the data does not exist. Analysts work on what has been captured, and most of what a founder-led business needs to know is about behaviours rather than transactions — days since a client heard from a human, work past its promised date, decisions that routed through the founder unnecessarily. None of that is recorded anywhere, and an analyst cannot analyse it into existence.
It fails when the questions are closed. An analyst hired to produce a weekly number is an expensive, over-skilled reporting mechanism, and they will know it. The output will be excellent and the role will be dull, which is a short tenure.
It fails on the delivery problem. An analyst produces answers by being asked, and a founder's week does not reliably contain the act of asking. Businesses hire analysts and then do not consult them, for exactly the same reason they buy dashboards and do not open them.
And it fails when nobody acts on what is found. An analyst who identifies that one source produces clients who churn, in a business with no mechanism to change acquisition, has produced a fact rather than a change. That is demoralizing quickly.
The most avoidable failure is hiring an analyst to settle arguments about the numbers. Those arguments are about definitions rather than data — two people using one word for two meanings — and an analyst can document the disagreement without having any authority to end it.
What has to exist first
Capture for the things you want to know about. If the question is behavioural, something has to be recording the behaviour, and the recording has to be a byproduct of work rather than a task on top of it — logging that requires a separate act does not survive a busy month.
Written definitions for the words that cause arguments. An analyst walking into a business where revenue means three different things to three people will spend their first quarter as a referee, and the disputes will resume the moment they stop refereeing.
A delivery mechanism for the routine numbers, so the analyst is not the mechanism. Signals that push to where people already are, on a rhythm, without anybody remembering to ask. That frees the analyst for the open questions, which is the only work that justifies the role.
And a list of decisions the analysis would change. If a finding would not change what anybody does, it is trivia — expensive, accurate trivia. Writing the decisions first is what keeps the role pointed at something.
Somebody who will act on a finding. An analyst who identifies that one acquisition source produces clients who churn, in a business with no mechanism to change acquisition, has produced a fact rather than a change — and facts that change nothing stop being produced within about two quarters.
How to tell which you need
Write the first month's question list, then sort it. Open questions — where you genuinely do not know the shape of the answer — argue for an analyst. Closed questions argue for instrumentation.
If the list is mostly open and your data volume is genuinely past what inspection handles, hire, and consider hiring fractionally first. This is one of the few roles where a few days a month gets you most of the value, because investigation is bursty by nature.
If the list is mostly closed — how many, how long, how much, who has not heard from us — you do not need an analyst and hiring one will frustrate you both. You need a small number of decision-linked signals that arrive on a rhythm, and the capture underneath them.
The clarifying question, if it is still ambiguous: when you last wanted to know something about your business, was the problem that nobody could work out the answer, or that nobody had recorded the input? The first is an analyst. The second is a build, and no amount of analytical talent substitutes for data that was never captured.
If you do hire, give them one open question to start with rather than a reporting backlog. The first month sets what the role becomes, and a month spent building weekly reports establishes the role as a reporting function permanently.
Analysts answer open questions; most founders have closed ones. Sort your first-month question list, and if the inputs were never recorded, no analytical skill will recover them.