What Playing in a Rock Band Taught Me About Product Management
In the late 90s and early 2000s, I played in two regionally successful rock bands, The Larkspurs in Minneapolis and Method Engine in San Francisco. We played at all the top clubs, had professional management, and, in both bands, we signed promising production deals (a common step back then before signing to a major label) that enabled us to record in state-of-the-art studios with professional producers and sound engineers.
At first blush, I can’t think of anything more different than being a product manager at a tech startup and being a lead singer/guitarist in a rock band. Rock bands are all about music and image. Startups are all about business and tech. Rockers are cool. Product managers are geeks. The two worlds are vastly different, right?
Well, maybe this was true years ago. Now I think it is quite easy to see the similarities. Both product teams and rock bands usually consist of a small group of like-minded individuals following a dream or vision. There are key roles that look a lot alike: product manager/lead singer, tech lead/lead guitarist. Both product teams and rock bands are trying to create something new, build an audience, and sell their product. And, there is an element of fame and adulation in both fields. In fact, I would guess that startup founders, who are usually their company’s first product managers, beat many rock stars in notoriety and outrageous behavior these days. Anyway, you get my point–there are a lot of similarities.
Having lived in these two worlds, here are some lessons I learned as a rock and roller that have influenced my days as a product manager.
Play Ugly, Play Often, Play Different Songs
Play Lots of Gigs
In the rock and roll days, we turned down a lot of gigs. Why? We wanted each show to be something really big and spectacular. We want it to be a packed house and something no one could miss. Everything had to be perfect and it had to be a huge event! Therefore, we spaced out our concerts to create this effect. The problem was that you need to play for a live audience to get better at playing live. Even if you are just playing for the bartender you’re getting yourself out there and learning along the way. We could have been so much better had we thought of each gig as an iteration, an opportunity to improve, rather than a single, one-off event.
So it goes in product management. Too often we wait too long to ship because we want something to be perfect. We’ll pre-optimize a product before launch when it’s cheaper and more effective to post-optimize (as in optimize after launch with real user feedback and data). Additionally, there is often organizational pressure for “big bang” launches. These launches are usually tied to a PR push, contractual obligation or other external event where it’s beneficial to launch a major feature or new product all at once. As product managers we must help the organization see the costs and benefits of this approach and make a rational decision. In most cases, being iterative and thinking of each release as a way to learn and incorporate feedback will be the way to go. Trust the process. Ship often. Play lots of gigs.
Write Songs Outside Your Comfort Zone
Sadly, I only learned this one years after my music career was over. In the band, we had such a constrained definition of our musical style. If we ever veered into new territory stylistically, we were always very quick to say, “that’s not our sound” and revert back to the tried and true. The pressure to keep writing material that fit those constraints, in my mind, is one of the reasons we eventually burned out and split up. We were afraid to grow into something we weren’t quite sure of. I learned too late that discomfort and creativity are like tequila and salt–pairings that lead to great things.
I’ve seen the same hesitancy to push the boundaries in product teams. There can be a plethora of large and small biases in a team that can hold you back. Maybe it’s coming from the person who has been there for years saying “we’ve tried that before and it didn’t work.” Or the engineer throwing her arms up lamenting that the code doesn’t work that way and it’s too much effort to change it. Maybe it’s a UX pattern or pricing structure that everyone knows is super important but can’t remember why. What are your sacred cows? What are your unstated constraints and assumptions? Find those. Push on those. Go past your comfort zone. The bigger wins are in that space. And maybe you’ll move beyond sounding like a B-grade version of Radiohead.
Play Well With Others
Tell the Drummer what the Song is About
Often when the band was learning a new song and it was starting to sound pretty good, I’d ask the guys if they knew what the song was about (if I had written the song). Our drummer would always crack me up with his answers. He had no idea what the songs were about. Not even close. He would make up stories and sing along in his head with his own incorrect lyrics. To top it off, his made-up songs were all about characters from The Simpsons! He would transform my lyrics into songs about Homer and Bart. It was both hilarious and frustrating. Suffice it to say when I told him what the songs were really about, the drumming got better and the rest would fall into place.
(Update: It should be noted that the drummer mentioned is a top-notch professional musician, a successful business person, and an all around hilarious guy.)
As a product manager, imagine if your engineers and designers were making up their own stories, their own lyrics if you will, because you haven’t told them what the project is all about? What if they are as far off from the real story as was my drummer? It’s a disaster waiting to happen and in a business context I doubt it’s hilarious. Your team deserves and requires context. This is not going to slow you down. The small upfront cost will be paid back quickly. Show your team why you’re going in this direction. Explain how it fits into the bigger picture and why the timing is right. If there’s urgency (there always is, right?), help them see that directly. To create a better product, a better feature, or a better song take the time to give the correct context.
Let the Bass Player Write Her Part
One needs to be careful in a band not to let one’s ego get in the way of working with one’s bandmates. Sure, you’re not the bass player, but you may be certain that you’ve figured out the best bass line for the song. You may even think you can play it better yourself. It’s driving you crazy, but hold back. Assuming the bassist is in the band for the right reasons, give her the space to create. Feedback and productive nudging can be welcome in certain circumstances at the right time. Our bass player in the Larkspurs, Charlie, was not fast, but when given some time, he always came up with the perfect bass line for the song.
Similarly as a PM, you may be certain you know the best UX for the product you are building. And no doubt you know a thing or two about visual design (everyone does, right?). And shit, you used to code! Fuck it, I’m gonna get in there and… Stop! Hands up. Step away from the computer. Seriously, always question your own certainty. It’s likely an ego trap. Let your specialists do their job and give them time to do their job well. Feedback is important but, again, it must come at the right time in the process. See what your team comes up with before being directive. If they didn’t come up with a good solution, ask yourself if you framed the problem correctly. A great rock song may be the initial vision of one person, but it takes a band to arrange it and play it well. Same deal with products.
Play in the Broader Ecosystem
So You Can Play Guitar, Now Learn the Music Business
In music it is really easy to get taken advantage of if you don’t understand the music business. It’s one thing to be dazzling on stage or a virtuoso in the studio (I was neither), but it’s hard to be successful at any level without a competent understanding of contracts, accounting, royalties, intellectual property protection, publishing rights and, most importantly, cash flow. Even the “creatives” in the band need to grasp these concepts as well as have a few professionals in your camp to help flesh out the details.
In product management, it’s no different. You and your team may have built the most amazing, highly converting funnel for a brilliant, sticky product, but if you don’t understand how that fits into the greater business strategy or how the economics work you’re going to be at a disadvantage. You need to develop relationships with marketing, operations and finance to truly grok how the business operates. Mastery of the customer need, UX and the underlying technology is one thing. Fluency in the business side of product management makes or breaks a product manager’s potential for career advancement.
Definitely Crowd Surf
Despite being right next to some of the best networkers in the business (Mark, the manager for both bands, and Ted, my co-founder at Dogster), it took me too long to comprehend how important networking is and how to be effective at it. They say your true net worth is the value of your network not your bank account. I believe this. Opportunities more often come from the people you know than from talent or output alone. Mark got gigs at First Avenue opening for major acts like Semisonic because he hustled to create a network in the local music scenes. Ted got us funding, an exit, and tech pals I still value years later through his natural talent and pleasure in meeting new people. Having friends in the business you can bounce ideas off of, contacts that can put you in touch with the right people for partnerships, and a network that helps with recruiting team members is key. Specifically, as a product manager your network will help to broaden your influences and expand your universe of ideas that eventually you’ll leverage in making great products.
What flipped the networking bit for me is a) learning how to network and b) realizing that you cannot do it solely for personal gain. You’ll never succeed with only self-serving intent. Do it because you like to meet interesting people. Do it to see how you can help others. It’s one of those weird paradoxes: you’ll get the benefit of a network only if you build a network without attachment to the end result or expectation of reward. I think Give and Take by Adam Grant does a great job at explaining this.
The rock and roll life is now mostly a fond memory from the past. Product management is my every day. It’s funny how our past experiences, no matter how different, can leave us with important lessons for our present situation. I’m sure a former Peace Corps volunteer, a former bee farmer, or a former journalist might be able to write a similar article on their transition to product management. It’s that kind of job. Well, rock and roll was fun but product management is pretty great too. And the hours are better.
