Be the Product Orchestra Conductor

How to keep multidisciplinary teams balanced

The other day I was talking to a UX designer friend of mine when he shared a recent frustration. Alongside with researchers and other designers, he had been working during few weeks on a major UI refresh for his employer’s site. Some days later, new priorities popped-up for their client-side developers, and his designs were still parked in a dark corner of his team’s backlog.

  • Unbalanced resources (e.g. too many UX designers in proportion to back-end or client-side developers, or a very Senior specialist in one area and a very Junior in another). Even though allocation of resources comes often from Senior Managers or Technology Managers, it is the PM who works day-to-day with the team and who should spot and flag the lack of equilibrium.
  • A lone-wolf / individualist in the team. Everybody has his preferred way of working, and that should not be a problem as long as it doesn’t break the common pace of the team. Being a little individualist doesn’t need to be harmful for the team as long as the outcome follows the same vision and complements other team members’ efforts. Orchestras have their soloists too.
  • Bugs and unexpected issues. Okay, we may have less chances to prevent this compared to the previous, but there is still plenty we can do to make the best out of the situation. More on this later.
  • Let them run the show. I’ve had great experiences with developers preparing team’s presentations, business reviews and talks. In preparation for the sessions, they will think thoroughly about the vision and “whys” of the team, and if not, they will be questioned during the session and learn for next time.
  • Disappear (sometimes). As a Product Manager I try to be next to my team as much as possible. However, due to circumstances I once ended up having two teams in two different locations, working on very different products and technologies and with different grades of experience. My initial worries disappeared alongside with me. My first team (the one for which we had been working on the vision with the best practices described before) became practically autonomous when I wasn’t present. 20% of my time was enough to achieve what I did with the other 80% in the new team. I almost made myself redundant! But what a great feeling when you see every member of your team articulating the vision in unison.
  • Cleaning-up technical debt. When the affected colleagues are back-end developers (client-side may also work), a good idea is to spend some time cleaning-up technical debt, optimizing past code-mess and even documenting complex parts of the code. This should help making your product more robust and scalable, therefore preventing surprises that could disrupt future velocity.
  • Mini-hackathons. If the company gives you freedom to do so, running small hackathons is a great way to prototype MVPs for ideas with unknown or unclear value, or even out-of-the-box and disruptive solutions for known problems. Again, worth another future post!
  • Offer help to other teams. No UX tasks until back-end guys catch-up? Another team may be facing the opposite challenge. Swapping resources is a great opportunity to share knowledge, learn from other teams, and especially to help colleagues.

Full-time learner, product stuff, “triathlete” & global traveller. Creating cool products @ Revolut, formerly @ Booking.com and @ Just Eat.

Full-time learner, product stuff, “triathlete” & global traveller. Creating cool products @ Revolut, formerly @ Booking.com and @ Just Eat.