From Running multiple lean teams at once

This is a brief interview conducted by Jeff Gothelf in preparation for Lean Day UX in NYC on March 1st. This post originally appeared on

Running lean teams in the enterprise can become a tangled mess of experiments, rapid iteration and changes to the customer-facing experience. As your lean organization scales up, managing the direction of each of these teams and ensuring they’re communicating well and not stepping on each other’s toes becomes paramount. We talked with David Panarelli, UX Manager at LivingSocial to get a sense of how they deal with this issue in their ever-growing organization.

How do you separate the different “turfs” Lean teams at LivingSocial?

We have a large (100+) person organization within LivingSocial made up of engineers, product managers, project managers, and designers that we refer to as our Build team. The Build team is subdivided into three primary audiences: merchant solutions, consumer products and internal tools. Each of those teams is then subdivided into small groups called pods that each own a product. Our pods are really the atomic element of our overall product team and they operate as start ups within our company, each with a different agenda, but aligned around common goals.

The best example of how pods distribute responsibility is probably our consumer products. The primary navigation of our site in a large market like NYC is actually a rough approximation for how we split out our consumer facing pods:

  • Deals platform (our core product, local deals)
  • Escapes (travel packages)
  • Fun & Events (live events)
  • Shop (merchandise)
  • Takeout & delivery (ordering food online)

We have other teams focused on key consumer touch points like our mobile app, mobile web, and email.

Finally ,we have a team we refer to as the Unified Experience team and they’re responsible for tying it all together, managing site wide experience and also contributing to a lot of our new product initiatives that can span across teams.

This setup has allowed for tight communication within their pods and given each team a chance to fall into their own operating groove.

What are some problems that can arise from running multiple lean teams at once?

In many ways, the tight structure within these teams is a blessing and a curse. The blessing is that the team will fall into a groove together through regular working cycles. It’s easy for the team to get on the same page on the direction of the product.

The curse is a byproduct of that same tight internal communication. As people on the team get into the habit of communicating well with each other, there’s a risk that information that should be communicated to other pods might not make it. The result is one pod making a change to their product that has an impact on another product and hijinx ensue.

What three tips do you have for other orgs trying to run multiple concurrent Lean initiatives?

Well, I think it goes without saying that communication is key, but that’s always easier said than done.

First, it’s critical to have a shared set of goals. In much the same way that individual members of a pod need to be on the same page around their product direction, the larger team as a whole needs to be on the same page on their organizational goals. There should be clear, measurable KPIs that provide a definition for both success and for failure. Pods must identify how their work ties directly to that KPI.

Secondly, it is just as important that the progress against those goals be communicated throughout the organization on a regular basis. For example, a monthly report consisting of a rundown of work accomplished, the results of subsequent tests, and outlining how the work impacts the live product is a great tool. This not only communicates the progress of a given pod, but provides a window for other pods to look for potential conflicts in product direction and user experience. For extra credit, I’d also recommend highlighting other things as they happen, For instance, a pod can announce what kind of problems it’s taking on, or relay the output of sketching sessions over time. Be careful with this though—there is such a thing as over communication, especially while a project is only partially complete.

Finally, it’s been very useful for us to have shared resources like CSS style guides. A little digging in on’s front end will easily reveal that we’re using a CSS framework that we call LSUI. It allows our designers to work through prototypes with production-level code while serving as the canonical resource for what should and shouldn’t be on our site. But this kind of resource is more than just more efficient. Our team is full of ambitious, talented people. A resource like this helps us provide a playing field for our team, without micromanaging, and that goes a long way.

David will be one of the amazing speakers we’ve lined up for Lean Day: UX – March 1st in NYC. Tickets on sale now.