Dedicated Product Teams

In my last article I talked about the importance of knocking down walls, especially the wall between product management and engineering.  In this article, I want to describe a technique that helps achieve this, along with several other significant benefits.

While there are many variations, there are essentially two common ways of running your product organization.  The most common of the two is project-based planning and feature teams.  In this model, the management of the company essentially defines a communal roadmap – they come up with a prioritized set of projects for the quarter or year, and they allocate time and people to those projects.  For example, they may have a team spend two months working on a new advertising system, and then the next high-priority project for that team might be a new search technology, or some SEO work.  The team may or may not change, but the project and even domain they are working on typically changes frequently.

If you look at the communal roadmap, you see a mosaic of different projects, each row typically an allocation of a set of developers to a project.

These roadmaps hardly go a week without significant change.  Some new business opportunity comes in and takes priority, so that throws a big wrench in the plans and a bunch of shuffling is done, or a project takes longer than expected, so that has a ripple effect.

(Not to mention that these project-oriented portfolio roadmaps are typically created before there is any real information or knowledge on what it will really cost to build this, and whether customers will actually want to use it.  But that’s a different issue.)

These communal roadmaps change so frequently are are so full of assumptions that they’re rarely something companies enjoy, but nevertheless this is often how they run their product organizations.  There are, however, several less obvious consequences of this approach.

First, team members are constantly moving around.  Product managers team up with specific developers on a project basis.  They rarely have the time they need to form the working relationships so important to effective teams.

Second, the developers are often constantly reassigned to different areas.  While on the positive side the developer gets exposed to lots of different areas, they rarely get the time to develop the deep expertise in an area that can make a developer so incredibly valuable.

Third, since the developer is switching topics so frequently, they don’t develop the velocity that an experienced team does.

Fourth, since the developers are scheduled on different projects beginning right after the prior project ends, this tends to encourage what we call “release and forget” or “orphaned projects” where a project is launched because it is scheduled to launch, but the follow-on work and the product optimization work gets deferred for months or even indefinitely because the team is on to other projects.

The alternative to this, which I’m happy to say is spreading fairly rapidly across our industry, is to move to dedicated product teams.

In this model, the executives, rather than debating specific projects, instead consider which areas of the business they want to invest in, and what percentage of resources to allocate to each area.  For example, for a typical e-commerce company, they might have teams like “Search and Recommendations,” “Product Pages and SEO,” “Fulfillment Systems,” “Infrastructure,” “Rapid Response” and “New Business Opportunities.”  They would then choose what level of investment they consider appropriate for each area.

The next step for the management team in this model is to define Team Objectives for each of the teams.  This essentially sets the business priorities for each of the teams.

Next, the organization staffs the teams with a product manager, designer, and developers.

In this model, the team then is charged with coming up with the projects, features and fixes that they believe will best deliver on the objectives they’ve been assigned.

There are two important differences here.  The first is that these teams themselves are ongoing.  They don’t switch from topic area to topic area after every feature or project.  Instead, they focus their energies on building true expertise on their topic, and coming up with real innovations in their areas.

The second is that the team members are persistent, in that they are assigned to this product area and they’re not just here for the specific project.

Of course management may choose to adjust the balance of resources by reallocating people, or by adjusting the objectives to reflect changing business priorities – this usually happens quarterly or annually.  And of course people are not sentenced to work on this area for the rest of their career.   They can and should move between teams, but generally people are working on a team for a year or so, and not just for a few weeks or months.

As I watch companies switch to this model, I consistently see the velocity go up as the teams gain expertise.  I also see the quality of product go up dramatically which I attribute both to the relationships that are built and also to the sense of ownership that teams feel over their area.

But most importantly, I see the business results that stem from the focus, the better product work, the innovation, and from continuous and rapid improvement of the product.

A few notes:

– A very useful dedicated product team is the “rapid response team,” there to handle critical fixes and relatively minor improvements and functionality.  I’ll describe this in more detail in an upcoming article.

– I also like a “new business opportunities team” that is there to explore new potential products or sources of revenue.  In most companies, these opportunities will always arise, and if you don’t have a team available to pursue, then all too often other teams are raided for resources.  Instead, plan for a small team to pursue these opportunities, and help them get good at evaluating potential.

– The one team and allocation that’s usually a given is the “infrastructure team.”  This is a special team, usually comprised of just engineers and architects, and the allocation is typically 20% for consumer internet companies.  You can instead intersperse this work into the other teams, or you can have a blend (a dedicated team plus some resources in each of the other teams).

– Moving to Agile, if you haven’t already, will get you part-way towards dedicated product teams.  It helps a great deal in building the personal relationships of an effective team.  But all too often, Agile teams are still handling backlog items from many product areas, and not being given the ability to focus on an area as a team.  That’s the difference really between a project team and a dedicated product team.

While I typically recommend moving to dedicated product teams for the full product organization, be warned that this is not a trivial change and requires executive support.  If your organization is not yet convinced, you can move just one or two teams to the dedicated product team model.  If you give this model even 6 months I’m fairly certain you’ll see the benefits and hopefully make the switch at the next planning cycle.