[Note: I’m actually wary of “should”s, and what follows is more of a provocation than a call to arms. But I think it needs to be seriously considered.]
In 2007, Jared Spool wrote about the market maturity framework, and how technical product categories evolve from “technology” (where it’s compelling that a product simply does a thing at all) to “features” (where there’s competition that stakes claims based on the number of capabilities) to “experience” (which delivers a gestalt greater than the sum of the parts, and often involves removing features).
Most technical product organizations are still driven by engineering (“technology”) or product management (“features”). “Experience” is where design comes to the fore, but because of its nascency, design is typically subsumed into an existing engineering- or PM-driven org.
This means that many organizations place design within existing product/feature teams, looking something like this (for an imagined e-commerce service):
The vertical orientation is primary. On the left, there’s a leadership team with a Director of Design, Director of Product, and Director of Engineering who coordinate and plan across the teams. Then you have distinct “feature” teams that own different parts of the product, comprised of a product manager, a designer, and 4 (or so) engineers.
The design team is distinct and works together. The Director of Design still coordinates with Director of Product and Director of Engineering, and now also with a Product Manager on a key feature team. We’ve introduced Senior Designers who own relationships with two Product Managers each. When a PM needs to know what’s going on with design, the PM talks to that senior designer. And then we have 2-3 additional designers who collaborate with the Senior Designers or Director of Design as needed.
I call this a “Centralized Partnership” model, where design is centralized, but, through the senior designers, there is a real commitment and partnership with product areas. The benefit of this model is that designers can work across multiple features, ensuring coherence of the experience.
However, this is still ruled by “features”. So, maybe we need to fundamentally rethink it?
If companies are serious about focusing on experience, than design teams should be free to work on that holistic experience, which means that they can actually address a whole lot more. At Adaptive Path, I lead a project team on an e-commerce site. We were able to deliver across many more features, because we weren’t constrained by product teams.
The open question is to figure out how product management and engineering should be structured to support this crafting of experience. But it doesn’t make sense to let legacy organization structures constrict our ability to deliver the greatest possible experience for our users.