Why Product Managers Should Learn to Code "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 5 May 2017 True Code, Coding, Marketing, Product Management Role, Skills, Team Leadership, Mind the Product Mind the Product Ltd 1263 Product Management 5.052
· 6 minute read

Why Product Managers Should Learn to Code

Building products is amazing. You take an idea – sometimes big, sometimes small – and with your team you make it real. Or at least you make a version of it come to life and then send it out into the world.

Every day I find this creatively inspiring. To craft a product from scratch brings a range of feelings; from joy and pleasure to frustration and despair. Whether a quickly drawn sketch, an MVP, physical product, iterative improvements or a brand new feature, all studiously validated with user research and customer development, you roll up your sleeves to make it happen. It is a magical, continuous, learning experience.

I’m now on the fault line between users and technology. I’ve had all sorts of job titles;  digital marketer, growth hacker, creative technologist, UXer, startup product person, product strategist, product owner, lean coach and consultant. I’ve been a startup founder – when I completely tanked my first foray building product.

All of these roles have involved building products and telling people about new products and features they might be interested in. Over time I’ve become more technically literate as my projects began to require more technical work.

A Sense of Frustration

However I’ve struggled with the nagging thought that I should learn to code. As a non-coder deep in product and marketing, I’ve found it increasingly frustrating that I must stand by while I could see that my teams could do with more help. It felt uncomfortable and disempowering. From both a personal and professional perspective I wanted to be more productive, understand the development process better, improve sprint effectiveness and get further under the skin of all that goes along with building and growing products.

At present I’m freelancing, working in product, UX and marketing roles. I tend to work with startups, though I have also been involved with more established companies – roles where research, UX and marketing considerations really have an impact on what is built. Almost everything I work on involves technical people or working with digital products, and both product roles and marketing ones are becoming ever more technical. A functional knowledge of how tech works and how to build it is not only helpful but is becoming critical.

I’m seeing it more and more – in job specs, interviews, among my peer group – where technical understanding is becoming an expected skill. Not all members of a product team need to be a hardcore coder, but when everyone has a firm foundation of how all the pieces fit together and function, I firmly believe that it helps.

Learning the Language

We’ve all seen how putting users’ voices closer to the design and development improves product and experience outcomes. In the same way I’m starting to see how raising a team’s technical baseline has a positive impact on product development roadmaps and implementations. A rising tide raises all ships.

I have tried to learn to code a few times, but just teaching myself or taking a few short courses, I couldn’t make it stick. I would try to learn the language that was being used in my projects, which in hindsight was too scatter-gun an approach, applied inconsistently. Still, I had an ever-growing curiosity to overcome this invisible barrier, even though it continued to feel frustratingly elusive.

I sort-of understood coding, but I wouldn’t have been be able to sit down and create a digital product or feature. Like knowing the universe is really, really big but not grasping the absolute scale. It was turning into a worry that I just wouldn’t overcome it, or have the time to invest properly in it. A puzzle that I couldn’t quite slot all the pieces into place. Not something I am comfortable having hanging over me.

Eventually I decided to go on a SuperHi course. It’s a startup that teaches designers, product people and marketers to code both online and in small classes in London and New York. I enrolled on a course last year and I can now jump into a code editor and bring an idea to life. I’m now starting to contribute more in my projects beyond product development, UX and marketing. In fact the experience of learning to code with SuperHi has been so positive for me that I now help them out occasionally with ad campaigns and product feedback.

While no one will pay me to code (yet), it’s the start of a journey that’s already reaping personal satisfaction, and all the while I’m having fun bringing silly side projects to life. Self-side note: must stop buying domain names!

In case you wonder, my first instinct is still to draw on the wall, rather than in code, though maybe that will change in time, with practice.

Once you can Code, Practice is key

It now feels like the training wheels have been taken off. I now don’t feel afraid of coding, and I’m confident that I can hack something together. I try to code at least once a week as practice is key – to try out new things and keep learning, increasing in confidence by breaking things and figuring out how to fix them.

It’s interesting to think about where the line is between design, product and marketing these days. We all know that marketing can’t sell shoddy products and create delighted users. It’s like taking water uphill in a bucket full of holes. Maybe we’ll all come to see it as strange that some marketers could build products without deep knowledge of the customer and how they use a product. In a similar way, perhaps we’ll also ultimately find it bizarre that we could all be part of teams building digital products without an understanding of how to code.

For me, learning to code was important, even if I wasn’t always completely sure how I was going to apply it. It doesn’t necessarily matter how deep you go. It now feels foundational from both a work and a life perspective.To me the ability to code is like being fluent in another language – incredibly useful for communicating with a wider group of people than you’d otherwise be able to engage with and one of those hard skills that widens your horizons.

A Skill set for the Future

We’re all gradually becoming less silo-ed and more cross-skilled in teams and companies. And if you factor in the way that automation is increasing in our daily lives you can see that these trends will only accelerate in the next 10 years. I think that in the future our most important “soft” skill will be developing our ability to learn and adapt: as one thing becomes obsolete it’s a natural reflex for you to move on – building more skills as you go – with the minimum of personal disruption possible. It doesn’t matter whether you work in startups or for large organisations, keeping up to date means you spread out from your core expertise. Industries change all the time so it’s important to keep pushing yourself forward. As they say: if it feels uncomfortable, you’re probably exactly where you need to be. Keep going.

