The challenge of setting goals

Every new tech initiative starts with high hopes. Let's say, a company decides to migrate their data infrastructure to enable more AI capability. Leaders talk about competitive advantage. Business wants revenue growth and happier customers. Architects are already debating the new capabilities while IT worries about security and scalability. Management says we need to move fast. Operations says the models are running on nightly batch data and that needs to change. The product owner says this project is a perfect opportunity for exanding the product offering.

There are expectations, concerns, ideas, slide decks flying around. Engineers are already under pressure.

Everyone has their own answer to why this project exists. So how do we extract a clear, actionable project goal from this stream of seemingly non-related statements?

The hierarchy of goals

The first thing to understand is that most of those competing "wants" aren't actually in conflict — they're just operating at different levels of project reality.

Think of it as a pyramid. At the top sits company strategy: where the organization wants to win, what competitive advantage it's building. Below that is the business layer: cut costs, grow revenue, improve retention, make a customer segment happy.

Below business goals comes the operational layer — the sweet spot where strategy gets concrete enough to act on. Here you might say: Ensure customer-facing models operate on data less than one hour old so that sales opportunities are not lost due to stale information. That's specific, it points at real work, and it can be measured. But it still doesn't prescribe a solution. This is what should be in most cases used as a project goal.

A useful test: if you changed the technical approach entirely, would the project goal still make sense? If yes, it's a goal. If the goal collapses the moment you change the technology, check for a problem.

Getting to the technical part

Once the operational goal is clear, engineering teams can start translating it into technical goals.

A technical goal is still a goal — not a technology selection. "Migrate to XYZ" is not a goal, it's a decision. "Reduce data pipeline latency so that models run on current data, not last night's batch" — that's a goal. The difference matters: a goal survives a change in technology, a decision doesn't.

Technical goals are usually enabling goals. They don't stand on their own — they exist to unlock something above them. "Reduce pipeline latency" only means something when connected to why: so that operations stop losing deals over stale data, so that the business can offer a real-time tier. Strip that connection and the technical goal becomes just another thing to deliver, with no way to know if it was worth it.

This is why a technical goal alone is rarely enough to run a project on. Without the operational or business goal above it, teams have no way to make trade-offs, no way to know when good enough is good enough, and no way to explain the value of what they built.

Many organizations have experienced the same platform migration story: halfway through, every team is working hard toward "migrate to XYZ" as if that's the finish line. The speed improvement — the actual pain point — is never discussed. By the time it's done, the performance gains barely justify the investment and nobody can explain what went wrong.

Once you have a genuine technical goal, everything below it shifts from what we want to what we're going to build or try.

This is where you find:

• Initiatives or bets — major efforts toward achieving the goal
• Epics, features, stories, work packages — delivery increments that make up an initiative
• Tasks — the day-to-day work

The further down you go, the more solution-specific things get.

Putting it all together

Here is an approximate map of how goals at different levels connect to one another and to execution.

Do you need to draw out this entire hierarchy for every project? No, no you don't. But understanding that the layers exist — and that people talking at different levels aren't always disagreeing — will save you from a lot of frustration.

Also, having at least the operational goal written down and visible somewhere might save your project from drifting when things get complicated.

How does a good project goal look like?

Here are a few examples of what people actually think is a project goal. Tap on each one to see what's wrong  — or right  — about it.

To sum up, a good project goal sits between business ambition and technical execution: clear enough to drive action, yet independent of any particular technology or implementation. When teams can distinguish goals from decisions, they're far more likely to stay aligned on the outcome that actually matters.