Setting Product Priorities With GOD: Goals, Objectives, and Deliverables

For most of software's history, planning mattered, but sloppy planning was survivable because building was slow.

Building was the bottleneck. A feature took weeks to ship, so a fuzzy spec got corrected in flight. You'd start building, discover what you actually meant halfway through, and the slow grind of implementation gave you time to course-correct. The plan was a rough sketch because the building was going to be the expensive part anyway.

That's over.

AI coding collapsed the cost of building. A developer with good tooling now opens five or six pull requests a day instead of one or two a week. AI already writes a large share of the code that gets committed, north of 40% by recent measures.¹ Code that took weeks now takes hours. The thing we spent decades optimizing is no longer the thing holding us back.

So where did the bottleneck go? It didn't disappear. It moved to the two places building used to hide: deciding what to build, and verifying that what got built is right. Planning and verification. A 2026 analysis of 8.1 million pull requests across 4,800 organizations found developers feel about 20% faster with AI while actually running roughly 19% slower in delivery, because review time ballooned as generation sped up.² Trust is the root of it: most professional developers say they don't fully trust AI-generated code without checking it themselves.³ The constraint relocated upstream and downstream at once, and squeezed the part in the middle that used to be the whole job.

This changes what product priorities are for. When building was slow, priorities were a way to ration scarce engineering time. Now building is cheap and the scarce resource is clear thinking about what's worth building and proof that it works. Priorities aren't a rationing tool anymore. They're the bottleneck itself.

Which means the quality of your goals and objectives now directly sets the speed of your team. A vague plan used to cost you a few wasted weeks. Now it costs you a flood of cheaply-built features that nobody can verify and nobody's sure they needed.

So let's get the planning layer right. Three concepts do the work, and they spell GOD: goals, objectives, and deliverables. A goal is where you're going. An objective is the proof you got there. A deliverable is the thing you build to move that proof. The letters run G to O to D, but it isn't a finish line. The D loops back to the O, because the only way to know a deliverable mattered is to check whether it moved the objective. It's a cycle you run, not a checklist you complete. Most teams confuse the three constantly, so start there.

#Goals and objectives are not the same thing

A goal is a qualitative statement of aspirational intent. Simple, big, inspiring, no numbers. It's the destination.

• Become the tool people reach for first in our category.
• Make new users succeed in their first week.

An objective is a measured change in customer behavior that proves you got there. It names three things: who, doing what, by how much. The "who" is a real customer, the "what" is something they now do differently because of your work, and the "by how much" is the number that makes it checkable. Not what you shipped, not how your system performed. What people do, and how much more of it. You nail it or you don't.

Some people call these OKRs or KPIs. Same idea, fancier acronym. The label doesn't matter. What matters is that all three parts are present. Drop the "who" and you're measuring a system, not a customer. Drop the "by how much" and you've written an aspiration, not a proof. If your objective doesn't have a person doing something in measurable quantity, it isn't measuring value yet.

• Grow the share of new users who finish a real task in week one from 32% to 55%.
• Lift the share of trials that convert to paid within 14 days from 6% to 15%.

A goal without objectives is a vibe. Objectives without a goal are a scorecard nobody can read. Together they say where you're going and how you'll know you arrived.

#The trap: outputs dressed up as objectives

Here's where almost everyone goes wrong. The goal is usually fine. The objectives are where it falls apart, because people reach for the number that's easiest to measure from the inside instead of the number that proves a customer got value.

There's a clean test, and it follows straight from the definition. A good objective measures what your customer does differently because of your work. A bad objective measures what your team ships, or what your system does, neither of which proves anyone got value. Outcomes, not outputs. If there's no human doing something in the metric, you've measured the wrong thing.

The fastest way to feel the difference is to put the weak version and the strong version side by side.

Goal: Become the product people trust most in our category.

• Bad objective: Hit 99.9% uptime for two quarters. (A system metric. Uptime can be perfect while customers quietly churn. It measures your plumbing, not their trust.)
• Good objective: Grow the share of teams running a mission-critical workflow on us from 30% to 55%. (A behavior. Putting critical work on you is what trust actually looks like.)

Goal: Turn happy users into a growth engine.

