Product Marty Cagan

The Internal Agency Model

I have long written about the importance of dedicated, durable product teams and that we should always strive to optimize for the team and not for the individual function (e.g. product management, user experience design, engineering, test automation, data science, etc.).  It’s not hard to spot when teams have not embraced this model, as you see lots of organizational silos and “walls” between members of the team.

Fortunately, most organizations I meet now have honestly embraced the critical notion of a durable, cross-functional, and whenever possible, co-located, product teams.

That said, there’s one function that too often only has a half-hearted presence if at all, and is actually one of the most critical.  I’m speaking of user experience designers (interaction designers and visual designers especially).  I have written about some related points before, but this is different.

All too often what I find is that the UX designers want to go off with each other for several days to several weeks, and eventually come back to their team with their “grand reveal” of their new design.  I call this the “internal agency model” because they are essentially trying to run like a small, in-house design agency.  People make requests of them and they do their best to accommodate.

There’s so many things wrong with this, but these four are the big ones:

1) That design is predicated on a specific understanding of the necessary functionality, which has probably changed several times in the past 48 hours.

2) That design may be predicated on a technology direction that may have changed in the past 48 hours.

3) If the design time did not include testing on actual users, then the design will almost certainly change dramatically once it does, and much work will have been wasted.  If the design did include testing on actual users but the product manager and key developers weren’t there to watch and learn as well, then there was a very big opportunity missed and don’t be surprised if your learnings are ignored or discounted.

4) This is really a derivative of waterfall.  That’s why it’s often called the “lipstick on a pig” model.  The design can only do so much in this model as it’s taking the “requirements” as an input.

So if this is so bad, why does this happen so much?

First, it is often driven by the leader of the UX team.  She understandably feels very strongly about the need to ensure both good designs and consistent designs from all of her designers.  One way to do this is to get the designers together during the day and have them work more with her and with each other rather than with their teams.

Second, it’s also a reality that in many organizations, the UX designers are coming from much more of a visual design background rather than an interaction design background, and what I’ve described is much more common in visual design.

Third, another reality is that many UX people do actually come from design agencies, so it’s no surprise that they tend to work at your company like they did at their former agency.  However, the main reason we hire staff ourselves and try hard to avoid needing to use an agency is precisely to avoid these problems.

Bottom line is that if you consider the design of the experience (interaction design, visual design, and for devices, industrial design) as critical to the success of the product as I do, then you’ll want to make sure to treat UX design as the first-class activity it needs to be.  The designers have to be first-class members of their product teams, sitting right next to their product manager and engineers, and truly collaborating on devising the blend of functionality, experience and technology that can result in a winning product.

Note that there’s nothing wrong with the designers getting together once a week for a few hours and spending some together-time with their UX colleagues from other teams.  It’s a great way to tackle hard design problems, and learn from each other, and keep developing skills.  But the key is to optimize for the product team, not for any particular job function.