Why Dedicated Product Teams Reduce Risk
Listen to the latest episode of The Agile Reformists podcast from MATRIX Agile Coach Todd Sussman below, or keep reading for a summary. Subscribe to The Agile Reformists podcast on Spotify to keep up with our episodes released every other Tuesday.
While there might be subtle differences between implementations, there are in essence two types of product approaches to building software. Yet, when it comes to results, the differences can be significant.
Project-based approach
The first and most common is to take a project-based approach. When an organization is project-focused, management sets the roadmap. It is almost always focused on a list of prioritized deliverables, and the associated quarter or year in which they will be completed.
Then, money and resources are made available to deliver on the expectation. Looking at the roadmap, leaders can see the intersection of all the different projects, each with their own allocation of developers, testers, and product management time.
The problem with a roadmap based on deliverables is you can’t go a week or two without some significant change. Maybe some new opportunity, or late breaking requirements, for an existing project. Management is forced to shuffle the schedule. Aligning people across several departments can be tricky to say the least. While most people do not enjoy the act of redrawing their roadmap, there are several other negative consequences at play here, too.
Developers and testers are moving from team to team, never getting to progress through the stages of team development. Product managers don’t get the opportunity to form working relationships with their IT counterparts.
If developers move from team to team or project to project, they are prevented from developing a deep expertise that makes them a value add. The alternative is to turn them into a commodity or resource.
Even with a cadence, teams will be no closer to predictability, since teams will be able to produce differently depending on the team makeup or the project and experience.
It is easy to produce “orphaned” projects. If the team or individuals are allocated to a different project when the current one ends, then follow-up work and optimizations are delayed, or worse -they just never happen. This, of course, leads to that feeling that “Phase two” never happens.
Product-based approach
With dedicated product teams, the debate is not which project should move forward and when, but rather which area of the business should be invested in, and how much time should be spent doing it.
Time is spent thinking about outcomes and the intended impact on the organization. As an example, a travel company might have identified areas of the business, such as:
Search and Results
Booking and Fulfillment Systems
Payments
To define the appropriate investment, start thinking about teams and their objectives. How many teams will support an area? Will a single team be required to support multiple areas? This in essence is creating the priorities for the teams to come.
With the understanding of priorities and what the teams will be asked to work against, make sure it is staffed with product managers, designers, developers, and testers. If other specialized roles are required, now is the time to address it.
What makes this so unique is that it doesn’t articulate project, features, or enhancements. That is left to the product team. They determine what they believe is going to deliver on the outcomes they’ve been assigned. This allows teams to be long running and persistent. Instead of focusing energy on constantly learning a new aspect of the business, they are building true expertise on their topic, and this in turn enables innovative solutions.
This is not to say that once they create these teams, that they are immutable. After all, they must be able to respond to change and there will be times when changing business priorities necessitate adjusting team balance or modifying their objectives.
People will want to grow and change areas of focus, and they should— just not every few months! When you create dedicated and persistent product teams, it is inevitable that team productivity will go up as they gain experience. Quality improves because of the relationships between people, not to mention the sense of ownership and expertise that is acquired.
By ensuring focus you get better work product, constant innovation, and rapid demonstrable improvements to the product.
If you’ve already started your Agile journey, then the idea of persistent and cross-functional teams is not new. In Scrum, the roles are easy to articulate -> scrum master, development team, and product owner. As a team, they are responsible for all the activities required to get their stories to completion.
Product teams tend to be larger and more encompassing and not so clear cut. Responsibilities include:
Identifying new opportunities
Defining what to build, and interfacing with the development teams
Marketing activities
Tracking progress against defined outcomes
In a small organization or business unit, this could be just one or two individuals. In larger, more complex environments, these might be dedicated roles like product analyst or marketing specialist.
These are critical activities when you think about the complete product experience, and you should design your team to support your goals for that experience. For your product team, think beyond the product manager. Do you need user experience research or simply UI design? What about someone responsible for market trends and user journeys, who will coordinate launch plans to coincide with the rhythm?
Setting up dedicated product teams does not come without risk, but embracing cross-functional and persistent teams follows best principles, requires minimal effort, and serves as an enormous risk reduction.