On an aircraft carrier, the landing zone describes a small section of deck that a pilot must touch down in to land the plane safely. By analogy, a landing zone for a product describes a range of measurable attributes that your product must deliver to achieve the product vision.

Landing zones are useful for products as well as complex projects and programs. For such complex systems it can be difficult to define “good enough to ship” without considering a lot of different factors and making tradeoffs between them. Recently I have been introducing landing zones as one technique for getting a bigger picture on agile projects and programs. I also find landing zones helpful in identifying architecture and design risks and potential required innovations.

I first learned about landing zones from Erik Simmons. Erik is responsible for creating, implementing, and spreading requirements engineering practices at Intel. Long ago, he and his colleagues taught requirements classes at Oregon Graduate Institute. That’s where I met Erik and learned about landing zones. Since then I’ve helped several clients use them for managing complex programs and projects. They are particularly useful when many requirements needed to be considered and it is important not to lose sight of make or break requirements.

Online information about product or program landing zones is scarce (the only other references I found were a brief glossary definition in Tom Gilb’s Competitive Engineering: A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage.

At first glance a landing zone seems nothing more than a glorified table. Each row in the landing zone represents a measurable requirement. Each requirement has a range of acceptable values labeled Minimum, Target, and Outstanding. The goal is to have each requirement within this range at the end of development. Inside the range is the desired value, labeled Target. Minimum, Target, and Outstanding are relative to your budget and timeframe.

Here’s an example of a landing zone for a loan processing system (all the examples I am using are concocted for simplicity’s sake; any relation to landing zones for real projects is coincidental):

And another for a smart phone (this one was cooked up by comparing competitive benchmark data):

A landing zone is similar to release criteria, except it allows for tolerances in acceptable values. There isn’t one number you are aiming for; you have a range of values for each product attribute or characteristic you are targeting. This gives you some flexibility in defining what’s “good enough.” You’ll note on the smart phone that the minimum acceptable screen size is exactly the same as the target. This is not uncommon. It just means that there is no margin between your target and what is minimally acceptable. Sometimes the variance between minimum, target and outstanding can be small (this is when you know what your target is and how to achieve it, and are willing to accept only marginally less).

When you have little wiggle room in meeting requirements, you might simply want to define acceptance criteria with hard and fast numbers that simply must be met. I find it helpful to define landing zones for those product attributes that have some degree of flexibility in their outcome.

I like the way landing zones can help bring focus to a lot of complexity. If you are building something really big, you can roll up your product’s success to a few dozen things to monitor (instead of hundreds). In contrast to a list of release criteria, a landing zone also allows you to see a bigger picture and make sense of it: When one attribute is edging below its minimum, what is happening with the others? Are they trending below minimum, too? If so, you have a big problem with achieving your overall product goals. No, and you have a landing zone which allows you to achieve a successful product/system launch even if every requirement isn’t exactly on target.

Most important, landing zones allow you to make tradeoffs in multiple dimensions. The art is in understanding the tolerance for those attributes that define your landing zone, and then selecting reasonable values for minimum, target and outstanding. If you are defining a landing zone for a new system or product, it may require you to do some research, experimentation, and prototyping to determine appropriate attributes and their values. If you are replacing an existing system, you probably know what capabilities need to be improved (and your minimum values are likely at least as good as the current system you are replacing).

If you have competitors, you will most likely benchmark their products as part of investigating what you can reasonably expect to achieve. Simple criteria, if met, are checked; other cells have explicit values.

Yet what’s good enough? A good landing zone allows for some flexibility in meeting goals without forcing you to accept unreasonable compromises. If all your landing zone attributes fall in the minimum acceptable category, do you still have a viable product? By definition, yes, your product is minimally acceptable. But that doesn’t guarantee its success. It means you have “landed.” You didn’t miss the aircraft carrier, but you are perilously close to the edge. You’d like to be in the target zone for most of the attributes.

In my next post I’ll write about using landing zones on agile projects and how architects can and should be involved in defining, vetting, and recalibrating landing zones. If you’ve had experiences with landing zones I’d like to hear from you.