What Landing Actually Is

I have been writing that landing, not building, is the new constraint. A few people wrote back with a fair question: what do you actually mean by landing? I have been using the word like everyone already agrees on it, and they do not. So here is the working definition, and the four ways it fails.

The short version

Shipping is the code reaching production. Launching is the announcement reaching the market. Landing is the thing that matters and the thing nobody owns: a customer's behavior durably changes and the value sticks. You control shipping and launching completely. Landing happens on the other side of the glass, in a person's real workflow, which is why it is hard and why cheap building did not touch it. There are four ways landing fails, and each one looks like success on launch day: the demo that never becomes a habit, the onboarding that activates once and goes silent by month two, the launch with no owner past GA, and the feature that gets used but moves no number. The test for whether something landed is simple and unforgiving. Point at a behavior a customer used to do differently, that they now do with your product, and would be annoyed to lose. If you cannot, you shipped and you launched. You did not land.

Three words people use as if they were one

Shipping, launching, and landing get treated as the same event with three names. They are three different events, and only one of them is the point.

Shipping is an engineering fact. The code is in production, the feature flag is on, the thing exists and works. This is fully inside your control, and it used to be the hard part. It is not the hard part anymore.

Launching is a marketing fact. The announcement went out, the blog post is live, the sales team has the talk track, the market knows the thing exists. Also inside your control. Also increasingly cheap and increasingly automated.

Landing is a customer fact, and it is the only one that lives outside your building. Landing is when a person who used to do something one way now does it with your product, gets real value from the switch, and keeps doing it after the novelty wears off. You cannot ship your way to it and you cannot announce your way to it, because it happens in someone else's workflow, on their time, against their existing habits.

That last sentence is the whole reason landing is hard. Everything up to launch is a thing you do. Landing is a thing a customer does, and you can only make it more or less likely. Cheap building and automated launching made the first two nearly free and left the third exactly as hard as it always was. That is why the constraint moved.

The test

Here is the test I use, and it is deliberately strict.

Can you point at a specific behavior a customer used to do a different way, that they now do with your product, and that they would be annoyed to lose?

Not signups. People sign up for things they never use. Not week-one activation. People try things once. Not a great demo. Demos are performances. Durable behavior change with realized value, or it did not land.

The strictness is the point. Most of the metrics we celebrate at launch measure the two events we control, shipping and launching, and go quiet on the one we do not. A launch dashboard lighting up green tells you the announcement worked. It tells you nothing about whether anyone changed what they do on a Tuesday when no one is watching.

The four failure modes

Landing fails in four recognizable ways. I have shipped versions of all four. Each one is invisible on launch day and obvious a quarter later.

1. The demo that never becomes a habit

The feature is adopted in the room and forgotten by Monday. People nod in the meeting, click it once, and never return, because it was impressive to see and never became part of how they actually work. This is the most common failure and the most flattering, because the demo really did land. The habit never did. Adoption that peaks in week one and decays is not adoption. It is a very good trailer for a movie no one finished.

2. The onboarding that activates but does not retain

The customer gets through setup, hits the activation event you instrumented, and goes silent by month two. You measured the moment they first got value and assumed value would keep arriving. It did not, because the second and third weeks had no on-ramp, or the value required a habit you never helped them build. This is the prototype graveyard at the account level: a thing that worked once, for one session, and then quietly stopped.

3. The launch with no owner past GA

The product ships, marketing runs the launch, and then everyone moves to the next launch. There is no one whose job is to drive the thing from "available" to "adopted" over the following two quarters. It falls into the gap between product, marketing, sales, and success, and things in that gap do not land, because landing takes sustained attention from a named owner and there is no name on it. I wrote the whole argument for this one in who owns landing: the short version is that it is nobody's job, and that is the problem.

4. The feature that lands in usage but not in economics

People use it, and no number that matters moves. Engagement is real, the behavior even changed, and it did not translate into retention, expansion, or margin. Sometimes this means you landed the wrong behavior. Sometimes it means the value is real to the user but not captured by the business, which is a pricing failure wearing an adoption costume. Either way, usage without an economic result is a feature that landed on the customer and missed the company.

Why the definition is load-bearing

This is not a vocabulary exercise. The reason the definition matters is that you build the org around the words you use. If your org treats shipping and launching as the finish line, you will staff, measure, and reward everything up to launch day and nothing after it. You will have four teams pointed at the moment of release and no team pointed at the ninety days that decide whether release mattered.

When building was the constraint, that was a defensible design. Getting the thing built and announced was most of the work. Now that building is cheap and launching is cheap, an org optimized for shipping and launching is optimized for the two easy parts and blind to the hard one. Twelve builders can ship twelve products, and if the definition of done is "launched," you will have twelve launches and, if you are unlucky, zero landings.

Fix the definition first. Landing is durable behavior change with realized value. Everything before it is a means to it, not a substitute for it.

Try this week

Take the last thing your team launched. Not shipped, launched, so it has had a little time. Apply the test: point at one behavior a real customer used to do differently and now does with your product, and would be annoyed to lose.

If you can, name it out loud in your next review, because that is the actual win and it usually goes uncelebrated while the launch metrics get the applause. If you cannot, you have found a thing that shipped and launched and did not land, and you have found it early enough to do something about it. Then ask the harder question, the one the landing ledger is built to answer: what would it have cost to land it, and did anyone budget for that at all?