I have the fortune of working at incident.io: a well-funded startup with founders that have technical background at high-performing companies, and a data team. Even when I started, we at least had a data team of 1. For a lot of organisations, that’s not the case. Whether you’re bootstrapped with a team of 10, have less technical expertise throughout the organisation, or haven’t been able to prioritise data, it's time to stop winging it on data and make a change.

Data as your backbone

If you don’t have a few core dashboards that you’re looking at every day, you’re probably not making the best decisions. If it takes you half an hour to answer a simple question because your data is disjointed and you're connecting the dots by hand, that's a sign for you to pause other work and get your data into a good state.

Good data you can trust isn't a nice-to-have; it's essential to running your business. You need to be able to walk into every board meeting confident that you either have the answer to all questions, or know how to get it quickly as a follow-up (ideally the same day). Equally, if you’re building a product, you need to be able to measure how much it gets used.

This doesn’t mean data makes decisions for you; that’s your job. What it does is give you the evidence to back a decision (or help disprove your intuition and avoid costly mistakes!), and a way to validate afterwards that you got it right.

For that to happen, data has to sit at the core of every function, not just product. Marketing, go-to-market, and operations all need to look to data too. That doesn't mean everyone becomes a data engineer, or even touches the data directly, but they need to know what questions to ask of the data. And when those questions can’t be answered by the data you have, that means it's time for another round of investment in the data setup.

Data is P0, not a sidequest

Believing all of that is one thing, resourcing it is a different matter. There are two ways this goes wrong: you hand someone a nebulous "sort out our data" task alongside their existing work, or some consultant promises to set it all up for you with no input. Your data is your business, and while you can definitely rely on outside help, you need to make sure you remain in the loop as it gets built, so that what gets built reflects your needs.

Both of these options result in the same outcome: 6 weeks later, you have a half-built data stack that no one trusts and that isn't maintained. Instead, pull someone, realistically an engineer or someone with an engineering background, off their normal work for a week or two and make sure that time is protected.

Equally important here is that you give this project to someone who can go across the org and talk to the right stakeholders, and that you communicate this to leaders as a priority, making sure they give up time for this project. Because what's hard about data isn't the stack itself. What takes time is sitting down with the people who own each function and pinning down what numbers they care about and what those numbers mean. Every leader should end up with some form of homework in this process, to define what data they need.

Getting this protected time will give you outsize returns, and will make maintaining the data stack much cheaper in the long run. It'll ensure that the foundations are all in place, and that setting up new data is much more a routine 30-minute task than a half-day endeavour (and ideally, something that doesn't even need an engineer most of the time).

Make sure you start from a good place

Good data comes from a good data stack. This means you have the right tools in place to pull in data from all your tools, transform and relate it, and finally analyse it. There are lots of tools, but in short this boils down to:

1. Fivetran to get all your data into a single place (BigQuery is a safe bet if you’re unsure)
2. dbt to transform your raw data into something that’s easier to work with
3. A BI tool like Omni, Hex, Cube, or others. Here, look for a tool that’s building to be AI-native.

Naturally, tools come and go, these are relevant now, but use your judgment and do some research.

Most of the hard work of a good data setup will then sit across configuring the BI tool, and setting up the right dbt models. If you lack the expertise to get that setup well, you can always start by asking your favourite LLM like Claude, and then sanity check it with someone experienced like a data engineer.

Connect the data

As you’re building out your dashboards and BI tooling, don’t accept “we don’t have that data” as an answer. Instead, figure out:

1. If the data exists, why isn’t it being pulled through? Unless there’s some really good reason for it, get that data source added.
2. If the data doesn’t exist, ask how you can start tracking it? Is there a team that needs a new tool, or is there functionality in their existing tools that they just aren’t using? And make it the responsibility of leaders in these functions to figure this out; it’s important that leaders in each area know the capabilities of their own tools. Of course, if they run out of their depth, they can always ask for help!
3. If the data is hard to connect to other data, fix the model. This will likely require a bit more expertise, likely someone who has an understanding of your transformation layer (i.e. dbt).

