There’s not a Product Manager alive who hasn’t seen the traditional project management pyramids or triangles — it’s a very common trope of the business, focusing on Time, Scope, and Resources as the “pivot points” for hitting deadlines, or the common line of “Good, Fast, or Cheap — pick two.”

The simple fact is, in nearly every organization, there is no pyramid or triangle.  There is only Scope.

The Fallacy of the Project Triumvirate

The concept of the project management pyramid or triangle is a long-standing principle of project management, and structures the discussion around a negotiation of various factors that affect the ability of a team to hit a deadline or milestone.  Conceptually, it’s a very attractive model, and it plays well with management:

• If you fix scope, you have to be flexible on time or resources;
• If you fix resources, you have to be flexible on time or scope;
• If you fix time, you have to be flexible on resources or scope.

Or…

• If you want it fast and good, you can’t have it cheap.
• If you want it cheap and good, you can’t have it fast.
• If you want it fast and cheap, you can’t have it good.

If you’ve been a PM for as long as I have, you’ll see the problem here.  When was the last time the company or management was willing to be flexible on resources?  When was the last time you got a senior stakeholder to agree that the project wouldn’t be good when delivered on a tight timeframe with limited resources?  I’ll grant that occasionally I’ve found management teams willing to play with time a little bit — but rarely to any extent that actually permits the kind of flexibility your teams need to deliver something good, cheap, an in scope.  And when the answer to “resourcing” becomes “outsourcing” the conversation is dead before it’s even started.

The simple fact is, outside of the world of startups, the average management team isn’t willing or interested in discussing time or resources; they want everything good, fast, and cheap.  And they’re often unwilling to recognize this as an impossible stalemate.

The reality is…

• Nobody wants to spend more money; and
• Nobody wants to sacrifice quality; and
• Nobody wants to delay releases…

As a PM interested in getting shit done, that leaves us with one lever to pull — Scope.

The CLAW Chooses Who Will Go and Who Will Stay!

The best thing about Scope is that it’s the one thing that Product Management is both accountable for and has control over.  Rarely, if ever, do we have any amount of control over the development, testing, and ops resources that will do the work.  And it’s sometimes difficult to exert any strong level of control over the timeline of releases or projects, depending on how cooperative (and realistic) your management team is.  This makes it much easier for us to simply focus on managing scope so that we can deliver the best product we can under the restrictions imposed on us by external teams.

That’s not to say that we can be dictatorial in our decisions, nor that it’s necessarily easy to manage scope.  What it is, however, is something tangible and visible that we can use to demonstrate the impact of decisions that others are making.  When we’re very clear about what’s changing in the scope and why it’s changing, and most importantly about the impacts of those changes on the customer experience, that is how we influence change in the organization and in its goals.

The Scope is Dead!  Long Live the Scope!!

Traditionally, “scope” was something that was set, predictable, and managed through a variety of complex and archaic processes (the words “change management” still make me cringe to this day).  However, when I’m talking about “scope” in the context of this article — and indeed, in this entire blog — I’m talking about your backlog, the list of desired (or required) functionality that you have, at a point in time, deemed necessary to deliver a quality product to your customers.  This “scope” is not something set in stone; rather, it’s something that is somewhat fluid — though it shouldn’t be changing every day.  It’s something tangible, that others in your organization can look at, and to some degree rely on.  But it’s also something malleable, that shifts as new information is discovered and as more is known about the product, the project, the customer, the market, or even the organization itself.

The backlog should ultimately reflect the personality of the organization and of the Product Manager running it — and in and of itself, it can be a tool for cultural change.  If it’s changing too often, this can be made apparent and discussed; if it’s never changing, that too can be an indication of too much rigidity or a lack of curiosity in the organization as a whole.  The only time that the scope of a project or feature should never change from the outside is when it’s being actively worked on by a development team — there may be changes due to technology, implementation, or other development concerns, but once a team starts work, we need to let them push that piece of work over the finish line, and then we can revisit what they’ve accomplished.