Product Thinking: An Underrated Skill in Analytics Engineering
When people think about analytics engineering, they often think in terms of tools and execution: SQL, data modelling, orchestration, testing, pipelines that move data from one place to another. These things matter. They are the foundation. But over time, I’ve come to believe that the real difference between a good analytics engineer and a great one is something less technical and harder to teach: product thinking.
At its core, product thinking is about understanding people. Who is using the data, what decisions they are trying to make, and what reality they are actually operating in. A dashboard or a dataset is never the end goal. It is only useful if it helps someone see something more clearly, decide something more confidently, or act with less uncertainty. In practice, analytics work often begins with a request. A stakeholder asks for a metric, a dashboard, a model. The instinct can be to treat this as a task to complete: define the logic, write the SQL, build the output, move on. But product thinking introduces a different posture.
It slows the process down just enough to ask better questions:
What decision will this support?
How is this metric used in context?
What assumptions are being made about the underlying process?
What becomes clear quite quickly is that no single stakeholder ever sees the full system. Each person understands their own part of the process well, but the connections between systems, teams, and definitions are often fragmented. This is where analytics engineers quietly sit in a unique position. By working across data models, systems, and conversations, they begin to assemble a more complete picture than any one stakeholder might hold.
This is where the role becomes less about implementation and more about interpretation.
As you move through data sources and speak to different teams, patterns start to emerge. A metric that looks straightforward on paper may hide multiple definitions in practice. A process that appears linear may have hidden branches, exceptions, or manual interventions. What began as a simple reporting request can turn into something more revealing: inconsistencies in how performance is measured, gaps in operational understanding, or opportunities to simplify how information flows through the organisation. This is not incidental work. It is investigative. It requires curiosity, patience, and a willingness to sit with ambiguity long enough to understand what is actually happening beneath the surface. In many cases, the most valuable output of an analytics engineer’s work is not just the final dataset or dashboard, but the questions they surface along the way.
The strongest analytics engineers I’ve worked with tend to operate in this way naturally.
They don’t only deliver what was asked for; they build a mental model of the business itself. They become knowledge gatherers, connecting fragments of information across teams and systems into something more coherent. Technical skill enables this, but it is product thinking that gives it direction. There is also a quieter consequence to this way of working. When analytics engineering is approached with a product mindset, it often surfaces issues that extend beyond analytics itself. Misaligned definitions, fragile processes, unclear ownership, and unnoticed data quality problems tend to reveal themselves. These are not just technical issues; they are organisational ones.
From an investor’s perspective, this matters more than it might first appear. Decisions about growth, product investment, and resource allocation are only as strong as the clarity of the information behind them. When data work is treated purely as delivery, these underlying issues can remain hidden. When it is treated as product thinking, it becomes a mechanism for improving how well the organisation understands itself. As analytics engineering continues to mature as a discipline, I suspect product thinking will become one of its defining skills. Technical excellence will always be required. But the ability to understand context, challenge assumptions, and translate messy real-world processes into usable systems is what ultimately turns data work into something that genuinely changes how decisions are made.