• Bad objective: Reach a net promoter score of 50. (An attitude survey. It asks how people feel, not what they do, and feelings don't compound.)
• Good objective: Lift the share of new signups arriving through an existing user's invite from 8% to 25%. (A behavior. Referring is the action NPS was only ever a weak proxy for.)

Goal: Win the enterprise buyer without losing the solo builder.

• Bad objective: Close 10 enterprise deals this year. (An output, measured from your side. Closing a deal isn't the customer getting value, it's you booking revenue.)
• Good objective: Grow accounts that expand from 1 seat to 5+ within 60 days from X to Y. (A behavior. A team pulling in more seats on its own is the customer proving the value for you.)

One caveat, because great product people smell naivety instantly: not every objective has to be a pure behavior change. A guardrail is fair game. "Hold solo-tier week-one activation flat while we chase enterprise" is a perfectly good objective, because it protects a behavior you've already earned. The rule isn't "behavior only." It's "stop mistaking your outputs for proof of someone else's value."

Notice the other pattern too. The goal never contains a number, and the objective is nothing but a number and a deadline. If your "goal" has a metric in it, it's an objective wearing the wrong label. If your "objective" can't be checked off as hit or missed, it's a goal in disguise.

That pairing is the entire foundation of a product priority. If a roadmap item doesn't trace to an objective, and that objective to a goal, you don't have a priority. You have a thing someone wanted to build.

#Deliverables: the thing you actually build

So far everything has been a planning artifact. Nobody ships a goal. Nobody ships an objective. They're the destination and the proof. At some point you have to build something, and that something is a deliverable.

A deliverable is an output. It's the concrete thing your team produces and ships: a feature, a flow, a redesign, an integration. It hangs directly off an objective, and the objective is the only reason it exists. "Ship one-click import" is a deliverable. "Rebuild the onboarding flow" is a deliverable. They are not outcomes, and that distinction is the whole game. The outcome is what the customer does differently. The deliverable is what you build hoping to cause it.

This is the layer most teams confuse with progress. Shipping a deliverable feels like winning. It isn't. It's a bet that this output will move that objective. Until the number moves, you've shipped work, not value. A deliverable that ships and doesn't move its objective isn't a success with a measurement problem. It's a miss.

So deliverables hang off objectives like this:

Objective: Grow the share of new users who finish a real task in week one from 32% to 55%.

• Deliverable: Replace the six-step signup with a single screen.
• Deliverable: Auto-generate a starter project from the user's first input.

Objective: Lift the share of new signups arriving through an existing user's invite from 8% to 25%.

• Deliverable: Add an in-product invite flow with a shareable link.
• Deliverable: Build a referral dashboard so users can see who joined.

Each deliverable points at exactly one objective. If you can't name the objective a deliverable serves, that's not a deliverable, it's a distraction with a ship date.

#Why this matters: deliverables are what AI made cheap

Here's the part that changes everything. Of the three concepts so far, the deliverable is the one AI collapsed in cost.

Goals, objectives, the judgment about what's worth building, none of that got cheaper. The deliverable did. "Build xyz" used to be the expensive, scarce thing you rationed your whole roadmap around. Now a developer with good tooling produces deliverables in an afternoon that used to take a sprint.

That inverts how priorities work. When deliverables were expensive, the deliverable was the priority. You picked a few because you could only afford a few, and the picking did the prioritizing for you. Scarcity was the filter. Now that filter is gone. You can build almost any deliverable you can name, fast. So the deliverable can no longer be the unit of prioritization, because nothing is scarce enough to force a choice.

The objective becomes the filter instead. When you can build anything, the only question worth asking is which deliverable moves an objective. A free deliverable with no objective above it isn't a quick win. It's fast garbage, shipped with confidence.

This is also exactly the seam where humans still matter. AI builds the deliverable. It cannot tell you which deliverable is worth building, and it cannot tell you whether the one you shipped moved the objective. The deliverable is where human planning hands off to cheap machine building, and where it hands back to human verification. Get the objective right and the cheap building is a superpower. Get it wrong and you've just automated the production of things nobody needed.

And the faster this gets, the more the planning matters, which is the part most teams have backwards. When building was the bottleneck, a sloppy objective got sanded smooth by the sheer time it took to implement. You had weeks to realize "make onboarding better" actually meant "cut the signup steps," and you fixed it before launch. That buffer is gone. When the deliverable ships in an afternoon, there's no slow grind to catch your fuzzy thinking. You get exactly what you pointed the build at, fast and at volume. The precision you used to add during implementation now has to exist before it.

This is the real lesson of the productivity paradox. The teams generating the most code aren't shipping the most value. The ones winning are the ones whose planning and verification kept pace with their build speed. Build got cheap. Knowing what to build, and proving it worked, got expensive.

#Closing the loop: did the deliverable move the number?

Which brings us to the step almost everyone skips, and the one that makes GOD a loop instead of a line. A deliverable hangs off an objective for a reason: so you can go back and check whether shipping it actually moved that objective.

This is the connection most roadmaps never make. Teams ship the deliverable, mark it done, and roll to the next one. The objective just sits there, unexamined. But "done" is the wrong finish line. A deliverable isn't finished when it ships, it's finished when you know whether it worked. Shipped and moved the number is a win. Shipped and the number didn't budge is information, and often more valuable than the win, because it tells you the bet was wrong before you pour three more deliverables into the same dead end.

So the objective does double duty. Up front it's the filter that decides what's worth building. After the fact it's the scoreboard that tells you whether what you built was worth it. Same number, two jobs. That is the D looping back to the O: build the deliverable, check the objective, decide what to do next. It's the engine of a roadmap that learns instead of just lengthens.

Concretely, every deliverable gets a before and an after:

• Before: which objective does this serve, and what's the number today?
• After: did the number move, and by enough to justify what we spent?

If you can't answer the "after," you didn't ship a priority, you shipped activity. The deliverable connects to the objective at both ends, or it doesn't really connect at all. This is the verification half of the bottleneck, and cheap building makes it matter more, not less. When shipping is slow, a useless deliverable at least announces itself slowly. When it's instant, motion is easy to mistake for progress.

#Setting priorities: the practical sequence

Here's how to set product priorities in a world where building is the easy part.

#The shift in one line

Building used to be the constraint, so we optimized building. Now planning and verification are the constraint, and most teams are still optimizing the wrong thing, pouring AI speed into producing more deliverables instead of into knowing which deliverable is worth producing and whether the last one worked. Goals and objectives are how you point cheap building somewhere worth going, and how you check it got there. Pick the deliverable that moves an objective, ship it, confirm the number moved, repeat. That loop is the whole job now.

---

#Footnotes

1. Sonar, 2026 State of Code Developer Survey, which found AI accounts for roughly 42% of committed code, with developers expecting that to reach about 65% by 2027. ↩

2. LinearB, 2026 Software Engineering Benchmarks Report, an analysis of 8.1 million pull requests across more than 4,800 organizations finding a 39-point gap between perceived speed (about 20% faster) and actual delivery (about 19% slower), driven by longer review times on AI-generated code. ↩

3. Sonar, 2026 State of Code Developer Survey, in which about 96% of developers said they do not fully trust AI-generated code to be functionally correct, and fewer than half always verify it before committing. ↩