and how this will make you a better PM….
Quite often Product Managers are considered ‘jack of all trades’, we can adapt to a wide range of situations and know a little bit about quite a few different topics.
It’s not surprising that when I talk to other PMs, we often don’t understand much of the underlying tech that we are jointly responsible for. We work with a lot of smart engineers that we can trust to build products in the right way, but it sometimes feels like we put up a wall to create a very clear distinction between cross-disciplinary responsibilities.
Why do we do this?!
I believe that one of the reasons is because Tech can be really hard. If like a lot of PMs, you don’t have a tech background, this can be overwhelming and quite scary. It can leave you feeling like you are an imposter in the team amongst a bunch of highly skilled engineers. So we turn to the things we know and can do well; discovery, opportunity sizing, stakeholder engagement etc because this is where we find comfort and know we can add value.
Recently I had the opportunity to take an online Frontend development course designed to get participants writing code and building websites within a few hours. All I can say is: what a revelation.
This short course really opened up my eyes and I’m now firmly of the opinion that every PM should spend some time learning how to write some code and here’s why.
Building team empathy
As a PM, I don’t usually see the code that powers my product, I simply see the output. I don’t see everything that goes into making it do the things I want, in the style and level of prettiness I want.
There have been times I have been frustrated with the speed of feature improvements, I think to myself how hard could it really be to move that here, make it red, or do that specific thing?
Learning to code really helped me appreciate how some ‘simple’ tasks can be awfully deceptive and lead you down a never ending rabbit hole of needles and haystacks. When I started with CSS, the fake website I was creating only had 200 lines of code and it was already becoming quite difficult to understand what bits of code was supposed to do what and why it wasn’t doing what I expected.
Now imagine a well established website like FT.com which is made up of multiple code repositories and has many many dependencies. What looks like it should be a one line change could snowball into something much bigger.
This has given me a fresh perspective and a new found respect for my engineering colleagues. I can now empathise much more with the challenges and problems they might have, particularly if I have the urge to say ‘it’s just a small change, how hard can it be?’
Be a better communicator
One of our jobs as a PM is to liaise between Engineers and Stakeholders. A little bit of technical understanding can help us better communicate with both groups and ultimately build better shared understanding and help reach better outcomes.
My colleague Jen Johnson wrote an article to help non developers understand some of the regularly used terms. I’ve read it more times than I’d care to admit, and learning to code really helped put this into practice. Creating your own repository on Github, changing a file, making commits and submitting PRs really helped make this terminology sink in.
I’m a firm believer that PMs with a little bit of tech knowledge, and engineers with a little bit of product knowledge can achieve great(er) things together.
Typically a PM will shape the product roadmap and prioritise upcoming feature requests and wait for the outcome, with Delivery leads shepherding along the way. To me, it often would look a bit like:
Learning to code won’t solve all of that, and to be clear, you definitely don’t need to know how it all works. You work with a lot of smart and competent people, give them the autonomy to decide on the HOW whilst you focus on the WHAT and WHY. However, by building a foundation of technical knowledge, you can better help communicate the challenges of your customers and vice versa to achieve better outcomes and solutions for all.
Often in the PM world, our work doesn’t have a yes or no answer. We can spend time analysing the impact of the work we did, collect user feedback, analyse more data — and still have to deal with ambiguity. However when writing code, it either works or it doesn’t work, it looks and does the thing you expected it to, or it didn’t (even if you have no idea how you did it).
Creating something is rewarding and seeing something come to life that you’ve physically created is cool. Whether that’s an online portfolio, an app, blogs and or just something to experiment with. Creating something you can actually play with gives you a nice sense of achievement and is a great learning opportunity.
What and how?
The course I took was designed to get you writing basic HTML and CSS on a live website within a mere few hours, which makes it highly accessible and gets you really engaged with the course content.
Codecademy, freeCodeCamp, Frontend Masters, Udemy, loads of places all have a variety of courses available with both free and paid for versions. If you have access to your organization’s Github account you might be able to look at some of your team’s Pull Requests to try and understand how the products you are working with come together.
Lastly, make friends with your engineering colleagues, most would be happy to help give you pointers/feedback and tips. They are the pros at the end of the day.
As a PM, you certainly don’t need to learn to code, but it’s another skill in your pocket, another string to your bow to help you lead with more confidence and create better outcomes for your team and ultimately your customers. Why not give it a go?