There are some decent day-to-day work tips in Sierra Newell’s 7 Project Management Principles Product Managers Can Learn From. There’s one principle I wanted to expand on, and that’s “Define the scope and stick to it”. First, from the post:

Product managers should set the scope of their products’ development as early in the process as possible. Learning how to say no to product requests is a valuable skill. But it is also a reactive method of keeping your product’s development on track. Instead, be proactive. Define your product’s scope from the beginning, and keep development within that scope.

I know that “define the scope and stick to it” is fairly common practice, but I don’t think it’s a good way to build product at all. First, that principle tends only to define one side of the spectrum — how not to add scope. It doesn’t, however, talk about the need to sometimes reduce scope. If you define a “fixed scope” and say you won’t go over it, but then things take longer than anticipated (as they are prone to do in software) and you have no mechanism to deal with it, you’re going to get yourself in trouble. Because at that point, you “committed” to a scope that won’t change, presumably saying “no” to a bunch of things, and still you’re “late” in delivery.

This is why I’m a firm proponent of “fixed time, flexible scope” projects. Under that principle, you don’t lock down the scope for forever and ever. You commit to an initial body of work, and an expected timeframe. Then, if something happens along the way — a developer gets pulled into an emergency, or something takes longer than expected — you have a mechanism to deal with it. Since you didn’t lock down the scope, you don’t have to choose between being “late” or the team working themselves to death. You can reduce the scope of your work to fit into the time you gave yourselves to do it in.

There’s another scenario under which I would go even further and advocate for “flexible time, flexible scope” projects. There are instances where increasing scope (and time) is the Right Thing To Do for a project. For instance, if the choice is between a hacky way of implementing a feature, and extending functionality properly with future-proofing in mind, which would add two weeks to a project, I believe it’s pretty much a no-brainer that you need to add the two weeks.

This is why I think fixing scope is a dangerous practice. There are too many unknowns, too many variables, and too many things can change along the way. We shouldn’t let our process get in the way of good product decisions.