Organizing teams around users, not features

For the last 6 months at Clever, we have organized our engineering teams around the type of user rather than the part of the product. The result has been increased collaboration, deeper insights, and an explosion of new product ideas.

As an engineering team grows, it is natural to divide it in terms of the various features of your product. At Clever, this meant having a team for our API, a team for Instant Login, and a team for Secure Sync. It seemed like the obvious thing to do and worked pretty well, but there were some issues:

• There were parts of the product that did not neatly fall into the three categories, and so were either thrust upon one team or were left to languish.
• There wasn’t a clear path to experimenting with new products, short of carving out a separate team or task force.
• Teams and roadmaps were designed around improving or adding functionality to the given feature, rather than around user needs or jobs to be done.
• Teams created slightly different experiences that were all used by the same set of consumers, resulting in strange inconsistencies in the product (a consequence of Conway’s law).

In April we were blessed to hire Ben Adida as our fantastic VP of Engineering, who looked at this situation and proposed a new structure: aligning teams to user type. We now have 3 such teams: the Schools team, responsible for building products for students, teachers, and administrators; the Apps team, responsible for building products for edtech developers and companies; and Internal Products, responsible for building products that enable our support, sales, and marketing teams. Each team has a product manager, engineering manager, and group of 4-10 engineers.

The benefits of this restructuring have been swift, surprising, and significant:

• Teams are excited to improve the experience for their assigned user group, and willing to dive into unfamiliar codebases to do so. Parts of the product that don’t clearly fall into one team are now improved by both teams, as opposed to neither.
• Teams have significantly greater flexibility to prototype new products and features, re-analyzing past assumptions rather than taking them as given.
• Product managers can focus on a group of users and needs, resulting in increased empathy, deeper insights, and tighter collaboration with customer-facing teams.
• Products and experiences feel more cohesive and consistent, both for our external users using the product and internal teams working with internal tools.

As a platform, Clever is fortunate to have clearly-defined, distinct user types and a narrow range of technologies - for instance, we don’t have an iOS or android team. I am not sure whether a user-focused structure would work for other companies, but it has had great results for us.