Being an Agile Consultant, I get a unique insight into digital product development in many organisations, and how teams are structured during their agile journey. I was inspired to write this blog to distil why two specific teams, in their first agile attempt, were so successful compared to others I’ve worked with.
I discovered the secret ingredient: two product managers working within one team. In this blog, we’ll explore the attributes of a Product Manager subject matter expert (SME) and a Product Manager Expert. These concepts are useful for any organisation wanting success in their agile and product teams, especially those with teams in their early stages.
Your first agile team – have two product manager roles not one
Often when companies create their first agile teams, or during their first in-house software development, they’ll put together a team similar to the one below. A business subject matter expert is often promoted into a Product Manager role. However, this person being a business SME doesn’t necessarily make them an effective Product Manager.
The typical structure of a company’s first agile team:
- Developers / Testers
- Iteration Manager / Scrum Master
- UX Designer / Researcher
- Business Analyst
- Product Manager (someone previously a business SME who has been promoted to Product Manager)
Let’s explore this SME who has recently become a Product Manager.
Figure 1: Typical structure of a new agile team and attributes of a Product Manager SME
Attributes of this Product Manager SME
Let’s call this last person a Product Manager SME. Quite often they have been chosen as they’re a business subject matter expert. They have lots of customer, client and internal company connections; plus, they have their finger on the pulse of market trends. This knowledge is great, however, (there’s a big however), this person usually doesn’t know how modern software teams operate. To get there, they need to unlearn many of their old work habits and learn the new ways of working with a cross-functional team.
An agile team should have all the skill sets to complete the mission, but this is a lot harder if their Product Manager is missing key experience such as working with development teams, testing, UX, splitting of work, backlog prioritisation, power of influence and having an experimentation mindset. If these are new concepts for that person (and most people learn by making mistakes) then this can often lead to things going pear-shaped.
Things that could go wrong
A common practice for new Product Managers is to focus on constantly delivering new features, without concern for the technical evolution of the system or if these features are valuable to the customer. This approach can lead to slowing development as the team tries to integrate new features into every-extending spaghetti code, and a less robust system overall. This technical debt starts to cripple the team, and users and customers become more frustrated as existing functionality slows down. Users may vote with their feet and abandon the product. In turn, this will create additional business pressure on top of the already stretched Product Manager SME.
I remember arriving in one particular organisation where the Product Manager SME didn’t articulate a clear vision of what’s on the horizon. The multiple conflicting roadmaps were far from helpful for the team. They didn’t have a chance to sink their teeth into the next big problem, delivery was decreasing and so was morale; becoming an “us” vs “them” attitude very quickly. Speaking to the team, it was no longer an enjoyable place to work, triggering people to leave and creating a knowledge drain in the company. Left unchecked this situation can trigger loss of customers, contracts, financial losses and a downturn for the organisation. This is an extreme example; however, it does happen.
Product Manager Expert
Let’s introduce a Product Manager Expert: someone who’s worked with multiple delivery teams, UX, testing, knows how to split work, has a mindset of experimentation, and tells stories to engage and influence within an organisation to create alignment to the mission. Quite often this person is new to the company; it will take time for them to get up to speed, extract the right information from stakeholders, and build up knowledge of the sector including competitors.
If we return to the semi-trailer example, this person is skilled at reversing trucks, even in tight, complex loading docks. Imagine the days before Google Maps or GPS; if the area is new, navigating to the right street would be challenging. It might take a few tanks of fuel driving around different blocks, asking for directions, but eventually they’ll get there.
If we paired this person with a navigator who had great local knowledge the truck would get to the delivery dock more quickly. We could think of this concept as “product-pairing” in agile teams.
How Product-Pairing creates success for the team
Pair-programming of developers is common in modern software development; it helps one developer learn a new part of the code and create value. It increases quality while minimising rework from bug fixes found in testing and uses the best of both developer’s knowledge.
This was the key element of the agile teams I mentioned in the introduction being successful in their first attempt – not by pairing developers, but by pairing Product Managers; product-pairing.
For this structure to run smoothly, the Product Managers must have a mutual respect for each other’s knowledge and contributions to the team. It’s impossible for someone to be brilliant at everything, so knowing their weaknesses is key for any Product Manager, and an attribute of the ones who can make great teams – e.g. “I’m not the best at UX, let’s get an excellent UX person to join the team!”
Pairing a Product Manager SME and a Product Manager Expert on the same agile team delivers value to customers faster. Coaching the Product SME is the added benefit of this structure, which complements the 70:20:10 learning model; 70% on the job learning, 20% mentoring and 10% formal training courses to successfully upskill. After a few months and the right handover plan, development and training, both Product Managers can run their own teams. The Product Manager Expert might do product-pairing with another Product Manager SME and uplift another team.
Figure 2: A structure of an agile team when Product-Pairing and attributes of a Product
Note: Don’t get too hung up on job titles here, these differ between organisations and more or less roles might be needed depending on the product and team.
It won’t be completely frictionless; the best agile teams never are. There will be challenges along the way; however, the benefit of getting value to customers quickly outweighs the risk of working on a product that is ultimately not valuable to customers for months or years. Some challenges might arise, such as who to ask when there is a conflict in priority and when’s the right time for the Product Manager Expert to hand the reins over to the Product Manager SME? These are some of the healthy conversations that should be happening within a psychologically safe agile environment.
Conclusion
We’ve got to consider the skill set of the entire agile team to complete the mission, remembering that individuals are different. Especially when creating new teams or when team changes occur, including Product Managers.
Software development isn’t cheap. It’s expensive fielding a team; the costs are just hidden compared to creating physical products. Working on the wrong thing is even more expensive. Try experimenting with product-pairing in your teams to minimise this risk, especially in new agile teams.
Further Reading:
- Your Team is Smarter Than You Are: Why Autonomous Product Teams Work Better
- Techniques to Help you Build a High-Performing Team
- Engineering Wants to Rewrite!
