From Demand-Driven to Objective-Led: A Shift in How Organizations Decide

Not long ago, I was working with an organization that was strongly demand-driven.

The company is in the middle of a transition. It wants to operate with more of a product mindset, with greater emphasis on objectives, outcomes, and empowered teams.

During one of our conversations, a tension became very clear.

On one side, the organization still operates largely through demands, projects, priorities, and delivery commitments.

On the other, a different logic is beginning to emerge, one that is closely connected to today’s discussions around the Product Operating Model: start with objectives, give teams more strategic context, and use outcomes to guide decisions about where to invest time and energy.

That tension led to the central idea of this article:

objective versus demand.

Not as a battle between two models.

But as a shift in the logic behind decision-making.

What does it mean to be demand-driven?

The demand-driven model is familiar to almost everyone.

Someone asks for something. The request is captured, enters a queue or work list, is analyzed, prioritized, planned, executed, and eventually delivered.

There is nothing inherently wrong with this.

This logic exists in project management, operations, technology, healthcare, financial services, and virtually every large organization.

Customers make requests. Internal functions make requests. Regulation creates requirements. Technical issues create work. Day-to-day operations generate an endless stream of needs.

So demand itself is not the problem.

Demand is part of organizational reality.

The problem begins when demand becomes the primary unit of decision-making.

The logic becomes:

“This request came in. We need to execute it.”

And an important question often gets skipped:

“What objective does this demand help us achieve?”

A demand-driven organization tends to organize work around what needs to be done.

An objective-led organization starts with what it needs to achieve. From there, it decides what is worth doing.

Being good at delivery is not the same as being good at achieving objectives

In a demand-driven organization, many conversations begin with the work itself.

What needs to be done? By when? Who owns it? How much will it cost? What are the dependencies?

In an objective-led organization, the conversation starts one step earlier.

What are we trying to achieve?

How will we know whether we are making progress?

And only then:

What is worth doing to get there?

This shift may sound subtle, but it changes the starting point of the decision.

Completing the work that was planned is one thing.

Achieving the outcome that justified the work is another.

When the work comes before the outcome

Imagine someone says:

“We need to build a new customer portal.”

In a demand-driven model, the conversation will usually move quickly toward scope, features, budget, ownership, dependencies, and delivery dates.

There is nothing wrong with discussing any of those things.

But notice what has already happened.

The work has been defined before the outcome has been clarified.

Now imagine starting somewhere else:

“We want to reduce by 30% the effort customers need to make to resolve simple requests.”

The conversation changes.

Maybe a new portal makes sense.

Maybe improving the existing portal would be better.

Maybe automation would have more impact.

Maybe the internal process is the real problem.

Maybe we can eliminate the need for that request altogether.

An objective creates room for choice.

A demand often arrives with a preferred course of action already embedded in it.

In a demand-driven model, we often decide what to do first and discuss the outcome afterward.

In an objective-led model, the sequence is reversed.

First, we clarify what we are trying to achieve.

Then we decide what is worth doing to get there.

Shoot first, paint the target later

There is an image I use in my book Team OKR in Action to describe a common mistake.

shoot first, paint the target later.

Imagine someone shooting an arrow at a wooden wall. Once they see where the arrow landed, they walk over and paint a target around it.

It looks like a bullseye.

But the target came after the shot.

I call this shoot first, paint the target later.

Something similar happens in many demand-driven organizations.

First, we decide what will be done.

Then we plan it.

Then we execute it.

And only afterward do we try to connect the work to an objective or explain what outcome the delivery was meant to produce.

First comes the shot. Then we paint the target around it.

This creates the appearance of alignment, even though the desired outcome did not actually guide the decision.

In an objective-led model, the desired outcome is made explicit first. The work comes next.

Order matters: objective before backlog

Another common mistake is starting with what is already on the work list, the to-do list, or the backlog.

