Choosing a suitable project management tool

Simply put, there are too many to choose from. At the end of the day there is no right or wrong answer.

One of the most talked about areas of digital project or product management is the tools that are available. Simply put, there are too many to choose from. At the end of the day there is no right or wrong answer. The biggest piece of advice I can share is to ensure that everyone is happy (or near enough) with the chosen tool. This will increase your best chance of adoption amongst the team and hence a tool that will add value to your process rather than being another ‘thing’ for the sake of it.

There are a whole raft of decisions to consider when choosing the right tool to use. This article focuses on what I consider to be the most important of these factors. They are: 

  • Functionality / ease of use
  • Project / product size
  • Team size, split and expertise
  • Integrations

The biggest piece of advice I can share is to ensure that everyone is happy (or near enough) with the chosen tool.

Functionality / ease of use

The most basic requirement to consider is obviously functionality – will the tool do what you need it to? For example, structure your requirements into Epics, Features and Stories? The chances are you can manipulate most of the available tools to work in such a manner. However, keep it simple. Don’t even bother attempting to bend the rules of the tools available – it will come back to bite you at some point. 

There are three different levels of complexity here. Simple, a little more advanced and then the ‘Oh my gosh, this is scary’ level.


The simple tools are easy to use. They can be adapted to work across many scenarios (product management, resource management etc) and in my opinion will allow you to tick off 95% of the smaller projects / products without wasting any time or overcomplicating things.

A couple of examples of these are Trello and They give you control of the structure (to an extent) and most importantly don’t bamboozle people with their complexity. 

They offer a functional option to list tasks, assign tasks, discuss tasks, group tasks, track tasks etc… To be completely open, some of the most effective products I’ve worked on (and chunkiest!) have been managed through Trello.

If simplicity is what you and your team value – don’t be afraid to dive in with one of these tools. Managed well and adopted by the team, this can often be the best way forward, especially if this way of working is new to you all.

Trello - a simple pm tool
Trello. Easy to use with kanban style layout, great mobile experience.

A little more advanced

Sometimes we all need a little more functionality and customisation. There may be a need to create relationships between tasks, estimate time required or perhaps integrate with another service (although simpler tools can do this too!). Whatever the next level requirement is, sometimes you can’t avoid having to step into something a little more advanced.

The likes of Clubhouse and Basic Azure Boards bring in a little more complexity and detail. The chances are, if it’s full product lifecycle management you are after then this is where you’ll end up. The reason being that the ‘Simpler’ options are often targeted at one specific fixed time span project, rather than a living, ongoing product or project. For example, you can bring in ongoing testing and bug reporting at this level. This could then be integrated with other tools to report on issues experienced and feed into ongoing Service Level Agreements.

I’m a firm believer in the fact that 95% of digital products and projects can be managed using this level of tool without ever needing to venture into the behemoths of the space!

Clubhouse screenshot
Clubhouse. Clean UI with more complex functionality than others.

Oh my gosh, this is scary

For the 5% of products / projects that need them, there are bigger and more complex tools available. The two main players in this situation are Jira and utilising the full setup of Azure Devops.

I’m by no means saying that you shouldn’t use these. I am suggesting that you only use these tools if you’re really going to benefit from everything they offer. These tools start being suitable when you have to consider one product to handle ALL things related to the product life cycle. For example, detailed estimation, service desk support and performance reporting. 

These tools have their place and when setup correctly can be very effective. Just remember at this level you really should be considering the following points to ensure the ways of working are clear for everyone and things are interpreted the same way. These tools aren’t as intuitive as the simpler options.

  1. Tool expertise is required
  2. Full team training / onboarding

The larger scale tools are usually only suitable for long-term product management. Is the product still going to be alive in 6 – 12 months time? Do we really need to understand time estimates and burn rate per Task? 

Yes they have their benefits, but ask yourself if you will actually benefit from the investment required for these. 

Jira screenshot
Jira. Busy UI with a lot of complex functionality and capabilities.

Project / product size

It probably sounds like an obvious thing to say, but don’t be afraid to scale your choice of tool depending on the complexity of the actual project / product you are managing. No doubt you have an internal process that you need to follow, but that’s not to say you can’t make everyone’s life simpler but just using Trello for a small build and jumping up to Jira for a bigger project. 

This is something we do at Pixel Fridge. Whilst I wouldn’t advise having more than 2 tools for teams to use (it will get confusing / annoying quickly), we do see the value in having a simpler tool and a more complicated tool available. When a small budget project comes through, it might be more efficient (and pleasing) to keep things simple.

License fees are obviously a consideration – but make the most of the free trials and smaller team setups that the majority of tools provide.

Team size, split and expertise

The next thing to consider is what tool will best suit your team size. Remember, real life face-to-face (with social distancing, obviously) collaboration isn’t something to forget! If you’re a small team, why not make the most of being able to talk about things, share knowledge etc. Yes, it’s good to document the core requirements for visibility, but small can be very effective. Hence, you may choose a simple tool to give you an overview and then rely on communication to discuss and agree the details. Have growth in mind, but don’t be afraid to keep things simple. It’s often overlooked in our world.

If you’re a bigger team then yes, you’ll be glad of the more complex tools to ensure there is no loss of knowledge. It will provide the whole team one source of the information that the team has to be following.

My guidance for those medium size teams (5+ people) would be to lean towards the ‘a little more advanced’ tools and strip back what’s not needed. You could opt to keep it simple and build in integrations / workflows but you’ll probably soon find that things get confusing! Keeping it all in one platform, but not using 100% of the features from the tool is the way to go.

Have growth in mind, but don’t be afraid to keep things simple.


Finally, it is always worth thinking about how you might benefit from the integrations that these tools offer. Whether you’re looking at this from a development point of view, or a PM point of view there are always options that make life easier in some shape or form. 

Will the tool integrate with your code repository? Will the tool integrate with you communication platform? Will the tool integrate with your design tools?

Consider your existing toolset and internal processes. If there is a tool that can save you having to manually share design files with people, why not try it?

Integrations aren’t the top priority when considering which tool to run with, but trust me they can save a lot of time and energy. This is especially true for teams that favour remote working.

Consider your existing toolset and internal processes.

To summarise

Whatever your scenario and your setup is, all of the available tools will provide you with some sort of starting point. My advice; pick one that everyone will use and run with it. 

Share this post

Related Posts