Product Goals vs. Use Cases: What's the Difference?

We were stuck between reporting and integrations, and both sides were right.

Integrations were what actually drove the value. Each one took a system the responder would otherwise have opened in another tab and pulled it inside the product, which cut the swivel chair effort out of the response. Reporting did nothing for the responder. It made the product’s output legible to the person one level up, the one who had to account for the quarter to somebody else.

The argument had no natural end. Both were real, both had customers behind them, and the case for each was made in adjectives.

Then we put the goal on the table. Reduce the time it takes to respond to an incident from hours or days down to minutes. Measured against that, it is not close. Integrations move time to respond. Reporting does not touch it.

We shipped reporting first.

That looks like the number losing the argument. What it did was let us say why. Reporting had never been competing with integrations for the same job. A deal we needed depended on it, and it was never going to make anybody respond faster. Its job was to make the product something a security organization could buy.

Without the unit, that is two people arguing about which feature matters more, and it gets settled by whoever is more senior or was most recently in a customer meeting. With it, the disagreement resolves into something you can state in a sentence: one of these produces the outcome, the other one makes the outcome reachable, and they are graded on different scales.

Part 2 said the return on writing a vision down is that somebody can finally tell you it is wrong. This is the same return one layer lower. A number precise enough to show you that you were having two arguments at once.

Goals are where this becomes falsifiable

A goal is a measurable value a user realizes from the product. Measurable is not a nice to have. It is the entire point, because a goal you cannot measure cannot be called done, which means it cannot be traced to, which means the layers below it are floating.

This does not mean you must know the target number up front. You often can’t. A goal needs a unit of measurement, not a committed value.

The goal in that argument is the one Part 2 ended on:

Reduce the time it takes to respond to an incident from hours or days down to minutes.

The unit is time to respond. That is what makes it a goal rather than an aspiration. Everything below it inherits that unit, which is what turns an argument about features into a question with an answer: does this use case move time to respond, and by roughly how much?

We happened to know the order of magnitude here, because the gap between days and minutes was the entire reason the category existed. That is not always true, and you should not invent a number to make a goal look rigorous. A goal with a unit and no target is still a goal. A goal with a target and no unit is a slogan.

It also does the work in the other direction. Once time to respond is the measure, a feature that does not touch it has to justify itself some other way, and any use case that shortens it has a claim on the roadmap that does not depend on who requested it.

Layers above goals are stated in prose. Goals are the first layer with a unit attached. This is why the chain is not a nicer-looking org poster: it bottoms out in something you can check.

Not every use case pays

Use cases are where PMs most often flatten something that isn’t flat.

Value-driving use cases are the meat. They produce the outcome the user came for, and they trace directly to a goal.

In incident response, ours were the scenarios where an analyst pulled everything relevant into one place instead of chasing it across systems, ran the collection steps without assembling them by hand, and had the work recorded as it happened rather than reconstructed afterward. Each one took legwork out of the response, and legwork was what the hours were made of.

Note what those are not. Centralizing data, orchestrating collection, and capturing work are capabilities. They are features, and they sit a layer lower. The use case is the analyst in the middle of an incident, and the feature is what the product has to do for that scenario to work. I mix these up as readily as anyone, which is a decent argument for writing the layers down instead of holding them in your head.

Supporting use cases don’t add direct value. They exist because something has to be true before the value-driving ones can happen at all.

The clean version is single sign on. Being compatible with SSO delivers no value to a user in any direct sense. No one has ever renewed because authentication worked. But for a company with security requirements, it is the difference between a product they can adopt and one they cannot.

Reporting was the harder version, and the more common one. It was not valueless. It delivered something real to an actual person, the manager who had to account for the team’s work to somebody above them. But that person is not the one the goal measures. Time to respond is measured on the responder. So reporting produced real value on a scale the goal does not read. That is the condition that makes these arguments circular when the layers have not been written down. Both sides are pointing at value, and they are reading it off different instruments.

Keeping the two labeled is what stops two bad arguments. The first is treating a supporting use case as if it should show ROI, which gets security and compliance work perpetually deprioritized until it becomes an emergency. The second is treating a supporting use case as a value driver, which is how a product ends up with a beautiful admin console and nothing worth administering.

