“Testing, 1–2–3, mic check” — what being a professional DJ taught me about product management

It’s 9:30pm, and the speakers are pulsating. Party goers can be seen vibrating and singing along to 50 Cent’s ‘In Da Club,’ as the fog machine pushes out another blast of smoke through a laser show that rivals a museum’s security system.

In one corner of the room, there’s a group of people taking a breather — after dancing for an hour straight — visibly wiping the sweat from their foreheads. The front of the stage houses the more dedicated group of dancers, getting lost in the music and completely disregarding how they look to the rest of the crowd.

As the DJ and main arbiter of the evening’s entertainment and provider to a band of music enthusiasts, seeing the crowd’s reactions when a song begins playing conjures up a slew of different feelings — satisfaction, accomplishment, pride, and even a sense of relief.

It was akin to the same feelings I later experienced as a product manager. The moment when that feature improvement, bug fix, or brand new product hits the market, ready for consumption. As I look back on my experience DJing for all sorts of events, crowds and venues, there were plenty of experiences that I could draw on, to help me in my pursuit to become a more successful product manager.

Handling requests

One of the main roles of a DJ was to be able to openly take song requests. I’ll never forget one occasion, when someone requested a heavy metal song at a wedding. While there’s certainly a time and place for that style of music — and may have satisfied ~1% of the crowd that day — it was important to push back and say no to it. On the flip side, there were many instances where the song requests would fit right into the set list, and we were more than happy to take it into consideration. Similarly as a product manager, I always dealt with product feature requests, some of which made sense, and others that did not.

The point is, I learned how to separate the two, and be disciplined with the decision to say yes, or no.

If you are to say no to a feature request, or special update that only suits a very small percentage of your user base, you’ll need to be able to balance that with delighting the rest the users.

Double down on the hits

There were always a group of songs that ‘killed,’ in almost every setting — whether it was a party, dance, wedding or club. They could bring droves of people to a dance floor, and get them singing and screaming for more. We always tapped into those songs, because we knew from our experiences playing to various crowds that they would work. When planning and executing a product roadmap, there was always a strong gravitation towards digging into historical data — whether it was post-mortem documents in Confluence, project delivery performance in Jira, or even customer feedback post-release.

After trawling through that data, we could focus on the areas where we were successful in planning and executing a certain project. Of course, there were certain weak points that we knew we needed to improve upon as a team. And we always blocked off time to try and reduce those hotspots. But, we also knew we were strong in other aspects, and if we played to those, there would be many positive outcomes when it came to successfully executing a project.

Get in front of the customer, early and often

Planning a set list for a wedding was always a very detailed process. Months before it even started, I would meet with the wedding party to listen intently about what they wanted to hear at their wedding — the specific songs they especially loved, the genres to stay away from, etc. While I often had to meet some of their more specific needs (like the ), they usually left it up to me about what to play. During the wedding, I would check in with them periodically to make sure things were going well, and if they had any feedback.

With product releases, integrating early customer insights before launching was a large part of the process. This often involved spending a tremendous amount of time conducting user tests, surveys, and doing phone calls. Whatever we were building and getting ready to launch, it was vital to get it in front of our user base, to make sure we were aligned with them before confidently shipping to the masses. During the post-launch phase, we would deploy a similar process, and see if the feedback and insights matched what we originally hypothesized — and, most importantly, if we were on the right track to meeting our goals.

Always be communicating

In addition to hearing a crowd cheer or whistle, we would always take it a step further to make sure we always kept them engaged — “How’s everyone doin’ tonight?!” “I can’t hear you, make some noise!” It wasn’t just about playing a song and seeing a reaction, we wanted to let them know we were there to keep things on track. In the trenches, and ready to make it a fantastic experience. On the other hand, if a crowd wasn’t very enthusiastic, didn’t like a specific song, or would come to the DJ booth to express their disdain, we needed to meet the criticism head-on.

While I never tried to pump up a project planning meeting by playing , communicating with a group of project stakeholders was an integral part of ensuring a release was on track. Is the design team not getting adequate feedback from user testing? Is a project delayed due to some issues in development? Are there conflicting opinions about which layouts to use? Whether it was a positive update, or we were facing some adversity, communicating and laying it all out for stakeholders was key, and crucial for the project’s success.

12am. The event starts coming to a close, and the energy permeating throughout the venue is still in full swing. The place now feels like a sauna. But, it’s time to close out with the last few songs, and finish what we set out to do at the start of the night. Reflecting on the evening, surely there are a few things that need improvement. Maybe we’re due for another post-mortem.

Photo above by on .