Product Team Mindset
Are you ready to go beyond the comforts of an Agile mindset to a Product mindset.
Over the years in IT, teams have been organized more as component teams or feature teams. Component teams were more formed around the IT investments like the mainframe group, the DBA team, the website team etc. Terms like UI teams and backend teams were the more familiar structure.
Shown Below is an example of Component teams. Depending on the platform or IT investment like Salesforce CRM,
These teams also tend to have ownership of the components and get funded yearly to get work done on whichever component they are responsible for.
This structure has its own pros and cons. Pros being people become experts of a certain area over time and the main con being the automatic dependency when anything needs to get done. The agile movement of cross functional teams led to the formation of feature teams. Feature teams are still heavily IT driven initiatives where instead of having teams around features or value streams. For e.g Search feature may have many pods each pod having representation of skills that can work on the UI, the platform and a data team. This resulted in what is now famously known as a T Shaped team. The work for both component and feature teams were funded by business teams and were prioritized mainly using gut feel by the role of a product owner. This also led to the term Full stack developer, someone who can work in many layers of the code.
Over the years with technology like React, Angular , AWS, Azure , Kafka, Microservices , Containers etc. It is now impossible for any one person to be a master of all stacks.The skills of the team balances out the overall skills needed to deliver the feature.
Siloes of Product Ownership, Design and Engineering and Ops.
The feature team and component team model solved the problems for developers and testers. However product ownership, UX Design , engineering and Ops continued to work in Silos and have teams of people working in their own teams. This creates
How do Project Based funding models work with Component and Feature Teams?
The predominant funding model for both component and feature teams is project based funding model. Each year the company sponsors key initiatives through a portfolio prioritization process. This allows for various key initiatives to be completed.
Each portfolio is made up of initiatives/ projects which then get funded. The initiatives/ projects are then estimated and then driven by product managers and product owners in product backlogs. The approach till it gets to the backlog is very much a waterfall.
Since the funding typically happens once a year, that becomes the general planning horizon and everything revolves around it.
Teams end up pulling from the different backlogs and in the end everything comes down to a prioritization exercise as capacity for most organizations is generally considered fixed for any given time period.
So the project based funding models have become shorter and organizations are taking a proactive approach to relook and prioritize the portfolio at least one a quarter.
So here the funded entity is the Project and that pretty much drives what goes in the backlog. While it is true that funding models are not any more once a year activity in organizations, the amount of such organizations tends to be very less in no. Most still do a large scale once a year exercise. Can we rethink our teams and make them truly customer facing. The answer lies in Product Teams and also how they get funded.
What are Product teams?
Product teams are a startup within an enterprise. A collection of teams that are aligned around a product area or a value stream. They own the entire end to end lifecycle around that area soup to nuts. This will also include sales, marketing and other functions in this group itself instead of them being in another part of the organization. Mainly there are no more two separate groups within the company business and IT.
An example is a large investment bank in the east coast that has completely restructured its investments group where each POD consists of the sales and marketing functions, and then many teams in a POD that are aligned to a specific feature on their product like Search.
The main difference between Project and Product teams is that
|Funding||Based on delivery of outcomes to the business and funding is many times a year.|
Funded entity here is the Team.
|Projects are funded based on milestones and are typically funded once a year. |
Funded entity here is the project
|Teams||Long lived teams that own the entire business outcome. More like the Amazon model of teams with a Single Threaded Leader||Teams are formed around projects,|
|Who owns||Team is part of the business unit.||Generally IT owns Projects|
|Customer facing||Yes , this is the big difference||Sort of through the proxy of business stakeholders and product owners|
|Silos||Same team has business, product, engineering and design and team members are encouraged to learn each others skills||Clear separation between Business, Product, Engineering, & Design|
Many IT organizations that are now doing agile and devops practices well, are still struggling to deliver value and aligning teams around the product areas and giving them full responsibility is not new to companies like Amazon, for large enterprises this is still a challenge yet to be solved. This requires a complete mindset change from the entire enterprise and also needs teams to step up and learn newer ways of working so that they can directly engage with customers, own specific areas in the value chain/ user journey. This also brings new challenges to large monolithic architecture in favor of more microservice driven , micro front end architectures that enable rapid development at scale. This also requires leaders to reimagine how they have designed the organization, and trust the teams more to deliver to outcomes than output.
Are you ready to imbibe the Product Mindset? Learn more about moving your group to a product mindset ? Learn how to redesign your portfolio to create product teams aligned around customer journey / value streams.
Contact us at email@example.com and learn more how to go about this change in a predictable way.