Objectives, Not Tasks: How to Set Objectives Without Dictating the Solution

What does it mean to set an objective without dictating the solution?

Setting an objective without dictating the solution means the objective says what should change, by how much and by when, and stops there. Marty Cagan of SVPG, in his essay on empowered product teams, states the test: "The litmus test for empowerment is that the team is able to decide the best way to solve the problems they have been assigned (the objectives)." An objective that lists the features to build has already made that decision for them.

Most teams are not getting this clarity either way. Gallup's 2026 engagement update, written by Jim Harter, found that in the first half of 2026 only 49 percent of U.S. employees strongly agreed that they know what is expected of them at work. That survey covers all U.S. workers, not product teams, and it measures clarity rather than autonomy. What it still shows is that half of people start their week unsure what they are aiming at, and a task list does not fix that: it tells people what to do, not what they are trying to achieve.

What must a good objective contain?

Four things, and each one answers a question the team will otherwise ask you in every meeting.

Component	Question it answers	Example (fictional team-notes app)
Direction	Where are we heading, and for whom?	New workspaces start collaborating, not just writing alone
Distance	How will we know we are succeeding, and when is enough enough?	Share of new workspaces with a shared page edited by 2+ people in their first 3 days rises from 30 to 45 percent
Deadline	By when?	End of June
Contribution	Why does this matter to the business?	Workspaces that collaborate early are the ones that renew, so this moves retention

Distance is the part most often missing. "Improve collaboration" gives direction but no way to tell whether the team has done enough, so it either never ends or ends whenever someone senior loses interest. A metric with a current value and a target tells the team when to stop and move on, which is as useful as telling them where to go.

Contribution is the part most often skipped. A team that knows the objective matters because early collaboration predicts renewal will make better calls when two good ideas compete than a team that only knows the target number.

What must a good objective leave out?

The route, the deliverables and the tactics. No feature names, no screen changes, no channels, no list of tickets. Those are exactly the decisions the team closest to the problem is best placed to make, and the ones most likely to be wrong when written down in advance.

Cagan puts the contrast as a question every team can ask itself: "Are you assigned problems to solve, rather than given lists of features to build?" A feature list written into an objective has two costs. The team cannot find a cheaper or better route, because the route is fixed. And when the feature ships and the number does not move, nobody learns anything, because the team did what it was told and the objective is technically met.

A useful edit rule: read the objective and underline every noun that describes something the team would build. Each one is either a hidden outcome (rewrite it as the change it was meant to cause) or a genuine commitment (move it to a separate list, see below).

What do before and after rewrites look like?

The rewrites below use fictional products and illustrative numbers. Each "before" names a solution; each "after" names the outcome the solution was supposed to cause and leaves the route open.

Before (task disguised as objective)	After (objective)
Launch a five-step onboarding wizard by March	New workspaces create their first shared project within 3 days of signup: from 30 to 45 percent by the end of Q2
Add dark mode, CSV export and SSO to the enterprise plan	Enterprise trials convert to paid at least as often as mid-market trials, from 12 to 20 percent this quarter, so the open pipeline closes
Send three reminder emails to inactive users	Paying accounts with no activity for 30 days fall from 18 to 10 percent by September
Rebuild search on a new engine	Searches followed by a click on one of the first three results rise from 40 to 60 percent this half

Notice what the rewrite makes possible. The team working on enterprise conversion may find that SSO is the blocker and ship it in two weeks, or that the real blocker is a security questionnaire sales cannot answer, which no feature would have fixed. The first objective would have delivered three features either way.

When is it right to specify the solution?

Sometimes the solution is the commitment. A contract promises a specific integration by a specific date, a regulation requires a specific consent flow, a security issue needs a specific fix. Pretending those are open-ended outcomes is its own kind of dishonesty. List them as committed deliverables, separately from objectives, and say plainly that the team does not get to choose the route on those.

The second exception is capability. Cagan is direct that autonomy depends on the team being able to use it: "So there is no true and lasting empowerment without competence." A newly formed team, or one working in a domain it does not know yet, may need a tighter brief and more coaching for a cycle or two. The answer is to coach toward outcome-based objectives, not to make feature lists the permanent format.

How do clear objectives prevent micromanagement?

Micromanagement usually starts with unclear expectations, not with a controlling manager. When the objective does not say what success looks like, the manager has no way to judge progress except by checking the work itself, so they review designs, rewrite tickets and ask for daily updates. The team experiences that as distrust; the manager experiences it as the only way to know whether things are on track.

A complete objective removes the reason for that. If direction, distance, deadline and contribution are agreed up front, the check-in becomes "where are we against the number, what did we learn, what is blocking you" rather than "show me what you built." Agree the objective together, let the team propose the route, and review the first draft of their plan early rather than the finished work late.

How is this different from writing OKRs?

An OKR is one format for an objective: the objective plus a few measurable key results for one cycle. Everything above applies to the objective half. Key results carry the same risk in a different place: a key result like "ship the new wizard" smuggles the solution back in. Google's re:Work guide to OKRs is blunt about it: "OKRs are not a shared to-do list." For where OKRs sit next to KPIs and a North Star Metric, see OKR vs KPI; for the definition and how key results are graded, see what is an OKR; and for choosing measures that move early enough to steer by, see leading vs lagging indicators.

Where does this fit in Builders Camp's bootcamps?

Setting Powerful Objectives is a one-week bootcamp with 9 microlessons, directed by Andre Albuquerque and part of the Data & Analytics Specialist Track. Its published topics include outcome-first goal setting, choosing metrics the team can influence, turning objectives into initiatives with clear ownership, review cadence and accountability, and common goal-setting traps such as vague goals, vanity metrics and unowned initiatives. Its practical challenge asks members to write SMART objectives for a new streaming feature, define how each will be tracked, and draft the brief they would share with their team; the write-up of that challenge shows the brief. If your team already runs OKRs, How to Design OKRs, also directed by Andre Albuquerque, lists initiatives versus outcomes and avoiding the task-list trap among its published topics.

Builders Camp runs live and self-paced bootcamps in product management and AI product building. See the Setting Powerful Objectives bootcamp for dates and the full syllabus.