I’d love to hear your thoughts about this and if you’re on your own journey of learning, discovery and transformation. Has coding been something you’ve wanted to do or have struggled to get to grips with and do you have any tips?

Comments 13

It’s great to hear you want to learn to code. I was a developer for 8 years and the skills I learnt helps me tremendously. The other domains I learnt through learning, observation and reading are UX, Business, Sales, Marketing etc.

Technical skills are not easily achieved. So through a course is great. It’ll teach you about coding. But I would also pair up with a developer, see them making your idea into reality. There is more than coding. There is design, architecture, tests, code quality, compiling code, deployment, security, releasing and operations as other parts of the technical domain. You don’t need to be an expert, but have empathy with the development team.

Even though I agree with the article, I have to call BS and plain advertising on SuperHi, as it has just started the lectures – when did you even manage to complete the course?

Hi George. Ha! I assure you I took the course last October. Before they built out the online syllabus they ran 2 years of in-person sessions in London and New York in the same 8 week format as the online classes. They were on my radar for a while but only managed to find the time then. You’re correct that the online classes started in February, & have been running two cohorts a month since. BS free zone, scouts honour 😉

Strongly disagree… IMO product managers need to *know* enough about coding and devt in general to thoughtfully represent their dev teams, sniff out unrealistic estimates, represent customers well, sort dumb from smart ideas, empathize like crazy with their organization… but the moment you write *actual* production code for your product, you’re part of the development team. Responsible for maint and bugs and test creation. Necessary in the office for code reviews of adjacent things that may break yours and vice versa. Emotionally wedded to whichever tech you chose, resistant to change. So I applaud your study and learning and ability to code, as long as you leave code development to those hired for such.

[Of course, all of that falls to pieces at a 2-8 person startup where everyone does a bit of everything…]

Ps – I’m not advocating that PMs tinker in backend production environments that could have cascade effects. I’ve found it depends on the context of the project and size of the team (same with how deep a PM might go on design). For me it’s more about effective understanding of the whole project/product and how in a PM role you can get further under the skin of what is being produced & how decisions made impact it. When appropriate quick fixes to things that would be low priority dev/roadmap wise but of significance from a UX or marketing standpoint can be good to get crossed off without distraction from bigger technical elements

I take your point, but have seen more than a PM fall down the rabbit hole of doing lowpri, small, non-distracting, low impact devt work. IMO, production code is just that, and needs rigorous design/review/testing/maint. Quick fixes are usually the ones that ultimately cost the most time and rework.
Reversing the story, imagine your dev team wants to write (and then develop against) user stories that you’re not very interested in, but that they deem worthy and want they to save you from the distraction of knowing about…
110% agree that knowing how to code makes you a much better PM on many kinds of products, plus earns you respect of your team.

Yeah, that would be somewhat problematic, though if they had validated user stories to contribute they’d already be in the backlog or up for discussion soon.

Of course, it is a matter of knowing your limitations, if you create more work than problems you solve you should have probably been self aware enough not to start with it (quick fix or otherwise).

As I mentioned in earlier feedback on this post, below: “Think we’re pretty close as I’m mainly advocating being more technical generally. For big complex projects absolutely it would be an alarm bell to be needing to support with code, for smaller projects the context can be different.” Really appreciate the feedback, Rich – thanks 🙂

As a marketer with some coding knowledge, I can definitely relate to your article. For a marketer or a product manager, a lack of technical understanding leads to the same effects as the lack of non-technical vision for a developer: unnecessary bottlenecks and communication issues that can easily be avoided. Both parties should be able to understand the basic gist of each other’s side of business and speak the same language.

Thanks, Andy. Yeah I agree. For me de-mystifying coding (as well as other adjacencies inc design) has really been an “aha” point. Plus some of the most inspiring coders I know are also great product & design heads too – we work together better when we have cross-skill empathy, IMHO. TY for your thoughts. 🙂

Really Disagree.

The simple reason is that a product manager that is coding is a product manager that is spending time NOT being the voice of the customer.

Should you understand the principles of developing software? yeah. Pragmatic used to say that a product manager that self-describes themselves as “non-technical” is a great way to reduce your salary by $10k. So, PM’s do need to be technical, but only to the point of gaining trust in the development team they’re working with.

Would I learn something in my “spare” time? Sure, and I have.

Actually code on a project I’m working on, for a company that’s paying me to be a product manager? Never.

If a team is at a point where a product manager actually has to write code, there’s a problem with budgeting or prioritizing.

Hi Dolsh. TY for your thoughts. Think we’re pretty close as I’m mainly advocating being more technical generally. For me it’s more about effective understanding of the whole project/product design and development and how in a PM role you can get further under the skin of what is being produced & how decisions made impact it.

For big complex projects absolutely it would be an alarm bell to be needing to support with code, for smaller projects the context can be different.

Join the community

Sign up for free to share your thoughts

About the author