Yesterday we summarized “The Blob” In 10 Screencaps Or Less™. Today, we extract a product management lesson from that classic 1950’s sci-fi flick.

According to its theme song, The Blob is a gelatinous creature that “creeps and leaps and glides and slides across the floor, right through the door and all around the wall”. It consumes everything in its path, growing ever larger and more dangerous.

Product manager and project managers routinely encounter features creeping up on them in a Blob-like fashion . . . attaching themselves to the work at hand, often with the best of intentions, and inadvertently endangering or even killing the product or project.

The good news is: these creeping features generally don’t want to dissolve anyone’s flesh and then devour you. The bad news is: if you’re not vigilant, these creeping features can sink your product, and blasting them with CO2 won’t do anything except make people cold and wet.

People sometimes use “product managers” and “project managers” interchangeably. While the two are related, they are not interchangeable and their approach to feature creep is very different. Before we get into the creeps, let’s define the roles of product managers and project managers.

Product Managers: Responsible for the ongoing success of a product.

Project Managers: Responsible for the successful delivery of a one-time effort; once that project is complete, the project manager generally moves to a new project which may be related to a different product in the organization.

There are other differences and responsibilities, but for the purpose of this conversation we’ll leave it at that. Check out Product Management Vs. Project Management by Jeff Lash for more detailed definitions.

How does a project manager defeat feature creep? What role does the product manager play?

The project manager is responsible for the successful delivery of a one-time effort–this means, getting it done, and done well, within various constraints (time, budget, etc.). Here are three tips on how to prevent feature creep from interfering with that goal:

• Allow the appropriate amount of time to research and nail down requirements. This sounds straight-forward but is often over-looked in the rush to Get Things Done And Show Results. Before anyone starts coding anything, make sure that you understand the purpose of the project and have a clear vision of what success will look like.
• Set the ground rules. Before a project has been defined and the spec has been locked down, set up rules governing feature changes. When a change is suggested or requested, hear the person out but be prepared to be the Bad Guy who has to say, “no”. If you are willing to greenlight the change–or are not in a position to reject the idea (for example, it’s the CEO’s direct request)–make sure everyone understands the repercussions of approving this out-of-scope feature (missing milestones, incurring additional costs, etc.).
• Be a hard-ass without being a jackass. Rejecting good ideas to stay on schedule can be tough. But it’s your job to make sure the project is completed on time, on budget, to the agreed-upon quality levels. Sometimes this means you’ll have to play devil’s advocate, and ask tough questions. This can strain relationships and alternatively bruise or swell egos. Remember to be respectful at all times, to hear people out, and to explain your decisions. Your meta goal is to be the most popular project manager in the room. That doesn’t mean saying “yes” to every request that comes your way; that means creating a stable, friendly working environment for your project and completing the project successfully.

For project managers, feature creep sneaks in after a project’s scope and requirements have been finalized. For product managers, feature creep takes a different, gelatinous form.

While the project manager strives to keep the scope of a given project manageable without taking on too many comely but dangerous hitchhikers, the product manager fights feature creep at the overall product level, determining the right feature set for the entire product not just an individual project.

The temptation for product managers working on a product feature set is to simply focus on what their competition is doing and just do that better and/or do more of it–which leads to a Blob-like feature set that may, or may not, meet the needs of your target market.

We saw a rash of this kind of thinking with free email services not so long ago: Company A would offer 125MB of storage; then Company B would offer 250MB of storage; then Company C would offer 1G of storage; and so on. As soon as one company implemented news feeds, everyone decided news feeds were required. As soon as someone else decided larger attachments were “It”, everyone else followed with larger attachments +1.

As a product manager, part of your job is to determine the right features to be released at the right time. Sometimes, this means setting aside your assumptions about the consumers of your product and re-educating yourself about their needs and desires.

Think of it this way: Suppose the target market for your email product didn’t give a toss about how many MBs or GBs anyone offers. How successful could you be if you could determine what they really did care about and then met that need before, and better, than anyone else?

If your feature list is just a compilation of features from your competitors, you’re doing something wrong. That is to say, you’re not doing your job as a product manager–you’re just feeding The Blob.

Your job as a product manager is to understand customer needs and create products that meet those needs. By asking the right questions and doing the research that your job demands, you’ll uncover the needs that need to be met and then determine the features that will meet them. And avoid being drop-shipped to Antarctica along with your failed product.

What do you think, gentle readers? Should feature creep be accepted as a fact of life or should it be warded off? How do you determine and prioritize product features?