What is a Product Team and what is the difference with a Feature Team? Surely, beyond the vocabulary, Marty Cagan explains in his books Inspired and Empowered the difference of concepts behind Product Team and Feature Team.
- How the company environment results in Feature Teams or Product Teams
- What is a Feature Team, as described by Marty Cagan in Inspired and Empowered
- What is a Product Team, as defined by Marty Cagan in Inspired and Empowered
- The Strategic Context: prerequisite to Product Team's empowerment
- What’s next? Learn about other frameworks around Product Development like Lean Startup, Story Mapping, Impact Mapping and Agile
- Do you want to learn more about Product Management? Here are some valuable references
In this blog, we refer to Squad, as the vocabulary of organizational components is inherited from the Spotify Model, but this notion covers both Feature Team and Product Team. Both of them align on Value Chains for more efficient delivery of features. In addition, the more the team is empowered, the better. So, the minimum level of empowerment is the Feature Team, but the target is to reach the level of empowerment of the Product Team.
How the company environment results in Feature Teams or Product Teams
Most of the time, companies consider technology as a necessary expense. Surely, they know it’s important, but they see it as a mandatory cost to do business. Furthermore, they think of themselves as in the insurance business or the banking business, for instance for the finance area. As a result, in most companies, the business considers technology teams as to serve them. On the contrary, in strong product companies, as Marty Cagan stresses it, technology is not an expense, it is the business itself.
What is a Feature Team, as described by Marty Cagan in Inspired and Empowered
In a nutshell, a Feature Team works to serve the business, in contrast to the Product Team that works to serve the customers in a way that is compliant with the business.
As a result, the characteristics of a Feature Team are for Marty Cagan:
- The Feature Team does not get a strategy from the business but a list of prioritized features.
- The relationship with the business and the management is command and control.
- The consequence is for the team to have a mindset of mercenaries: they are not empowered and not responsible for the result, in other words, the impact on the customers. Clearly, they just deliver features meeting business requirements.
- At last, they are not involved in product discovery. They just contribute with coding of features, once this step done.
What is a Product Team, as defined by Marty Cagan in Inspired and Empowered
Product Team vs Feature Team: common roots
Product Team and Feature Team are both Agile Teams and they share many characteristics of the Agile Squad:
Autonomous to remove as far as possible dependencies
Cross-functional to cover all aspects to address business needs
Multi-skilled to specify, develop, test and deploy in production features
Covering both development and production: “You built it, you run it”
Co-located to enforce optimal collaboration. Space and visual management are also key levers to support team work
Long-lived (> min 12-18 months) to reach optimal velocity
Stable but not fixed: size of the team and skill mix adapt to the business needs
The approach to define the scope of Product Teams and Feature Teams is also the same to enforce as much as possible autonomy and alignment on the business. In addition, for both type of Agile Teams, ownership emerges with autonomy on a clear scope. But the level of ownership is different as we will see with the change of paradigm coming with Product Teams.
Product Team vs Feature Team: the change of paradigm
It’s all about solving problems, not implementing features.
As Marty Cagan puts it, the purpose of an Agile Team is not just to deliver features. More than the output, it is the outcome that matters and solving the right problem for the customers. As a result, the relationship between the IT and the business is different with Product Teams. Indeed, the Product Team serves the customers partnering with the business to build products that delight the customers in compliance with the way the company works.
Mercenaries build whatever they’re told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers.
So the work between IT and the business in a Product Team is not sequential with the Product Manager defining requirements, then designers designing a solution, and at last, the BA and developers implementing the solution. On the contrary, they all work together hand in hand and since the beginning.
Product Team’s key characteristics
The Product Team has 3 core characteristics:
- Firstly, the Product Manager gives the team a problem to solve.
- Secondly, the Product Manager and the company empower the team to solve this problem in the way they want.
- Thirdly, as a consequence, the team is accountable for the result.
In a nutshell, there is a switch of mindset in a Product Team: the team thinks like owners, not like employees, so they take the responsibility for the outcome, rather than just the output by delivering feature.
At last, this switch of scope of responsibility, mindset and the change of the nature of the collaboration with the business, make it possible to tackle risks earlier and solve problems more upstream.
Product Team’s roles
The Product dimensions and risks split over the roles as follows.
Product Manager
Valuable
The Product Manager makes sure that the solution is valuable. In other words, that the customers will see enough value in the product so they will buy it and use it.
Viable
The product Manage also enforces that the product is compliant with the company’s way of working and that it is profitable. To put it differently, that the product meets business needs.
Ethics
This subdimension is in a way part of the viable dimension as it is related to the compliance with the company’s values. But it is a good practice to address it specifically as profitability and ethics may conflict. Surely, this is the responsibility of the Product Manager to ensure that the product meets ethics.
Designer: usable and valuable
The role of designers is primarily to take care of usability. But as they work on the user experience and that value is for most part perceived value, then they contribute to how the product brings value to the customers.
BA and developer: feasible and valuable
For sure the BAs and developers are responsible for the feasibility but not just that. Indeed, with upstream collaboration coming with the Product Team notion, they also contribute to increase the value, for instance highlighting how the technology can bring more value to the customers.
The Strategic Context: prerequisite to Product Team’s empowerment
The Strategic Context is necessary for the Product Team to have the total view on the business context in which they operate. Therefore, it is the prerequisite to Product Team’s empowerment. There are 6 components in the Strategic Context.
Company Strategic Context for the Product Team
Company Mission
The Company Mission is the purpose of the company. It is a simple, long lasting statement, sometimes for the whole life of the company. Truly, all employees should know it thanks to a broad communication, so they know why there are here.
Company Scorecard
The Company Scorecard provides the big picture and the health of the business thanks to Key Performance Indicators (KPIs). Furthermore, synonym names are company dashboard or the health metrics.
Company Objectives
The Company Objectives are objectives the company focuses on for the ongoing year. The high management of the company selects them as the most important areas to focus on, leveraging the feedback from the field. At last, the company objectives must be outcomes, in other words, business results, not output, like the delivery of projects.
Product Strategic Context for the Product Team
Vision and Principles of the Product
Product Vision
A company delivers its vision designing, building and delivering products and services to its customers. The Product Vision derivates from the Company Vision and captures the vision for a given product and how it is going to contribute to this Company Vision. It is a projection of 3 to 10 years in the future and it describes the future the Product Teams aim at creating and why that future will improve the lives of their customers.
The mission may provide the purpose, but it’s the vision that begins to make this tangible.
Product Principles
The product principles complement the product vision. Indeed, they state the values and beliefs the Product Team will refer to when taking decisions about the product.
Team Topology
As part of the input of the Strategic Context, Marty Cagan describes, the Team Topology as the scope of responsibility of each team in a group of Product Teams working on the same product. Surely, it is important for them to understand the big picture and how they interact with each other.
In Agile at Scale, as this blog develops it, Team Topology is just a part of the operating model as there is the need to explain how the delivery activities structure, but also medium and long term activities indirectly contributing, like the people development and the knowledge management that chapters support.
Product Strategy
Strategy is a multiple meaning word. Marty Cagan defines the Product Strategy as the concept that makes the connection between the Company Objectives and the Product Vision, then drives the Product Team’s objectives.
Note that the ambition of the objectives relates to the nature of these objectives:
- Roof shot objectives: low risk, low rewards, conservative objectives but with tangible results. Yet, some of them requiring a strong commitment, for instance to meet an external constraint like meeting a compliance requirement. Marty Cagan refers here to High-Integrity commitment. Indeed, with the empowerment of the Product Team comes the responsibility with the results and the capacity to commit on dates and deliverables for topics that require it. Of course, this is the exception, not the rule, as the focus is typically on maximizing outcomes, not guarantying outputs.
- Moon shot objectives: high risk, high rewards objectives, that are bets either on technologies, the market or the customers with potential results of 10X improvement. Surely, the objective is ambitious but considered possible. Definitively here, there is no possible commitment, as it would kill risk taking and innovation and the team would switch to well known solutions.
What’s next? Learn about other frameworks around Product Development like Lean Startup, Story Mapping, Impact Mapping and Agile
- To learn more about other frameworks supporting Product Development like Lean Startup, Story Mapping and Impact Mapping check my other posts.
- In addition, you can review my posts introducing Agile and Agile at Scale.
- At last, learn more about innovation with all my posts about Digital and the disruptive technologies.
Do you want to learn more about Product Management? Here are some valuable references
An article from Marty Cagan about the difference between Product Team and Feature Team.
Product Management books:
- Marty Cargan:
- The Product Book from Josh Anon, Carlos González de Villaumbrosia