Scope creep — the phenomenon of an ever-expanding surface area that your product needs to cover — happens when you don’t convey a vision, and don’t collect requirements correctly.

My variation on “the customer is always right” is a — in my view — more accurate “the product should always be right for your customer, but the customer never knows what this means”.

If you don’t collect requirements correctly, you will end up with a product that is not right for the customer, and this will lead to scope creep (if you don’t want to lose the customer you will have to implement the delta between what the product ended up doing and what the customer wants it to do). The customer won’t know that — a common beginner’s error is in assuming that the customer knows what they are talking about when they tell you what they want — so it’s your responsibility to make the need tangible and coherent. Poor business analysts simply listen to what the customer says and write down what they hear. Good BAs understand the requirements (which often means truly understanding the needs, and with them, the habits, behind the product). Great BAs drive the requirements, providing to the customer something he or she never knew he or she needed.

“But it’s hard to do,” you’ll probably remark. Of course it’s hard to do, and this is why good BAs are hard to come by! Don’t confine yourself to conventional methods of doing requirements analysis — i.e. talking to the customer and writing down notes. Mock something up for, or — even better — with your customer, come up prepared with theories for what the customer might actually need, or start with the anti-requirements.

Much more important — especially for a product past its infancy — is the vision you set for the product. It defines the universe of needs that the product will address, and, consequently, the universe of features the product will contain. The vision is what allows your product to be unique and remembered; the vision creates the brand. It also makes the product easier to develop for the majority of its lifecycle — you know which customers to talk to, you know what skills you’ll require your engineers and marketers to have, your product is easier to implement because all features have something in common.

The vision for all products is fluid — it has to respond to the Zeitgeist, new information, other products — and the features in your product will change based on that vision. However, vision brings about a certain inertia — it gets harder to add features if the vision changes — and this is why all products die. So just get used to it: don’t be afraid to kill products, knowing that you can bring new ones to life.

To part with, an anecdote. Imagine (in a weird future-in-the-past universe) that a group of Dutch settlers came to you and said “we want you to encode a map for our new city”. You ask, “what will the streets look like?”. “Oh, it’s a very simple system; we’ll pretty much have a grid, streets going east to west, and avenues going north to south”. “Trivial!,” you exclaim and encode every intersection as a set of two coordinates (x, y). For example, an intersection of 23rd Street and 5th Avenue would be encoded as (23, 5).

A little later you realize that there are avenues which aren’t numbered and fall in between numbered avenues. You scratch your head — your elegant system doesn’t quite capture this — but you realize that you can just map these names to non-integral coordinates. For example, (42, 3.5) would be the intersection of 42nd Street and a street that falls between the Third and Fourth avenues (which the settlers decided to call, oh I don’t know, say, Lexington Avenue). You also need non-positive coordinates because there are avenues to the West of First Avenue (which the settlers called Avenues A, B, C, …)

Then you realize that there is a special avenue that is diagonal, i.e. it intersects other avenues! Your elegant system certain does not capture all those intersections, so you implement a special set of coordinates (x, D) where x is the street that avenue intersects, and (D, y), where y is the avenue, knowing that that diagonal avenue — which the settlers called Broadway — can be represented as a piecewise curve of four straight lines, and with some clever mathematics you can still compute distances, and so on.

Then a large park is built in the center of the city, which removes some intersections but adds another irregular street. You’re visibly frustrated now, but with an additional mapping of which intersections don’t actually exist, and with an additional “special” road that connects two ends of the block taken up by the park, your system still supports the use cases. Of course, it’s pretty complicated now and it’s getting difficult to add features to it.

Finally the settlers tell you that actually, south of the 1st Street, there is a completely irregular grid of streets that are named, not numbered. That’s when you quit.

If only you had gathered requirements well in the first place…