The who, what and why of working with an external product team

When we join a client for an engagement, our TPXimpact squad is only half the picture. We aim to integrate with people from our client's team — and potentially other third party suppliers — to take a multidisciplinary ‘one team’ approach. This is a key component of ensuring the success of the product across its life cycle, beyond our engagement, because it keeps knowledge within the organisation.

One way we ensure these mixed product engineering teams are successful is to be clear upfront with the roles and responsibilities we’re expecting to need from the client. Pragmatically, many of those we work with have multiple competing priorities, so we are flexible and economical with their time, but we need a level of commitment in order to ensure the success of the work.

In an earlier article, we set out the 'ceremonies' or meetings you can expect during an agile sprint. But let's look in a little more detail at the people involved in these processes.

Here are some of the roles we’re likely to describe when we start working with you.

Product owner

The most important role from the client side is what we describe as the product owner. They are the lead for the project facing the organisation; they're our day-to-day point of contact and will work within our team. This individual will be the person accountable for the success of the project or product.

Choosing the right person for this role is important. Many of our clients will provide a member of the digital, data and technology (DDaT) team or the IT team to offer project/delivery management support given that it is likely to be a ‘tech’ project.

However, it’s usually best when the product owner is positioned within the business or policy area where the change is happening. This is because we expect this person to steer us and make decisions on priority on a day to day basis. As such, they will need to have a solid understanding of the problem area and organisational strategy for it.

The product owner will attend all our meetings, from morning stand-up to the retrospective at the end of each sprint. We may also arrange one-to-ones with this person and our delivery manager, in part as a light-touch governance opportunity, and in part to provide additional coaching in the product owner role as needed. It’s common for product owners we work with to have little or no experience of working in an agile manner with a multidisciplinary digital team so we like to build in time to support the learning curve.

Having this person on our squad equips us to work at pace, by embedding the decision making and organisational knowledge within our team. It’s also an important component of keeping ownership on your side, for the benefit of future phases of work. It's really important that this person is sufficiently authoritative in the space we’re working in and enabled to be relatively autonomous.

The product owner works best when they are supported by their own ‘squad’ of helpers from the client side. These are likely to include:

Project sponsor

Who? This is a more senior role, responsible for giving direction and championing the work at an executive level. They are normally the person who has commissioned the work we’re engaged in. They might also be referred to as the Senior Responsible Owner (SRO).

What? We’ll escalate any major blockers to this person for their support in negotiating them. We’d expect them to attend Show and Tells as an influential voice.

Why? This person’s involvement enables our work to progress without getting stuck, as they have sufficient seniority to remove major blockers. They are also integral to getting the work and learnings embedded in the organisation’s thinking.

Subject matter expert

Who? The subject matter experts will be the people who really know their stuff in the domain we’re working in on the project; they may be knowledgeable in areas our product owner doesn’t specialise in.

What? Normally we’ll start with upfront interviews or workshops with these people to download the key information. We’ll want them to come along to Show and Tells and other sessions to provide insight and correct our course. If we’re working on an automation project with you, this person will walk us through the processes we’re looking to automate in detail.

Why? We are experts in product, data and technology, but we are not experts in the day-to-day processes of your organisation or the legislation that governs them; we need you to provide that expertise to inform our work. This is particularly important in spaces that have legal or procedural constraints we’re unlikely to know about, and for internal processes and systems that can’t be observed from the outside.

User base representative

Who? This person is someone who can connect us to your user base, either directly or indirectly. In the private sector, these people are often from the customer success team, whereas in a governmental Arm’s-Length Body it might be someone from a local authority engagement team.

What? One of the biggest challenges in many projects, and particularly in Discovery phase work, is recruiting users for research and participation. We’ll ask this person to introduce us directly to users they know, set up a workshop or potentially share a survey. Where possible, we’ll want to piggyback on existing meetings or forums.

Why? We want to get user research and testing set up quickly when we land with clients, and this is an essential route to doing so. It’s much more effective for us to start from a trusting relationship, rather than coming in cold.

Technology representative (Also known as technical advisor)

Who? This person will be our single point of contact within your information technology department. They’ll be able to advise us on the technologies you use, as well as your information security and governance requirements.

What? We’ll ask this person to set us up in your environment as necessary. We’ll expect them to connect us to others in the department to answer questions on particular technologies or requirements. If you have a change control process in place, we’re likely to ask them to be our in-house sponsor for changes we’re proposing.

Why? We believe that code, like knowledge, should sit with the client wherever possible, and working with your tech team means we can work in your environment. It also enables us to take your current set-up, both in terms of technology and resources, into consideration when we’re recommending future phases of work.

In the mix

Alongside these positions, we are happy to mix up other project roles – user researchers, designers, technical architects – between us and the client. While we have an idea of our ‘dream world’ for clients, we are a very pragmatic group of people who will work with whatever your team set-up is.

If you’d like to chat through who would be well placed to fill these roles — or how to upskill them — we’d love to talk.