Establishing good definitions

I mentioned earlier you need to know what questions to ask of the data - to ask good questions of the data, you often need to have at least a rough understanding of what data you would want in order to answer that question. For example, if I want to understand “how much money will we make in Q3?”, it’s of course useful to get a headline “forecast” number. Beyond that, however, you’ll want to understand which details matter, and this might be specific to your business, so make sure you sit down to define it well. For example, in this fairly generic forecast example, odds are you want to understand, at least: * How much qualified pipeline do we have in the quarter? * What’s our aggregate win rate - i.e. for $100 of qualified pipe, how many dollars convert to revenue. * (maybe) what’s the distribution of deals? If 80% of your qualified pipe sits across 3 deals, you’ll care less about aggregate win rate than the deal specifics (you can’t win 70% of a $100k deal; so fewer large deals means win rate may be less relevant) * How many close-in-quarter deals do we usually get per rep? If we typically close $100k/mo in addition to any pipeline we have when the quarter starts, you probably want to account for that. This will largely depend on how long your deal cycles are.

There are lots more things you’ll want to define here, and most will be specific to your business. For example, you’ll only be able to track your COGS if you first define the goods being sold, and the cost that contributes to each line item, and these tend to be very business-specific, and particular to your pricing model too.

If your BI tool then supports semantic layers, you should take these definitions you come up with and make sure any AI tooling is aware of it.

Verified dashboards for core data

While you want everyone in your org to be able to self-serve data questions, there are some questions that are either so commonly asked (“how are sales doing so far this quarter?”) or so critical (think board reporting metrics) that you want to have it prepared and verified. Identify those, and then get those few dashboards built out with an expert who can sit with you through several sessions to define exactly what goes on the dashboard, and how you get the right numbers.

Over time, you’ll likely want to expand this list of verified dashboards, but start small and let demand dictate what data deserves to be promoted into a shared and verified dashboard.

Metric reviews for the whole company

Once you have a reusable dashboard or two, you should make sure everyone in the business is looking at those regularly. One way to do that is to have a metrics review - maybe once a month, maybe once a quarter. The cadence matters less than doing it—you get an opportunity to make everyone aware of how the business is doing, and everyone across the business is reminded that you have data available, and that they should use it.

Ideally, you should also push for leaders across different functions to have dashboards for their work, letting the data-backed approach trickle down through the organisation.

Impact reviews

One concept I love at incident.io is “impact reviews”. Whenever a moderately sized (usually ~a couple weeks) project completes, we’ll do a small impact review. This means building a dashboard of the success metrics (which we establish at the start of a project), and perhaps related metrics we think are interesting, and reviewing them ~6 weeks after launching a feature.

This allows us to validate whether we built the right thing, and to identify any gaps in what we built. Not only can we see whether people use a new feature, but we can also see, for example, if they’re using an advanced flow we decided to build to handle some edge case, or understand the distribution of usage among customer cohorts. For example, “large enterprise customers are using this far less than smaller customers” might let us infer that we’re missing some features that large enterprises need, or that the onboarding flow doesn’t serve them well, and is a nudge to go talk to some of those customers to understand why they’re not using the feature.

This is a great practice that makes you feel much more accountable for not just shipping a feature, but also rolling it out. However, this can also extend beyond product. If you’re doing a marketing launch, that should probably have some success metrics too, and the same goes for revamping a sales process or rolling out a new peer feedback system.

Don’t let it go stale

Finally, data isn’t a point-in-time thing. It’s something that changes constantly. This is more true in product than anywhere else; new data models often get created and removed near daily. If you’re serious about good data, you need to be making sure you keep asking questions of the data, which forces you to keep models fresh. And remember, never accept “we don’t have that data” or “we can’t answer that”.