Intent Over Output

Most teams celebrate the wrong moment. The big emotional spike is almost always the same: we shipped. The feature is live, the launch email went out, the toggle flipped from off to on. There's relief in the room. The thing we committed to exists, the date didn't slip, the demo works.

Listen to the questions leadership asks in that moment and they give the game away. Did we hit the date? Did we stay in scope? Is it consistent with the design system? How many tickets did we close? Those are output questions. They have almost nothing to do with whether the original problem is gone. Every one of them can be answered yes while the user's day is exactly as bad as it was before.

The user doesn't care that you hit your Q3 objective. They care about one thing: did the job stop stealing their evenings or not? If the answer is no, it doesn't matter how clean the rollout was. You shipped something. You didn't solve anything.

This is the difference between output and intent, and most organizations measure the first while assuming the second. Output is what you delivered: the feature, the redesign, the new validation rules, on time and in scope. Intent is whether the user's situation actually changed. The gap between them is where products quietly fail, because you can run a flawless delivery machine and still aim it at the wrong thing.

"Intent" is one of those words people spray into decks because it sounds serious, and if you don't pin it down it just becomes another way to say "priority." So let me be precise. Intent, in a product sense, is painfully specific. It's a description of a job a real person is trying to get done, in a real situation, with constraints, and a definition of done that would actually change their day.

Here's what real intent sounds like. "Right now I'm trying to finish next month's budget before my boss meeting. It's late, I'm already behind, and the software keeps making me re-enter the same numbers in three places. I exported to a spreadsheet because at least it behaves predictably. I can't skip the approvals because finance will reject it, and I can't get this wrong because I'll be blamed for it. Better means I can finish in under thirty minutes without feeling like I'm gambling. Whatever you build can't create surprises for finance or add steps for my team."

That paragraph carries everything you need: situation, stakes, constraints, outcome, guardrails. Strip any of it out and you no longer have intent. You have a half-remembered complaint. The job of a product organization is to carry that level of clarity forward intact, from the moment someone first says "this is killing me" all the way through intake, planning, design, engineering, release, and iteration. Tickets and sprints are just packaging around that core.

The output version of the story goes: we built Budgeting 2.0, redesigned the interface, added new validation, shipped in Q2 as planned. The measures are clean. Did we deliver what we said? Yes. Did we hit the date? Yes. Did we stay in scope? Yes. And none of those answers tell you whether the accountant still dumps everything into Excel every month because she trusts it more than your tool. They can't, because they were never pointed at her.

This is why "we shipped" is such a dangerous thing to celebrate. It rewards the moment of delivery, which is the moment you know the least about whether the work mattered. The team is exhausted, the launch went out, everyone wants the win, and the temptation is to declare victory and move to the next thing before reality has had a chance to vote.

A simple test will tell you whether your organization measures intent or output: when was the last time you killed a shipped feature because it didn't solve the original problem? If the honest answer is "never," you aren't measuring intent. You're measuring output, and you're accumulating features that exist without changing anything, while telling yourself the roadmap is progress.

The discipline is to treat shipping as a question you're asking reality, not the end of the story. You put a small change in front of the user and you watch. Did the workaround behavior disappear, or just move? Did the time actually drop? Did they adopt it, or quietly keep using the spreadsheet? Until you've watched the job move, the feature isn't done. It's shipped, which is a different and much weaker thing.

This is the heart of my book, Intent: How to Build Products That Last in the AI Era.