The Messy Product Management Triangle: Scope, Resources, and Time

Agreeing on what to deliver and by when can be challenging. Revisiting the classic product management concept with a fresh take & real-life examples.

👋 Hey, it’s András here! I write about all things product management: concepts, frameworks, career guidance, and hot takes to help you build better products. Subscribe for each article to be delivered when it’s out!

---

Do more people equates to less time? Or, as the classic saying goes: can nine women deliver a baby in just one month? The second example perfectly illustrates the messy product management triangle: scope (1 baby), resources (9 women), and time (1 month).

Is it possible to add more developers to a specific problem to improve time-to-market? What about out-scoping some nice-to-have items from the functionality? Or should the organization accept a month of delay?

These factors usually come up in product delivery discussions, especially if someone from management wants to speed up the development of a particular feature.

So what can the team do to make it happen?

There is no perfect formula to figure this out, and the answer usually comes with a compromise. Nobody will be thrilled; everyone will feel they’ve given up something.

But while the scope-resources-time triangle looks pretty straightforward at first (“three words cannot be that difficult, right?”), every aspect of it needs a different approach.

The messy product management triangle: scope, resources, and time.

Scope

The scope of a functionality covers the number and quality of features, the level of technical excellence (built as a robust solution vs. hacked together), and overall the amount of work put into it.

It’s easy to suggest out-scoping items if there is time pressure, but the question is: would the feature still be as valuable—or very close to that—as customers expect them when they’re paying for it?

Just imagine paying for Netflix or Spotify and think about what percentage of the content the services could safely remove before you start to question the price.

It’s similar to when customers figure out whether it’s worth paying for your product.

Alternatively, the team can consider cutting from the quality of the features: what if the new service only offers 5 fonts to start with instead of 15? Or just 10 basic drawing shapes instead of 20?

While these are easy compromises in theory, we rarely face similar decisions in real life.

Out-scoping functionalities from a future product can still be a reasonable way to ensure timelines are met, or the company can deliver something ahead of competitors.

The key question people should be asking is: does the feature still make a difference? Is it addressing the core part of the problem it is supposed to address? Or is that a stripped-down version of the original idea that just checks all the boxes for a “delivered feature”?

If a too big compromise is made to the scope, it can affect the expected business results, thus making it harder to justify additional investments into the solution later. And then we can think about: was the original hypothesis so wrong that it failed, or does it have to do with the number of trade-offs?

Resources

Resources in this triangle are often attributed to the headcount (people), but that’s just the biggest portion of it. It’s also the infrastructure, the tooling, the office renting costs, and maybe some free food or drinks.

Scaling up from 10 to 5000 customers requires not only more people but also a bigger paycheck to our technology provider: more servers, bigger data needs, and potentially a faster way to deploy product changes.

When developments are time-pressured with a given scope and timeframe, people’s first idea is often to throw resources into the problem. But new people don’t grow on trees, especially not people who would already know our technology and business.

For example, reallocating one or two developers to achieve something faster can make sense if those engineers don’t require a significant onboarding effort, know the technology and business context, and if the task is manageably-sized.

In every other case—especially if a person is hired from outside the company—it takes time to onboard. Learn the business context, the technology frameworks, how the products work, and all the abbreviations.

In many white-collar roles, half a year is easily considered good to reach peak productivity levels, so “throwing resources” to the problem should be mostly a long-term approach. And welcoming someone new to the team also requires existing members to invest time in training and guidance.

So adjusting resources in the scope-resources-time triangle is the most challenging aspect of the three, as even exceptionally skilled people are not plug-and-play lightbulbs.

Time

The above-mentioned triangle works in a way that two factors are usually defined, and the last one comes as a result of an equation:

• Set resources and scope? Then the team will come up with a delivery estimate.

• Agreed resources and time? Then the scope will be shaped accordingly.

With most empowered product teams, the resources are the least flexible aspect, usually dedicated by the management. And teams can balance the scope and timing.

Oh, if we’d have just one more month… but do we?

In case of delays, the deadline is the easiest factor to push further. If the team miscalculated something, how much of a problem is to do the release a few weeks later?

And the answer usually depends on earlier commitments and market factors.

Have there been any internal or external commitments made about the functionality? External ones are the hardest to change. For example, if some date or tight time range was communicated to customers earlier, they’d have those expectations. Not meeting those can cause reputational damage or churned customers at worst. Especially if broken promises are a repeating pattern.

Failed internal expectations can also be damaging but to a more limited degree. If there are no external commitments and the market is not pushing us to strict timeframes, only personal reputations are at stake. Even if a timeline was promised to the upper management, if there are no real stakes involved, pushing deadlines further only requires admitting a miscalculation.

Of course, if competitors are trying to beat us to market, that’s a different thing. Launching something brand new first can be a game-changer. Launching the same thing a few months after a competitor still has value, but reasonably less.

And challenging timeframes can also be a management tool.

If used correctly, it can dare dreams to consider alternatives, think about value-adds, and shape the product scope sensibly. No product is ever truly finished, and setting boundaries can help teams to think about delivering incremental value.

Making decisions based on the triangle

The scope-resources-time triangle is a simple framework that hides many intricate details with its obviousness. When making product delivery decisions, keep in mind that:

• Resources are the hardest to change; if it’s not a small or a long-term challenge, looking at other aspects might work better.

• Adjusting the deadline is relatively easy, but doing that too often erodes the organization’s trust. Time can also be a good tool to avoid scope creep.

• Scope cuts make sense, but only if the new product/feature’s core value proposition remains unchanged. Removing half of the features rarely results in the same experience.

Think from a customer’s perspective: if you were on the receiving end of a new solution, would you be happy with the compromise that was made?

And no, nine women cannot deliver a baby in one month.