Backlog is a term widely used in technology and product management to describe the list of work waiting to be addressed: requests, tasks, improvements, problems, technical work, and other items a team may need to tackle.

In many organizations, teams already have a long backlog.

Then someone looks at that list and asks:

“What is the objective behind all this work?”

The problem is that, at this point, the work has already been selected.

The objective arrives afterward, almost as a justification.

And quite often there is no single objective that truly connects all those items. The backlog looks more like a patchwork of requests from different stakeholders, competing priorities, and different levels of urgency.

In Team OKR in Action, I use a simple image to illustrate this distinction.

Backlog before OKR versus OKR before backlog.

The idea is straightforward.

Do not start with a list of work and then try to find an objective that fits it.

Start with the objective.

Then ask:

“Given this objective, what should actually be in our backlog?”

That changes the role of the backlog.

It stops being simply a repository of incoming work and becomes an execution mechanism that reflects the direction the team has chosen.

Where does OKR fit?

If we want to start with the objective, it helps to make that objective explicit.

This is where OKRs can help.

OKR stands for Objectives and Key Results.

For this discussion, however, the framework itself is less important than the logic behind it.

The Objective answers:

“What are we trying to achieve?”

The Key Results help answer:

“How will we know whether we are making progress?”

The objective provides direction.

The Key Results provide evidence of progress.

First, we clarify what we want to achieve.

Then we clarify how we will know whether we are moving in the right direction.

Only then does it make sense to discuss the work.

From demand to initiative

Not every demand should move directly into the backlog.

A demand is something that reaches the team: a request, a need, a requirement, an idea, an issue, or an opportunity.

It may be important.

It may be urgent.

It may even be non-negotiable.

But before turning it automatically into work, it is worth asking:

“What objective does this demand help us achieve?”

That question changes the role of the demand.

It stops being treated automatically as an instruction to execute and becomes an input into a decision.

Once the connection to an objective is clear, the demand may lead to an initiative.

In other words:

demand is input.

initiative is a choice.

An initiative is something the team chooses to pursue because it believes it can contribute to an objective.

This is where I like to use a simple template:

We believe that [INITIATIVE]

will help us achieve [OBJECTIVE].

We will know we are making progress when we see movement in [KEY RESULTS].

The first two words matter:

We believe.

Because an initiative is not a certainty.

It is a bet.

It is a hypothesis about how the team can influence an outcome.

Based on what we know today, we believe that investing in this initiative will help move us toward the objective.

That is very different from receiving a demand and concluding:

“We have to do this.”

The template forces a more useful conversation:

What objective does this demand support?

What initiative makes the most sense in light of that objective?

What outcome do we expect to influence?

What evidence would tell us that we are making progress?

The answer will not always be to do exactly what was originally requested.

And that is one of the most important shifts from a demand-driven model to an objective-led one.

Delivering is not the same as achieving an outcome

In a demand-driven model, the question is often:

“Did we deliver?”

In an objective-led model:

“Did we achieve the outcome?”

The portal was delivered. But can customers now resolve their issues with less effort?

The new feature was launched. But did retention improve?

The new process was implemented. But did service time decrease?

We modernized the system. But did the user experience improve?

The project was completed. But did the expected business or customer outcome materialize?

Delivery matters.

Without delivery, nothing changes.

But delivery alone does not guarantee impact.

Delivery is a means. The outcome is what justifies the investment.

Demand does not disappear. It gains a decision filter

An objective-led organization still receives demands.

The difference is that every demand does not automatically become committed work.

A few questions can help:

• What objective does this demand support?
• What outcome do we expect it to influence?
• How will we know whether we are making progress?
• Is there another way to achieve the same outcome?

This is not about adding bureaucracy to intake.

It is about improving the quality of the decision before committing capacity.

Some demands will still move almost directly into the backlog, especially regulatory, operational, mandatory, or risk-related work.

Others will need to be discussed, grouped, reframed, challenged, or even declined.

