51: Assemble the right product team
I’m writing about one hundred things I’ve learned as a product manager.
The UK Government now has many digital teams based on the blueprint established by the Government Digital Service (GDS). I’ve worked in Ministry of Justice (MOJ) Digital, and in turn closely with GDS as a service assessor for the MOJ.
These government digital teams have a way to ensure their digital services and products are created in the right way. In this post I’ll share with you how they do this and explain how you can make it work at your organisation.
The ideal product team #
According to GDS, the ideal team needs to be multidisciplinary, autonomous, and to keep the key roles separate. The make-up of the team and the way it works is vital for ensuring digital services and products are created in the right way. In fact, it’s so important that the GDS assessors will always check that the team is working in this way, and will not allow a digital service to progress if it’s not: it’s point 6 of their Service Standard.
6. Have a multidisciplinary team
Put in place a multidisciplinary team that can create and operate the service in a sustainable way.GOV.UK Service Manual – Service Standard
Being multidisciplinary means that the team is made up of the right people with the right skills, when they’re needed; autonomy means that the product manager and team are empowered to take decisions about their product and to work in the way the team needs to as they create it; and separation of roles means that the same person is not performing multiple roles on the team, for example being both product manager (roughly equivalent to a service manager in GDS terms) and user researcher.
This last point challenges the common (mal)practice of lumping together several roles onto the product manager. By definition, product management is a generalist role. Sure, we often talk about product managers being T- and Π-shaped people (those having a general understanding of many skills, but deep experience in one or two areas).
However, a product manager who happens to be conversant in a few different skills is not generally going to be the best choice to do all these different tasks on a daily basis. There’s already far too much product management she needs to do without becoming the bottleneck on (for example) contextual research, wireframing or data analysis. Just because she can do all these things doesn’t she should be doing all these things! Instead, it’s far better to have specialists on the team who are devoted to their particular area of expertise.
Which roles should be on the team? #
In practice, this means a team needs some or all of the following roles, in no particular order:
- product management (broadly equivalent with service management in GDS terms)
- delivery management (team coach and agile mentor, regardless of methodology used)
- user research (looking outside the organisation)
- business analysis (assessing processes and systems within the organisation)
- data science
- service design
- interaction design
- content design (short and long-form copy)
- front-end, back-end and full-stack development (all including testing)
- web ops
- security and ethical hacking
and other roles as needed.
With the exceptions of product and delivery managers, not all the roles will be needed on every product, or indeed at all times, so it’s usual for the teams to grow and shrink as required over time. As a rule of thumb, a team is ideally between 6-10 people at its largest whilst in full-on build mode.
It’s also worth noting for context that many of the products MOJ Digital was creating were new, rather than being iterations on an existing product. So that tended to skew the team make-up towards discovery and validation, simply because they were usually starting from scratch without any prior knowledge. If you’re working on an iteration of an existing product, you may need different sets of people at different times.
“Wow. Did you have an infinite budget?” #
Now almost every time I describe MOJ Digital’s rather luxurious-sounding team setup to others I tend to be met with accusations of impracticality.
Don’t misunderstand me, this is not the cheapest way to assemble a product team. However, I’ve observed first-hand at MOJ Digital both how well it can work and how products can flounder when the team is missing key roles. In the long run I’d argue that, although their burn rate (daily operating cost) was higher, working in this way dramatically enhanced the quality of their products.
The other benefit of assembling the right team is that it dramatically shortens the time needed to create a solid product that truly meets user needs. Because MOJ Digital had the benefit of people with all these skills when needed throughout the process, they could build the right thing (more or less) first time.
They could take an idea from drawing board through discovery and validation, through build and release, to a live digital service in around nine months on average – much more quickly than I’ve seen at other organisations with similarly-sized or larger teams. And even that includes the drag factors of the inevitable legacy systems in place and the bureaucracy still inherent in the UK’s Civil Service.
In other words, with the right team in place, you can move so much more quickly than if a handful of people are running around with their heads on fire because they’re each expected to fulfil multiple roles.
Grinding gears #
Mind you, working in this way is not without its challenges. Often the sticking point we had at MOJ Digital was not about whether we had the right people on the team, but whether senior management would trust us to work truly autonomously.
The UK’s Ministry of Justice is about 70,000 people strong. Like any large organisation, it has many layers of senior management and more than its fair share of arcane process and bureaucracy. In simple terms, the MOJ is perhaps better described as a group structure of three large agencies responsible for prisons, courts and legal aid, along with headquarters in London, which covers HR, IT, communication and so on. Each agency has its own senior management structure and objectives. In contrast with the wider MOJ, the MOJ Digital team is about 150 people attached to headquarters.
The difference between MOJ Digital’s faster-moving way of working and the more ponderous approach taken by the rest of the MOJ often felt to me like grinding gears. MOJ Digital is continually trying to influence not just the HQ senior management team, but also management in the other agencies in the MOJ. In a command-and-control organisation firmly rooted in complex, document-heavy project management processes, the very idea of small, responsive teams that can take decisions for themselves is pretty much heresy. Without the ongoing trust of senior management, autonomy feels to senior managers like an absence of control, and this can be a fearful thing for them indeed.
The MOJ Digital team exhausted a fair amount of their energy simply defending their need to work autonomously. However, every successful digital service they created earned them a little more trust and established their track record. As more and more people from the wider organisation had a chance to work closely with them and see the benefits of working in empowered, autonomous teams, they gained more acceptance. MOJ Digital has made a fair amount of progress in the three years it’s existed (at the time of writing), but there’s still a long way to go to convince the whole organisation.
Great in theory. But in practice…? #
If you’re working in a startup with a single product, you probably don’t have the luxury of having people dedicated to each role. After all, if they’re employees, you have to pay them whether they’re needed at that point in the project or not. If you have a good idea of when you’re going to need people, you could always bring in freelancers at the time, but that puts you at the whim of people’s availability, plus you don’t often have 20:20 foresight to be able to plan precisely.
People aren’t always interchangeable #
But it doesn’t necessarily work seamlessly at the other end of the scale, either. Typically MOJ Digital would have several teams working at any given time, each on different digital services. With this setup you might think that it would be easier to smooth out the peaks and troughs of demand for particular roles: you generally don’t need a full bevy of developers during discovery, for example. This would seem to suggest that supply and demand for roles could be managed by staggering the timing of delivery and moving people between projects.
In practice, not so much. Because we’re dealing with people, not faceless resources, not every person in a particular role is interchangeable with other. Some people are simply better suited to particular tasks than others: for example, not every developer knows every possible programming language, and so on. Then there’s the point that some people work better with others, some don’t, and no amount of banging heads together (metaphorically, of course) will resolve a conflict of personalities.
To keep the team together, or not? #
There’s a whole argument about whether it’s better to keep a team together. The main reasons in favour of this are that they accrue domain knowledge over time and work more effective as they settle in with each other. In general I’d agree with that sentiment, and for many organisations creating and gradually improving a single product with a dedicated team, this approach can work extremely well.
However, MOJ Digital’s situation was slightly exceptional. Because of its bias in the early years towards creating new digital services (as opposed to maintaining existing ones), a team would finish and move on to create a different one, so keeping a team together was of lesser (though not zero) benefit. Every new digital service essentially reset the team’s knowledge back to the start, where the problem and potential solutions had to be discovered from scratch. An approach that may have worked great in one service wouldn’t necessarily translate across to another. In fact, we challenged any lazy thinking of applying one problem’s solution to an entirely unrelated (albeit superficially similar) problem.
Summing up #
Having an autonomous team made up of specialists with the right skills is, without doubt, an extremely effective way to build digital products and services. However, without the right environment of trust and empowerment from the organisation’s management team, the team simply won’t be effective.
Transforming an organisation’s way of working is something that needs to happen from both the top down with management, and from the bottom up at the team level. Depending on the size of the organisation, this can take several years, but you can accelerate this if you have the management team fully behind you.
But hey – nobody said this product management thing was going to be easy :-)
And if you’re looking to hire a product manager for your organisation and you’re under the mistaken impression that she will also be your researcher, designer and copywriter, stop right there. Assemble the right team for the job. If you don’t know what that looks like, start with the product manager and let her guide you to bring in the right people as needed.
Get articles when they’re published
My articles get published irregularly (erratically, some might say). Never miss an article again by getting them delivered direct to your inbox as soon as they go live.
Read more from Jock
The Practitioner's Guide To Product Management
by Jock Busuttil
“This is a great book for Product Managers or those considering a career in Product Management.”— Lyndsay Denton
0 Comments on “51: Assemble the right product team”