Skip to main content

3 Kings of product development

When it comes to building a product. These 3 things are King; People, Time and Scope. You can never change one without impacting another.

  • cost (people/resource)
  • time (fast / slow)
  • scope (quality)

How it works

  • If you want it in less time you’ll have to increase the people or reduce the scope

  • If you want a larger scope you’ll have to increase the time or increase the people

  • If you want to reduce the people you’ll need to reduce to scope or increase the time

The last option to reduce the people is probably not a good call if your organisation is made up of small cross-functional teams or worse, multi-disciplinary teams. The impact can creep out of your product and into the wider organisation.
Teamwork
An actual example

Money can't always buy you success

Jayesh, our product owner, wanted to add an additional feature (increase the scope) into the sprint late in the sprint itself. His team were already at capacity and we’ll assume they were doing everything as smartly as possible already. So Jayesh could do any of the following:
  • Bring another designer and developer into work on the additional feature (increase the cost)
  • Pull another feature in flight to make time to work on the new one (reduce the scope)
  • Accept it will run over (increase the time)
  • Do nothing

If we assume bringing in another resource is going to be hard or too time-consuming then you’re left with 3 options.

Pulling a feature means re-prioritizing which is fine as this came late in the development cycle and we assumed Jayesh is doing a good job at leading the product.

He could let it run over, that may or may not be acceptable.

He could do nothing, and continue as is, which would in effect be the same as delivering it late.

Special Offer

Conclusion

Sometimes throwing more money, more resource just doesn't fix the problem. Most teams today avoid getting too big because they understand that it becomes too difficult to organise large groups.

It leaves you with changing the scope and increasing the time.

Working within an Agile methodology usually gives you wiggle room to change the length or scope of a project as you go. What I tend to see if the scope is continually reduced until it truly can't be reduced anymore and then and only then is the length of the delivery extended. 

This feels waterfall to me, because the goal is measured in a binary way (Did you build it?) not how well it achieved the business outcome. If you were using better measurements of success I don't think reducing the scope of the project would be the first go to action.

Teamwork