Be the Product Orchestra Conductor
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.
I immediately empathized with him, as I had seen the same issue happening several times in my own company. I had seen them in my own team. As a Product Manager, I had been responsible for them.
This week I stumbled upon an old article on Orchestra Conductors that made me think about the role of Product Managers keeping a team performing at its best.
“ Audiences often ask about the role of a conductor, since he or she is the only person on stage who doesn’t make a sound. Most of their work takes place before they ever meet up with an orchestra — studying, exploring and analysing the music, seeking to understand the composer’s vision. For the finest conductors, this is a never-ending journey throughout their lives…”
As a Product Manager of a multidisciplinary team I am responsible for getting my team’s resources balanced and aligned towards a common goal. As a result of my role keeping the team moving under the same vision and at an equal tempo, we should get results closer to this, rather than to this.
Looking in retrospective, there are multiple reasons why we have been unaligned. In the majority of the cases, it should be possible for PMs to either prevent or solve these issues asap:
- The Team does not follow / understand the vision. Product Managers generally “craft” and “own” the vision (if not for the whole company, at least for their Product’s team), thus they are responsible for getting it through every single brain in the team. Unless you prefer the code-monkey way, it is good that the team crafts this vision together.
- 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.
Is there a way to prevent this from happening?
Of course, most of the times. Next to the previously listed ideas for typical reasons, there are many other good practices that PMs can follow:
- Extended Sprint Plannings. In my previous team we used to “extend” our weekly sprint plannings in order to discuss openly about our vision (encouraging friendly fire and debate). We also liked to spend some minutes reviewing our position towards our quarterly goals or KPIs. Despite we were not as thorough as Christina Wodtke describes in her brilliant book, Radical Focus, this helped reminding everyone why we were working at certain things. Every other week, we would extend the meetings 30 extra minutes and do a deep-dive into a relevant user problem.
- 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.
And if still everything goes wrong… Although it is always better preventing than fire-fighting, it’s good to keep a couple of aces up the sleeve in case that part of the team is running faster than the rest:
- Arrange usability tests or research initiatives. As it happened with my friend, it is always often that UX side gets relegated when other priorities strike. If we can spot the issue on time and we want to prevent it from growing, we can propose the UX colleagues to take a break from daily tasks and spend some extra time researching. Depending on the product and its life-cycle stage, these initiatives may vary: discovering user pains, validating hypothesis,…
- 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.
Summing up, there is no magic formula to keep a whole Product team aligned and working at the same pace. Despite the multiple reasons that could disrupt the team’s alignment, a clear vision crafted, chewed and shared by its members should serve as a backbone to overcome minor velocity obstacles.
Please like, share and comment if you enjoyed it!