What Playing in a Rock Band Taught Me About Product Management, Part 2
In late 2016, I remember reading a great bit by John Vars (now CPO at Qonto, previously Varo Money & TaskRabbit) titled as per the above, which of course immediately grabbed my attention; in the article, he delves into his past as a musician, and draws parallels to his present vocation. Obviously, I highly recommend reading it if you haven’t yet — find it here.
Given that I’m also a product manager, as well as a (still active) musician, I decided to “be inspired” by John’s title (see “Be inspired — and be honest (or even bold) about it.” below) and write my own take on this theme. That being said — John, I fully agree with all of your points, so I tried to focus on additional aspects.
Here we go:
First of all, some background:
I’ve got 5 years of IT product management experience under my belt.
At the same time, I’ve been drumming — mostly for heavy music bands, so anything that’s hard rock up to death metal — for over 16 years now (wow, that’s more than half my life!).
The first time I professionally recorded an album was in 2007 (at age 19), I’ve recorded almost 10 of them so far, played shows in all kinds of places, and high points include recording an album for a Greek metal band called Mencea, performing an arena show in Greece with them alongside huge metal bands like Testament, Blind Guardian and Gojira in front of thousands of frantic Greek metal fans, and performing on a Rammstein-esque German band’s record that charted at position 68 in Germany (before it got rated 18+ for explicit content, haha).
As John put it very well, “Both product teams and rock bands usually consist of a small group of like-minded individuals following a dream or vision.”…so here’s what I’ve been able to apply from my point of view — which is back-center behind the drum kit, of course.
At first, play often — but learn when to start playing right.
John describes a very typical “rookie mistake” for bands to not go out there and play enough, urging to “Play Ugly, Play Often, Play Different Songs”. While initially, I’d co-sign this order any day, executing on this philosophy too excessively will lead to no one showing up anymore because they’ve “seen those guys too many times already”.
Don’t be these guys.
Or them.
So yeah, go out and play lots of shows at first — but if you notice fatigue with your fan base, try to focus on the right shows to play, and to expand to other audiences with the time you’ve freed up.
Same goes for producing software:
- At the beginning, don’t overcomplicate release cycles — give the users what they need and don’t lose momentum.
- However, if you’re noticing too much buzz and confusion happening around shipping things (common signs: confused stakeholders, lost features and deployment pipeline “traffic jams”), then you might want to focus on shipping properly and sensibly instead of often as a paradigm.
Be inspired — and be honest (or even bold) about it.
As a musician (or rather an artist in general), one continually tries to create unique works of art; if you draw inspiration from others, you’ll run the risk of being perceived as a copycat, unoriginal, irrelevant, a second-class artist (all you people that have played in cover or tribute bands, you definitely know what I’m talking about!).
If we got this far, can’t be that bad.
While I understand that both in music and in software, people strive to create unique products that might even go on to become something that others copy (or at least try) — don’t hesitate to stand against the stigma of drawing inspiration, even from “close to home”, because:
Everybody “steals”, all the time.
I could go on about historic quotes and phrases coined around this (most notably Picasso’s “Good artists borrow, great artists steal.”); but from my own experience, the question of originality just isn’t unilaterally paramount — I’ve worked with bands that have written very good songs that (partially) sounded just like a different band’s songs, and when asked about it, that “originator band” couldn’t even tell the influence.
So — go on and never stop trying to be original, but if something’s good (and not a blatant rip-off), just run with it, and don’t be ashamed to pay homage to who inspired you — like I did with the title of this article, hah!
95% of people couldn’t care less about what’s under the hood.
I know, Steve Jobs’ dad famously told him:
“Paint the back of the fence, so you’ll know.”
And there’s lots of good reasoning to that.
However — I’ve both spent years and watched others over-complicate music. Especially in certain strains of music, it seems like there’s a constant contest of who can play the most notes, can play the fastest, or include the most odd time signatures, taking very elitist forms sometimes.
Here’s a “little secret”:
95% of people don’t care.
Those 95% will listen to your music because they “just like it”. They won’t be able to play along to it, they won’t be able to accurately rate the quality of musicianship — most people even mishear a lot of lyrics. You’re just wasting your energy and setting yourself up for disappointment if you use it on the wrong priorities.
So don’t obsess over technical details of your service that have no considerable impact on what the customers see and use — because that’s what they’ll judge you by. Don’t get me wrong — I’m not calling to disregard technical questions altogether. Just don’t build a highly complex system that people will end up not using because they need a simple solution — because those will always win. (Do I really need to quote e.g. the iPod, the iconic music player with reduced capabilities and a comparably high price tag?)
Simplicity is a positive attribute — some musicians (and some PMs) still need to accept that. Focus on what your audience needs — or they’ll move and listen to someone else who does so.
Don’t EVER drop the beat!
Musicians, listen up (especially guitarists). Let’s be real for one second.
I’m not trying to rate or rank anything or anyone. But — there’s one crucial responsibility that usually drummers own largely to fully.
Ever heard a guitarist mess up a bit live?
Maybe you have, maybe you haven’t. In over 95% of cases, no one in the audience will notice a guitarist messing up on stage. Sometimes, even the guitarist her-/himself won’t even notice! And usually, they’ll be able to “jump back in” — no harm done. The band continues to play.
Ever heard a drummer mess up live?
Chances are you haven’t — because if a drummer does, everything stops.
That’s why drummers are under immense pressure playing live: they can’t drop out, otherwise the entire band will grind to a halt, which means that everyone in the audience will notice — highly embarrassing, to say the least.
In product management, there usually are certain elements of your software that are absolutely crucial and critical (usually something like database & server health, core/sensitive data processing and core business processes such as being able to log in and pay in an online store), and others that are nice to have but that can malfunction for a little while without creating too much of an issue.
While this might seem obvious and self-explanatory, it most unfortunately isn’t: make securing the crucial elements of your product a priority. Even when your stakeholders are only interested in shiny new things — they’ll be the first ones on your back when your service goes down.
If you made it this far: thanks a lot for reading! I hope this was at least a bit as entertaining to read as it was to write. If you have feedback or questions, drop ’em below — also, I of course appreciate every 👏!
If you’d like to keep up with me music-wise, best would be Instagram: @bertrothen
Product-wise, I’m most active on LinkedIn. I’m a Freelance Product Manager & Consultant based in Hamburg, Germany with knowledge of various technologies & industries, and very enthusiastic about remote work and progressive organizations. If you’d be interested in booking me, please reach out via LinkedIn or email — thanks!
