A vision you can reach is not a vision

At my first cybersecurity product management role, you could have asked five people what our vision was and gotten five different answers.

What everyone knew was that we had a product for incident response. What that product was supposed to do for a customer was not clear to anyone, including the people building it.

The easy read is that vision statements are inspirational fodder. Fine as long as they sound good, mentioned once a quarter, otherwise ignored. Ours qualified. But that is a description rather than a diagnosis, and it points at the wrong fix, which is usually a better sentence.

This is not a communication problem. It is a structural one. When nobody shares an understanding of what the product is for, work goes in every direction at once, and every direction is defensible, because there is nothing to check a direction against.

So before arguing about what to build, I tried to get to something everyone would actually agree to. Which meant answering a question I had not had to answer before: what is a vision supposed to do?

The vision is the aspirational, unattainable target of a product. For incident response, it looked like this:

Eliminate the damage stemming from cybersecurity breaches for organizations with security teams.

Is it possible to eliminate the damage from every breach? Theoretically. In practice, no. That is the point. The vision aims past anything you can ship, so it keeps pointing after you have shipped. Organizations dealing with incidents are trying to minimize risk and damage, so the target sits where their interest already is.

Which raises the obvious objection. If you cannot reach it, why write it down?

Because it is the guiding beacon for why the product must keep evolving. Software products are never “done” for precisely this reason. The vision stays out of reach, and you never stop moving toward it.

Three ways to tell a vision from a slogan

A vision is falsifiable in one direction only. You cannot prove it right. You can prove it is not a vision.

If you could complete it, it was a milestone. “Launch in three new regions” is something you finish, cross off, and replace. A vision has no finish line, which is exactly what lets it survive a roadmap.

If it rules nothing out, it is a slogan. A vision earns its place by making some work obviously wrong. Ours put damage at the center rather than detection or prevention, which put the product after the breach began rather than in front of it. It said organizations with security teams, which meant we were not building for companies that did not have one. Both of those closed doors. That is the test worth running: name the thing your vision forbids. If you cannot name it, you have written encouragement.

If it would fit any company in your category, it belongs to the category and not to you. This is where ours was weakest. Most incident response vendors could have signed that sentence without flinching. The qualifier about security teams saved it, barely, because it committed us to a buyer with people to operate the product rather than one who needed it to run itself. Strip that clause and it becomes a category statement with our logo on it.

Two out of three is not a failure. It is the normal condition of a vision that has been used rather than framed. The point of the tests is not to score well. It is to find out which part of the sentence is doing work.

How you start reaching for something unreachable

Every product needs a starting point. The usual answer is MVP, minimum viable product. The trouble is that nobody can say what viable means without an argument.

You can land your first user and declare MVP. Until many users want the same product, I would argue you have not reached it. And users liking something is not the same as users paying for it.

Minimum sellable product is the analog I have heard for that gap. MSP says it does not count until someone pays.

Both are useful for deciding when to stop building and start selling. Neither one tells you what to build. They describe a threshold, not a direction. You can hit MVP with a product nobody needed, and hit MSP by selling it to a customer who will not renew.

What is missing sits between the vision and the backlog: a target near enough to reach and specific enough to argue about.

That is the mission.

If the vision is unattainable, the mission is the short term target you are trying to reach in the direction of it. Missions are a destination, not a milestone.

The navigational version is the one worth keeping. A heading is not a destination. You can sail toward a heading forever without arriving, and that is what a heading is for. A destination is somewhere you drop anchor, look around, and plot the next one, still on the same heading.

The vision is the heading. The mission is the next port. It is achievable, and it may not be the final form that realizes the vision. It is the nearest destination that makes a difference someone can feel.

For incident response, the mission looked like this:

A security team can take the most common class of incident from alert to closed without leaving the product.

Notice what that sentence does not contain. There is no number in it. The mission is a destination, and you know you have arrived because responders stop opening other tools to finish the job.

The unit belongs one layer down. The goal underneath that mission was to get the time it takes to respond to an incident from hours or days to minutes, and that is the outcome that made the destination reachable at all. Missions say where. Goals say how much. Keeping those two apart is what stops a mission from quietly turning into a metric, and it is where Part 3 picks up.

What makes a mission the right size

I try to define a mission as something a customer can feel within six months to a year of development, at the resources you actually have rather than the ones you asked for. That constraint is doing real work. It means the company commits to roughly one mission at a time, and it means the mission has to be small enough to finish and large enough to notice.

The measurement of a mission is not revenue. It is the customer outcome. Revenue is a sales target. Value realized by a customer is a product target, and those two come apart more often than anyone enjoys admitting.

Which is where Part 1’s category error turns up in its most common costume. A quarterly revenue number standing in for a mission is the company supplying a layer it does not own. The company sets the constraint the mission has to live inside: what can be funded, what has to be shown, and by when. It does not get to supply the mission itself, because a revenue number cannot tell anyone what to build. It only tells them what to hope for.

The objection I’d raise against my own argument

“Vision statements are corporate theater.” Mostly true, and I would not defend the majority of the ones I have read. But look at what makes them theater. A vision is theater exactly when nothing below it is derived from it. It becomes load bearing the moment a requirement can be traced up to it and a decision can be checked against it. A vision that nothing traces to has been correctly ignored, and the fix for that is not better wording.

“I did not start this product. I inherited it.” So did I, which is the entire story in Part 1. Writing a vision for a product already in market is not the same act as inventing one. The product already implies a vision, in the choices it has made and the customers it has kept. The work is to state it out loud, discover who disagrees, and settle it. That conversation is uncomfortable and short. It is considerably cheaper than another year of work going in every direction.

“The market moves, so a market-calibrated vision is a moving target.” Concede the premise and then check the frequency. A vision moving is fine and rare. A mission moving is fine and roughly annual. If your vision moves every quarter, it was never a vision. It was a mission wearing a vision’s job title.

What it changed

Writing the vision down did not make everyone agree. It made the disagreement visible, which was the part that had been missing. Two people who both said we do incident response turned out to mean noticeably different products, and that only surfaced once there was a specific sentence available to disagree with.

That is the return on these two layers, and it is smaller and more useful than alignment. You get a sentence precise enough that somebody can tell you it is wrong.

If I asked three people on your team to state your product’s vision, how many different answers would I get?

Part 3 goes down a layer, to goals and use cases: how an unreachable target turns into outcomes with units attached, and where the chain stops being negotiated and starts being derived.