The most abused sentence in product management

I just told you we shipped reporting because a deal needed it, which is the most abused sentence in this job. Every feature request I have ever received arrived attached to a deal, and “the customer will walk” can be made to justify anything at all. So calling something a supporting use case cannot be a free pass, or the label does the work the argument was supposed to do.

A supporting use case earns its place when what the deal needed is true of the segment your vision already names, and not merely true of that account.

Ours named organizations with security teams. An organization with a security team has somebody who runs it, and that person has to account for what the team did. That is a property of every account in the segment we had committed to serving rather than one buyer’s quirk, which is why the request kept arriving and why it was going to keep arriving.

The tell is what you end up building. When the need belongs to the segment, you build the general version. When it belongs to one account, you build that account’s version and nobody touches it again. We built a reporting engine so customers could construct their own, instead of a queue of templates we would have been extending forever. That was the bet that the need generalized, and unlike the adjectives, it was a bet somebody could check.

The second check is cheaper. A supporting use case has to name the value-driving use case it unblocks. Reporting unblocked all of them, by making the product purchasable by the organizations we had said we were for. If a request cannot name what it unblocks, it is not supporting anything. It is just urgent.

Where the two sources meet

Goals come from the company. Use cases come from the customers. This is the one place in the chain where two different constituencies supply adjacent layers, and it is therefore the seam where products tear.

Look again at what the reporting argument was. Both sides were carrying a real customer request. Integrations came from the analyst who spent the incident moving between tools. Reporting came from the person who signed the contract. Those two people worked at the same company, and neither one had any particular reason to care about the other’s problem. The goal that both requests got measured against came from us.

Nobody in that arrangement is positioned to reconcile it except the product manager. The analyst can’t see the deal. The buyer won’t feel the swivel chair. Engineering can build either one and is entitled to be told which. Doing that reconciliation is the job, and the chain is what makes it a derivation rather than a negotiation about who complained most recently.

Worth stating plainly: if your goals and your use cases were written by the same person in the same meeting with neither constituency in the room, you do not have a chain. You have two layers of fiction stacked on each other.

Objections worth considering

“Not everything worth building is measurable.” True of the vision and mostly false of goals. In my experience, “we can’t measure it” is usually a compressed way of saying “I have not decided what I mean by it,” and that decision is the work being avoided. There is a residue I will concede. Trust, taste, and the sense that a product hangs together are real and they resist units. But they are rarely the thing under debate when a roadmap stalls. What stalls a roadmap is two measurable things that nobody bothered to measure. There are cases where you may not get the data to measure a metric because it exists in another part of the organization that’s not allowing you to have the data, but that’s a different case than saying “it’s not measurable.”

“Measurable goals produce metric gaming.” Real, well documented, and the chain does not prevent it. What the chain does is make it visible. A use case that moves the number without serving the scenario has nothing above it to point at, and the gap surfaces the moment somebody asks which use case it belongs to. Gaming thrives where the number is the only artifact. It has a harder time where the number is the third layer of seven and has to answer to the two above it.

“Supporting use cases are how you justify anything you want.” Fair, and I gave the guardrail above because I have watched this one go wrong. Name what it unblocks. Check whether the need belongs to the segment or to the account. Two questions, both answerable inside a single meeting, and between them they eliminate most of it.

Integrations never end

That was the part of the argument with no bottom. Every new engagement brought its own set of systems, so we went into each one already behind. There is no way to get ahead of a list that does not terminate.

Which is where the goal stopped being a referee and started generating work of its own. If time to respond is the unit, and integrations are what move it, and integrations cannot be finished, then the thing that moves time to respond most is whatever makes integrations cheap, rather than any integration in particular. So we started building an engine to let customers construct their own.

That decision doesn’t live on this layer. Engines, and the requirements that specify them, sit below use cases.

What did you ship last quarter that your goal’s unit does not touch, and can you say out loud why?

Part 4 goes below the boundary: features, requirements, acceptance criteria, and what it takes to trace a requirement all the way to the code that implements it.