Læs dette blogindlæg på dansk
We admit it. The headline is a little controversial. You might actually be working in a real product team, but the chances are not great. That’s because a lot of people confuse product teams with project teams and feature teams.
Confused? Read the rest of this blog post and learn what a product team is (and isn’t), and why it can make a big difference in your company when it comes to delivering valuable, relevant and competitive products in the market.
Is your team given a roadmap with prioritized features or a project plan they have to follow? Then your team isn’t a product team.
Nope. Product teams, project teams and feature teams have different goals and methods, and that’s why they need different structures and working conditions in order to function optimally.
Is your team given a roadmap with prioritized features or a project plan they have to follow? Then your team isn’t a product team. A product team is given business problems that have to be solved.
Is your team a success when it has delivered all user stories in a sprint? Is your team a success when they deliver a project within a certain time frame and budget? Then your team isn’t a product team.
A product team has ownership of the product and works proactively towards its success. They are responsible for driving innovation and upholding the relevance and quality of the product over time.
Is your team assembled for the purpose and dissolved when the purpose has been fulfilled? Then your team isn’t a product team. A product team consists of interdisciplinary members (developers, designers, marketing people, etc.) with different competences, who work together closely to continuously develop and improve the product.
Does your team have a hard time finding the time to be innovative and explorative in their approach in solving a problem? Then your team isn’t a product team. A product team is focused on creating solutions that are loved by the customers, while fulfilling the needs of the business, while feature teams are more focused on delivering specific functions or projects.
This makes the product teams more innovative and better at delivering valuable solutions.
A product team has a specific focus on developing, maintaining and improving a certain product or line of products. A well-functioning product team is therefore characterized by preferring to have a single, but often several products, that the team is responsible for from vision to design, development and maintenance.
A product team has a specific focus on developing, maintaining and improving a certain product or line of products.
An autonomous product team will often have ‘profit and loss’-responsibility when it comes to the product, which means that they can make decisions about what needs to be developed to increase value and thus maximize the outcome of the product.
Contrary to project teams, product teams will often be static for a longer period.
In an environment where you work with project teams, colleagues are often “borrowed” and moved to the assignment for parts of the project period. In an environment where you work with product teams, the team members competences are elevated in accordance with the product’s needs, so the team can solve it themselves.
If competences are drawn into a product team through other colleagues, to solve a task, it will often be with the purpose to train members of the product team to be able to handle similar tasks in the future. In some cases, the task is moved into another team, where they have those competences – especially, if it is competences rarely needed in the team.
This leads to a product team consisting of several types of developers – here collectively dubbed product developers – that has the necessary competences needed to deliver the product.
The term “developer” is, in this context, generic and does not necessarily refer to software developer. In a software team, there will often be a requirement of, for instance, software development skills, UX competences, test competences, etc. In other contexts, you might need people with competences relating to physical product development or the like.
Everything goes completely wrong if, for example, a Scrum Team is part of a larger framework—like a SAFe setup—where financing, requirements gathering, and prioritization occur far away from the team.
To make sure that they deliver value, a product team will establish feedback loops, where they communicate with relevant users and stakeholders, so that they can adapt to market needs along the way.
Isn’t that just a “Scrum Team” or a “Kanban Team”?
Well, yes and no. If a Scrum or Kanban Team can identify with the abovementioned product focus and authority to make decisions, then yes. Scrum and Kanban are frameworks, that state some guidelines for how we work together in the team and create flow.
However, we often see that Scrum or Kanban teams turn into feature factories that deliver elements defined to them by others.
Everything goes completely wrong if, for example, a Scrum Team a part of a larger framework – like a SAFe setup – where financing, requirements gathering, and prioritization occur far away from the team. Thereby removing both ownership and flexibility from the team, and therefore, in our opinion, cannot be identified as a product team.
Product teams do not work in all organizations. It demands leadership with a lot of courage, and too often product teams are wrapped up in governance and unnecessary structure.
In the end, it is vital that organizations put a stop to incomprehensible and politically motivated leadership decisions that limit the product team’s purpose and ability to take action. Give your team the freedom to perform the valuable work that they were hired to do!
Now, we would like you to reflect for a moment – if you haven’t already while reading this blog post. What obstacles are there that prevent you from establishing product teams in your organization?
We see a lot of teams that would like to take responsibility, and more often than not, we see that they are not granted that wish. Through mistaken considerations and misunderstood needs of control, it is often not possible for teams to act as product teams in their own right.
What can you do within your mandate to change that?
Do you dare unleashing the product teams, so that they can really feel how their solutions affect the customers? They need the chance to fall in love with the customers’ problems, so they can get creative with how to find good solutions.
We see a lot of teams that would like to take responsibility, and more often than not, we see that they are not granted that wish. Through mistaken considerations and misunderstood needs of control, it is often not possible for teams to act as product teams in their own right.
First and foremost – identify your products. There are many definitions of products – we believe in this one: “A product is something created through a process, and that has a market. A product is not necessarily physical”.
First and foremost – identify your products.
There are several ways of defining products – we have often seen that products are identified through the value streams supported in the business, since it both makes sense for the customers and is easy to communicate.
When the product is defined, you can assess whether the already existing teams can support the products, or if you need to make changes that secure even higher value creation in the product teams that need to be defined.
Finally, there can be great advantages to talking about an operating model for product teams; what is their mandate? How does the organization support product teams? What is the upper management’s responsibility (besides product leadership) and ability to support the product teams?
Generally, we would recommend an iterative approach to implementing products in your organization, since no one can predict the consequences of the decision to work in product teams – and definitely not in the complex world that is swirling around us in recent years.
Good luck with your transition into working with real, genuine product teams.