The objective becomes a decision filter.

It helps determine what deserves attention now, what can wait, and what may not deserve investment at all.

Where does the Product Operating Model fit?

Much of today’s discussion around the Product Operating Model is rooted in this shift.

It is not simply about replacing projects with products.

It is not about replacing demands with objectives.

It is not about renaming teams as squads.

It is not about eliminating planning.

And it is certainly not about abandoning management.

It is about changing how decisions are made and where decision rights sit.

Demand still exists, but it is no longer the only starting point.

Objectives provide strategic direction.

Context helps teams understand why that direction matters.

And teams are given more autonomy to decide how best to contribute.

This comes with an equally important shift: more autonomy and more accountability for product teams.

Instead of simply receiving requests to execute, product teams gain access to the strategic context, the objectives, and the outcomes the organization is trying to achieve.

Within a clear area of responsibility, they gain more room to decide where to focus and which initiatives to pursue.

For simplicity, imagine a box containing everything a team is responsible for.

That “box” is the team’s product.

Defining that box well, particularly in large organizations with multiple business units, shared platforms, complex structures, and different team topologies, is a topic for another article.

The point here is simpler.

Within its area of responsibility, the team needs enough context and decision-making authority to determine how it can best contribute to the objectives.

Autonomy does not mean freedom to do whatever you want.

It means having the authority to choose among different paths within a clear strategic direction.

And accountability means owning not only delivery, but also the outcomes the team is trying to influence.

Objectives do not eliminate management

When people hear about empowered teams and objective-led organizations, they sometimes imagine leadership setting a goal and saying:

“Here is the objective. Figure it out.”

That is not the idea.

Objectives do not eliminate management.

They change what management focuses on and how leadership engages with teams.

Instead of looking only at activities completed, milestones reached, or projects delivered, the conversation expands to include:

• what we are trying to achieve;
• what evidence of progress we are seeing;
• what we are learning;
• whether our current bets still make sense;
• and whether the outcomes are actually moving.

Management still matters.

But the conversation becomes less about controlling execution and more about the quality of decisions, progress toward objectives, learning, and outcomes.

Autonomy without clarity creates confusion.

Accountability without decision-making authority creates frustration.

The balance is: clear direction, autonomy to decide, and accountability for outcomes.

Demand is what comes in. Direction is what we choose.

Perhaps this is the simplest way to summarize the distinction.

Demand is what comes in.

An objective gives us a direction we choose.

Every organization must deal with both.

New requests, needs, problems, obligations, risks, and opportunities will continue to appear.

The goal is not to eliminate demand.

The goal is to avoid allowing each new demand to redefine the direction.

When the objective is clear, incoming demand gains context.

And better questions become possible:

• What deserves attention now?
• What should be prioritized?
• What can wait?
• What no longer makes sense?

And most importantly:

• what will move us closer to the outcome we are trying to achieve?

A simple change in the starting question

Perhaps the transition from a demand-driven organization to a more product-oriented one begins with a simple change in the first question we ask.

Instead of starting with:

“What do we need to do?”

Start with:

“What are we trying to achieve?”

Then:

“How will we know whether we are making progress?”

And only then:

“What is worth doing to get there?”

This is not about stopping demands from coming in.

It is about preventing those demands from determining the direction by default.

Objectives provide direction.

Initiatives are bets about how to make progress.

The backlog organizes the work required to put those bets into action.

The sequence matters.

Because when we start with demand, we risk shooting first and painting the target afterward.

When we start with the objective, the target is visible from the beginning.

We can choose where to aim, learn from what happens, and adjust the next shot.

If you enjoyed this article and want to go deeper, there are a few ways to continue.

📘 If you enjoy reading, explore my books Lean Inception and Team OKR.

💼 And if you want to bring this discussion into your team or organization, explore the services I offer. Or reach out to me on LinkedIn or through Caroli.org and we can set up a conversation.