Why every Product Manager should learn how to code
“Managing engineers is like herding cats“ — If you are a product manager in the tech world, you’ve probably heard this sentence before. I’ve dropped this phrase myself here and there and non-tech people as well as engineers around me would smile faintly and nod in knowing consent. In the last three months however, I’ve come to understand that this is only half the truth. To grasp the entire beautifully complex reality of cross-functional teams we need to add (or rather admit) another element to the equation: “For an engineer, working with (product) managers is like drawing a picture for a blind person.“
I’m a product manager myself. By the end of 2015, I had co-founded my own startup and failed with it, had built a network to support women in the tech and startup scene in Germany and worked for Podio in Denmark as a Product Manager. I love my job and I’m quite successful at it. But in fall 2015 I decided to change perspectives: I took what you could call a “code-sabbatical“ and enrolled in Bloc’s online coding bootcamp — 3 months, 8–10 hours of coding per day, 3 personal mentor sessions per week.
To cut straight to the point: I never planned to change careers and become a full-time developer. But still, it was probably the best investment I could have made in my career as a product manager. And I would go even further and say, it’s not necessary to have a CS degree to become a product manager (PM) but a program like Bloc or anything similar should be part of every product manager’s journey.
In my experience, it reveals the problem-solvers behind the “cats“ and turns “blind managers“ into translators and bridge builders…
Bonjour. Guten Tag. Hello World. — Language is more than words and grammar
When I started working on my first project in JavaScript I approached it basically as every feature I’ve every build: I analyzed the user flow, defined the different UI elements, decided that this “can’t be that difficult“, opened my editor … and was completely lost.
Every little piece that I thought would be a clear, not-so-difficult function, which I just had to translate from my written story into JavaScript syntax, seemed to open Pandora’s box: edge cases, helper functions, global variables, bindings, dependencies to consider etc… I was fascinated by the level of granularity that was required to make a simple “Play” button update a song-list!
It was not only the amount of code required to perform such a “rather simple“ task that got me thinking. The way a problem needs to be broken down into executable pieces is different for a programmer than it is for a PM. And while you might say, it’s not necessary that the PM knows how the problem is broken down in code as long as the common goal is clear, in my experience this is exactly where misunderstandings and misaligned expectations emerge.
Every language, no matter if it’s a human or computer language, requires an implicit mental model that forms out of syntax, grammar, experience and convention. What we say and — even more important — what we don’t say but mean, is defined by this mental model. And so the first thing I realized when I tried to think like a programmer was not the right solution to my code problems, but I finally started seeing where our mental models had diverged.
I don’t have to “speak“ (or write) this or that computer language fluently to support my engineers with better user stories, concepts or explanations. But it’s crucial that I continue learning to understand their mental model and be aware of the gaps and blind spots that appear in the process even though the final goal seems clear.
Refactoring. Complexity. Testing — Or: A PM’s nightmare
Yes, I’ll admit it: I was one of these product managers that had to fight really hard not to roll their eyes when — as it felt for me — every time I came up with a new story, it was either “veeery complex“ or required a large refactoring and would take at least a week more in order to secure test coverage. My dear engineers: I’m sorry!
After I had finished my first little music player in vanilla JavaScript my task was to refactor the entire thing into the AngluarJS framework to provide more structure and potentially scale the functionality of the app. Given that I had written all the code myself, I assumed that this would be fairly easy since I knew exactly how the code worked. Well, unfortunately that wasn’t quite the case. As soon as I started to pull something out on one side all the connected pieces would stop working. All the hacks I had made to “just get it working“ became evident or even worse, where so well hidden that it took me days to figure out why these two parts would just not talk to each other. And this was only my little educational project and therefore nothing compared to the code base of a full-fledged app in production.
Of course, you can call me naive now or you might say that I didn’t have enough trust in my engineers before. But to be honest, the problem for me was not a lack of trust or that I wasn’t willing to listen when someone explained why this is a complex topic or that refactoring was necessary. The problem was without doing it myself, I struggled to understand how it feels to deal with such a complex structure and with the consequences and risks involved.
Don’t get me wrong. I’m not saying every suggested refactoring or “let’s write it from scratch“-proposal is justified. And I’m still convinced that tech-projects and their prioritization need to be discussed in the entire team (including non-tech team members) and not only among engineers or technical managers.
But I also feel, that in order to have a qualified discussion with my teams and support them in making the right decisions, going forward it will help me not only to listen to the facts involved but also to know what it means for your day-to-day working experience when you have to deal with reduced productivity, uncertainty and pressure due to tech debt or a bad infrastructure.
(And as a side note: I hate writing unit tests.)
The beauty of code — Why appreciation matters
Do you know what the most frustrating part of my bootcamp was? I showed my code, that I’ve worked so hard for, to my friends and family and they only saw … well, code. Then I showed them the UI of the projects, how they could click here and make an update there. And although they tried hard not to show it, the message hidden under their friendly encouragement was always: “Ok, but … that’s all?“.
I don’t blame them. The projects I’ve build were certainly not cutting-edge technology or had a fascinating UI since that was never the intention behind them. But it was hard for people without a coding background to appreciate the incredible steep learning curve I’ve experienced: I had started with a bit of HTML and CSS knowledge in October and finished the program three months later writing a hybrid (mobile and web) app from scratch with Meteor, React JS, Mongo DB and Mocha unit tests.
As a PM I was always a bit surprised how even in cross-functional teams silos between dev and non-dev groups could emerge. And many companies hire product managers in the first place as a desperate attempt to get out of a situation where the engineering teams are more or less “doing their thing“ which no one else really seems to understand.
You might want to boil it down to the question: Why is “writing beautiful code“ so important since the user will never see that code anyways?
The answer is easy: Because we all seek appreciation for our achievements.
The best software — as the best design — will always be the one that effortlessly recedes into the background and “just works“. But in order to get there thousands of small, unseen improvements need to be made that collectively create a better product. Do they matter? Absolutely! But if we focus only on the visible output or the one we (as non-tech people) understand, it’s not a surprise that engineers will build a parallel structure of recognition and reward among their peers that easily turns into a silo.
For me as a PM, learning to code is therefore also a question of showing respect for the challenges and achievements of my team members.
The “deliberate“ choice for a non-tech PM
This text is already much longer than I intended it to be and still so many insights and experiences I gained are missing. However, I want to make a final comment about being a product manager without a technical background.
I often hear people talk about how they got their job because their company deliberately decided to hire a “non-tech“ PM. I don’t have a CS degree and you can even call me a “late bloomer“ in the tech scene, so I guess I qualify for that description quite well. And as I said in the beginning, I don’t think that’s by any means a disadvantage or a problem. Being a good PM means (among many other things) being able to see aspects and options others can’t because of their expert perspective on things. It means providing inspiration and input beyond the realms of a specific job title. And it means being able to provide leadership for a team whenever the team needs it.
None of this requires a CS degree. However all of it requires a deep understanding of the product, every step in the process and most importantly the people involved.
In my opinion, management — and product management is no exception here — provides no value in itself. We don’t produce anything. We don’t sell anything. So the most important part of our job is to find a way to provide value for the people we work with. And what’s valuable is not our decision. Value is defined by the people receiving it: engineers, designers, testers, users, marketing, sales, leadership etc.
So, if you ask me, why it is necessary that even a non-tech PM understands the fundamental principles of programming and the reality of working as a developer, I can only answer: Once you get a feeling for what it means to sit in front of a bug for days, feel the frustration that derives from a seemingly impossible requirement and the pride when you found a great solution, you gained a new insight about how you can provide value for your engineering team. And that is worth the investment. At least for me.
