The core roles every product team should have
Every product team is shaped differently, and almost never stays the same. The number of engineers often varies - in some cases wildly. Some teams have dedicated user researchers or business analysts or delivery managers, whereas others don’t. External “floaters” often exist - honorary team members who carve themselves up into fractions as they dip in and out of multiple teams as best they can.
But time and again, when given the luxury of a blank canvas, I’ve always used the shape described below as a starting point and tinkered as the ever-changing landscape and problem-space necessitated.
Core team shape
1️⃣ x Product manager 1️⃣ x Product designer 1️⃣ x Tech lead 4️⃣ x Engineer
1 x Product manager
A dedicated, full-time product manager is clearly the gold star here. I’ve had the dubious honour of product managing multiple products and teams at the same time and, believe me - this is not at all ideal, nor sustainable.
One alternative approach I have seen work, in the absence of a whole product manager - albeit less than ideal - is to supplement them with a strong, experienced business analyst who is comfortable leaning into typical product management activities.
1 x Product designer
I have worked in a handful of teams that have not had a permanent product designer of their own and have seen firsthand how this results in inferior outputs which ultimately impact desired outcomes. These have tended to be at less mature organisations, or where teams look after particularly technical products (such as APIs) or non-public facing products (such as B2B offerings, or internal products like inventory management systems).
Designers split over multiple teams is a common problem, as is designers being cut from teams once they have “finished discovery”.
1 x Tech lead
A tech lead is essential to set the technical direction of your product and provides guidance and leadership to the engineers.
Naturally, a more senior / competent / confident engineer will usually step up to provide cover in the absence of a tech lead, but this can be a source of conflict if there are multiple people vying to fill the gap, or if nobody fancies the extra responsibility that comes with it.
4 x Engineer
When I drafted this post, I initially had the number six here. Whilst I would continue to recommend six engineers for a more experienced, established team, I’ve erred on the side of caution for now and suggested a smaller number of four to get things off the ground. I’ve found that having too much to do is a better problem than having too little, and it's healthier to upscale than downscale.
I’ve worked in teams that have had different specialisms of engineers - dev ops engineer, back-end engineer, front-end engineer, UI engineer, data engineer. Generally, the more rounded and “full-stack” your engineers are the better, as this increases agility whilst minimising handovers and coordination effort.
Supporting roles
There are many other roles that can add lots of value, and in some cases prove vital to the delivery of a product or some of its constituent parts. The most common are listed below, along with a brief summary of when they could be a wise inclusion and how they can contribute towards the team’s aims:
- Automation engineer
- Business analyst
- Content designer
- Data analyst
- Data engineer
- Delivery manager
- QA engineer
- Service designer
- User researcher
- Technical architect
Automation engineer
Most teams I have known have shared out the automation work (e.g. all things infrastructure, CI/CD, internal developer tooling) amongst the “generalist” engineers. That said, there are two scenarios where I would advocate having a dedicated automation engineer.
First, where automation is expected to be a big focus for some time. This could be a blue sky “project” that requires apps to be created from scratch, or an existing product where there is a big push to move to a new platform, or to vastly improve CI/CD.
Second, where there is a lack of automation knowledge or appetite across the rest of the team.
I’ve learned a lot from automation engineers over the years, and have found them to be eager educators, keen to sprinkle their specialised knowledge throughout the team and beyond. Also, they don’t need to focus exclusively on automation - I’ve regularly seen automation engineers getting stuck into other, more general work items.
Business analyst
As well as the scenario described earlier where a product owner is simply not available to the team full-time, there are two other scenarios where a BA will often add value.
First, where complexity is rife - multiple systems, third parties, legislation, geopolitical angles. BAs are made for the big and the messy and the unknown.
Second, where the product manager is inexperienced or is stretched for some other reason. I’ve often found that BAs will naturally pick up the slack to help product managers focus on the things that would benefit most from their attention.
One to be aware of though - they can do more harm than good. They are often process people, which can ultimately damage both morale and momentum.
Content designer
All products and services should be scrutinised through a content design lens. More often than not, this function is performed by the product designer, sometimes with support from a central pot of content design expertise that serves several teams.
Where a product is very content rich, or where content has never been properly thought through, a case can be made for having a dedicated content designer.
A bonus of having one embedded within the team is that they not only relieve some of the burden on the product designer by owning the content, they are often more than competent UX/UI designers and may be able to provide support in that regard.
Data analyst
Some data analysis will always be required in order to glean insights and measure progress towards your objectives.
Where there is little expertise or capacity within your team to dissect and visualise data, or where the data landscape is unknown or convoluted, a dedicated data analyst may prove a wise investment.
Also, entering a team or starting on a new product where metrics have yet to be made centrally accessible or, worse still, have yet to be defined, the input of a data analyst - if only on a part-time basis - is encouraged.
Data engineer
Much like automation engineers, data engineers are like any other engineers but just happen to specialise in a given area.
A common pattern is to have a data team responsible for mobilising an organisation’s product data, that may itself have a product manager, a tech lead, and four data engineers.
But there are other scenarios where one or more data engineers may be warranted in a more traditional product engineering team.
An example might be where there is no dedicated data team, and each individual product team is responsible for ensuring that the data that their product produces is fed into a central data lake and exposed in a meaningful, useful manner. Where the other engineers in the team might not have the skills to enable this, a data engineer likely will have.
Delivery manager
The more constraints a team is under, the stronger the case for a delivery manager. They are master unblockers - something which, in their absence, usually falls to the product manager and in some situations the tech lead.
Where there are hard deadlines, lots of dependencies - particularly challenging ones such as third party suppliers who have proved unreliable in the past - or perceived problems with morale, productivity or comms, a delivery manager may be a shrewd choice.
As with business analysts, there is a risk that they may too be process people and focus solely on delivering something (anything, in fact), giving too much credence to up front planning, roadmaps, and all the bureaucracy and baggage that comes with this, much to the detriment of the team’s true objectives.
QA engineer
Earlier in my career I would have insisted on one dedicated quality assurance engineer to every four engineers.
Then I worked with teams where the engineers were empowered - truly empowered - to own the quality of what they delivered, which included contributing to the definition of acceptance criteria, creating, maintaining and optimising automated test suites and all of the tooling that goes with them, and of course ensuring that the acceptance criteria were met in everything that they delivered.
This does require a level of maturity and buy-in, as well as the skills and mindset to create and execute an automated testing strategy.
Where some or all of this is not present in your team, or where you are starting completely from scratch or are overhauling an automated testing suite, it may make sense to include a dedicated QA engineer in your team.
Service designer
This is another role that is often considered a luxury with its responsibilities commonly shared out amongst other roles - usually the product designer, product manager, and business analyst.
The best process illustrators I’ve met have been service designers. Whilst BAs might be that little more detail oriented, great service designers have a knack of making the invisible not just visible, but accessible, alluring and, above all else, usable.
A dedicated service designer may be a good option if there is a lack of understanding of the product or service within the team or the wider org, particularly if there is a lot of complexity behind the scenes with many different people or systems involved.
One bonus of having service design expertise in your team is that they can document and design an entire service - they aren’t just limited to the realms of software.
User researcher
Ideally your product designer would lead any user research activities with support from the product manager and sometimes others in the team.
Dedicated user researchers can prove beneficial where teams are exploring a whole new proposition, where the product designer is not experienced or comfortable driving research, or where there is a real logistical challenge organising and coordinating user research.
I’ve only ever seen positive outcomes from adding a dedicated user researcher into a team.
Technical architect
Only rarely have I seen a technical architect embedded within a team, and this has always been during the early phases of building large products from the ground up.
What can set them apart from their peers in other engineering roles is the ability to quickly absorb multi-dimensional complexities - much like a BA usually can - and to quickly translate that into a candidate architecture. To have an appreciation of the full breadth of technology, and to also be able to visualise and articulate it to both technical and non-technical people in their preferred language and via their preferred medium. Some tech leads and engineers can do this, but by no means all of them.
Where a technical architect is embedded within a team this tends to be short-lived, with the architect moving on once the bulk of the architecture that underpins the new product is in place.
In summary 📋
Of course, there is no one-size-fits-all, and certainly no right or wrong answer here.
Much like the thinking we apply to our product engineering work day-to-day, the key here is to constantly assess, take on board the thoughts and feelings of team members on a regular basis, and don’t be shy about tweaking the team make-up as the landscape shifts and a different mix of skills is required.
