Why designers should be embedded into product teams and what that even means
Consider these two schools of thought for how a product company might structure its teams:
#1 — Project Teams
In a project organization, individuals from different departments are assigned temporarily to projects (shocker!). Project members contribute temporarily until the project is completed, usually at a pre-determined deadline. Individuals may work on multiple projects at a time and may rely on others in their department to produce their share of the work.
#2 — Product Teams
In a product-based organization, designers are distributed into product teams. These teams — sometimes “pods”, “squads” or “scrum teams” — support a particular product or product area indefinitely. They exist independently of organizational silos and have minimal dependencies on others from outside of the team. Product teams tend to be more conceptually aligned with agile practices.
Reality doesn’t always break down cleanly into one of these two categories, but it’s still a useful dichotomy to consider.
Now, let’s say that you’re a designer in an organization that already has partial product teams.
Engineers, QA, and Business/Product leaders are organized into dedicated teams that are aligned to certain product areas.
Designers aren’t totally committed to those teams— they aren’t embedded. Instead, they still follow something closer to a “project” model. Teams request design help when they need it, designers are dispatched, and then when they’ve finished a set piece of work their allocations are renegotiated across the teams. The design team proudly boasts that it operates “like an internal agency”.
I suspect this is a pretty realistic scenario! UX groups and practitioners often seem to be hesitant to fully get on board with an embedded model.
But is that a mistake?
I’d argue that it is.
Product teams are already overwhelmingly the norm — especially in startups and…