A popular way to initiate a new team to solve specific problems/ deliver specific scope is by funding a new project. The project team then exists for a limited period until reaching the goals defined in the business case. On the other hand, the product team is usually durable (exist several years) and take ownership of a product. It is not strictly constrained in a specific problem/ scope but is more open to adapt to news, changes from customers or the product context.
A clear cut to explicitly label a team is project or product team is not important. A team can start as a project at first then transform into a product team to take ownership of the newly built product. Or a product team can also experience project delivery to tackle specific problems at certain times. Some key considerations to structure a team are:
- Delivering outcomes/ solving root problems for stakeholders is the purpose/ mission of the team. Not simply building a function or defined scope. Sometimes, a team might stick to defined output but forgetting why that output is needed.
- “The Pool Model” with engineers are fully utilized from project to project could be a myth. Careful attention is needed to distinguish between hours optimization vs value optimization. It takes time for the team to deeply engage with the problem domain and understand customers’ needs. Then, the team can achieve valuable outcomes with customers.
- Context switching should be minimized to help members stay productive. It’s not only about the domain knowledge, system familiarity but also about people relationships. It takes time for members to get to know each other and form a cohesive team.
What are your thoughts on structuring teams around products, projects, or functions?