Product and Agile are both industry “buzzwords” that have managed the impossible and become mainstays of the tech sector (and beyond). Ask anyone who has ever worked in an Agile environment and you can understand why the agile mentality has been a slow-burn revolution for software development.
Building on top of that success, the product role structure allows an Agile team to efficiently prioritise tasks and ensure that the project/product is shipped comfortably within the required timeframe, no matter how tight. The benefits are enormous, not just for the Product Team but for all involved stakeholders, providing better products, greater visibility and clearer customer expectations.
However, if you're looking in from the outside the whole ecosystem can feel bewildering, forming a jumbled mess of pseudo-English terms and phrases. It can be more than a little daunting to try and wrap your head around everything that’s going on! That’s certainly what we faced at Talent Point when product roles first started being requested, so we can understand where you’re coming from – in fact our L&D Manager, Daniel Wells, ended up creating a training regime just to help people get to grips with it all (which has now been used as the basis for this article, so thanks Dan!).
Perhaps you’re looking at transitioning into a company or role where these phrases are everyday parlance, exploring the potential of a Product hierarchy within your business, or maybe you’re just interested in getting to grips with the new normalcy. Whatever the reason, we’ve been there, we’ve had the headache and we’ve emerged on the other side able to help you untangle the terminology and help demystify the meanings behind product role titles.
But first, a quick disclaimer: part of why product roles are so hard to tie down is that, by their very nature, they are highly flexible. Best practice suggestions are a great starting point but, in reality, to fully understand a businesses’ product structure you must understand the environment within which they exist and the aims they are designed to achieve. As a result, no matter how much detail we include, there will always be situations or processes that work differently. Still, as the concepts mature specific patterns are becoming more prevalent and certain (fairly) universal truths are rising to the top.
So what exactly is the difference between a Product Owner and a Product Manager? Do you naturally fit better within the Product or Delivery team? And where on Earth does the Scrum Master fit into things?
The first step to understanding product structure is to see which roles naturally fit within it. Let’s look at the common job titles you can expect in a product function and break down their responsibilities. After all, if you don’t have a full overview you won’t be able to grasp the nuances.
Scrum Team (Developers, QA, UX, Design etc.)
Sitting on the front-line of product development, the Scrum Team are the people actually turning plans into reality. The exact team makeup is highly flexible and can consist of anyone – from developers, to QA analysts, to UX designers – to form the multidisciplinary skill set required.
Work is largely dictated by the product roadmap and current sprint goals, though members of the Scrum team will be expected to push back on problematic user stories or escalate blockers before they impact deadlines or quality of work.
Together, the Scrum Team forms a shared resource that can be accessed and utilised by anyone across the function. Each person in the team will be a specialist in a particular area of the tech-stack or product requirement, creating a smorgasbord of information, knowledge, experience and skills that can be tapped into.
As you might have guessed, the Scrum Master monitors the Scrum Team and makes sure they have the resources that they need. Scrum Masters facilitate sprints and Scrum sessions, as well as enacting Agile ceremonies such as Kanban boarding or stand-ups. They are also the escalation point for the Scrum Team, helping to clear blockers ASAP using a Servant Leader mindset.
They act as a buffer between the Scrum Team and the rest of the product function. The Scrum Master will liaise with the Product Owner and other stakeholders to prioritise the backlog and mediate any disputes or queries that arise, allowing the Scrum Team to focus on the day-to-day development of the product.
The Product Owner owns the product on behalf of the company (much clearer, right). In practice, that means they form the central point of contact between the customer and the build process, managing the relationship between the two so that the final product is fully understood by everyone involved throughout the development lifecycle.
They work with the customer to identify core needs and use these to create user stories, which are added to the Scrum Team’s backlog. They then liaise with the Scrum Master, determining how these will be prioritised and where they are added to the product roadmap.
Once features are returned from the Scrum Team, it is down to the Product Owner to review their work and ensure the customer’s expectations are being met, meaning that final accountability for the product’s success sits with them.
The Product Manager is involved in all major decisions, overseeing the whole product development lifecycle end-to-end, just from a more user or client focused perspective than a Product Owner. They must have a complete understanding of the product, the company goals and customer expectations, enabling them to spot potential conflicts early and implement initiatives at the highest level. That also means they are the final escalation point for all involved parties, including external stakeholders.
They define the initial setup and scale the function as required, making sure that the necessary skill sets and tools are available where needed. That continues even after delivery, with the Product Manager defining the future roadmap, ensuring a viable market demand exists and determining that the company will see sufficient return on their investment.
It’s worth pointing out that, particularly in smaller companies and start-ups, the Product Manager role is often subsumed into the Product Owner (or vice versa), but as a company scales the practicalities of managing development, delivery, return-on-investment and external stakeholder relationships requires greater segregation of tasks.
The Delivery Manager oversees multiple active product/project streams in tandem, working with the relevant Product Owners to ensure that development is on track to meet delivery deadlines. That means monitoring the product development and helping to steer a product’s direction, when necessary, to balance company and customer requirements and timeframes.
Critically, they are also responsible for ensuring that the delivery cycle is fully setup, debugged and generally fit for purpose. They work closely with stakeholders to fully understand their needs and manage their expectations in line with technical capabilities and realistic time constraints.
Head of Delivery
The Head of Delivery ensures that the overall product pipeline is delivered. They provide support to the Delivery Managers and can step-in if necessary to explain core concepts or mediate disputes, particularly between customers and product teams.
By working with key stakeholders they develop a deep understanding of the product roadmap, though don’t have ownership over prioritisation or sprint cycles.
Having that level of oversight enables the Head of Delivery to create marketing strategies alongside the Sales teams and generally ensure that the product has a clear roadmap once development is complete.
Programme Management Officer
Sitting outside the core Scrum, Product and Delivery teams, the Programme Management Officer provides a range of resources and support across the function, with a broad remit including advertising, sales and legal advice.
They act as a bridge between the core teams and the rest of the company, making sure that key skills gaps or queries are addressed by the relevant departments. They also work to source tools and resources that could benefit product development or increase team efficiency.
Crucially, they monitor the output of the various teams to ensure that all work complies with agreed internal product and company standards, and adheres to industry or national level policies, for example GDPR or data security.
Sitting outside the Scrum and Product Teams, the Agile Coach acts as both a watchful eye and confidant for anything Agile. They monitor the various teams to make sure that an Agile mentality is being practiced, working in a top-down manner (as opposed to the more bottom-up mentality of a Scrum Master), whilst generally raising awareness of Agile processes and the strengths/benefits that they provide.
As part of that, the Agile Coach runs workshops and sessions on Agile best practice and methodologies. They train new team members, ensuring that they understand the fundamentals of Agile and are fully versed in the ceremonies and practices being employed.
Whilst they have no direct hand in delivery, the Agile Coach provides the framework, attitude and knowledge needed to facilitate the team to uphold product standards and meet deadlines.
Now that we have an overview of the common roles found in a product team, let’s take a look at how they interlink. We’ve created a graphical overview to highlight the escalation channels and natural workflow that the product hierarchy creates.
So what’s going on here? We can think of the product role structure as a form of input/output machine that makes creating new iterations, features or products as efficient as possible.
At the top are the key external stakeholders (i.e. the customer). They provide the Product Manager and Head of Delivery with the core business objectives and expectations they want the product to solve. These are then reviewed by the Product Manager and Head of Delivery before being handed over to the Product Owner and Delivery Manager to convert into user stories and feature requests for the wider product backlog. From there, the Scrum Master helps to prioritise and add the new user stories to the scrum backlog, ready for development.
Once a feature is at this stage it’s up to the Scrum Master to incorporate it into a sprint, explain the requirements to the Scrum Team and monitor its progress. Once the Scrum Team has completed that part of the build, it gets bounced back up the product hierarchy, getting checked and refined at each stage until it reaches the Product Manager. Alongside the Product Owner, they will then present the final version of the feature back to the key stakeholders for sign-off.
Well, okay, the reality is a little more complex – we haven’t even mentioned the Agile Coach or PMO in that explanation! – but hopefully that provides an understandable outline for the standard workflow through a product role structure. The key part to keep in mind is that as you ascend up the chain, each stage has an increasingly holistic understanding of the product development, enabling conflicts or blockers to be spotted early whilst allowing everyone else to remain focused on achieving their immediate goals. That’s the power of an Agile product structure: it gives everyone clear goals, clear direction and a clear hierarchy.