Why you need to learn how to code as a Product Manager

Conversation with Jeremy Glassenberg, former platform lead at Box

Published in

Flowcap

6 min readFeb 27, 2017

In each entry in this “conversation” series I talk to a designer/product manager/engineer on a topic. I want to make basic practical skills education transparent and free.

PS: I have a new Youtube channel where I build things without code. You can check it out here — https://tinyurl.com/ycvdpoqt

We’ve talked to Jeremy before on how to incorporate user feedback for B2B and I wanted to talk to him again about this topic because he has helped several non technical people transition into product management at Box.

What’s your background and how did you get into product management?

I got in product management the more traditional way — get computer science degree and combine it with an MBA. However, that’s certainly no longer necessary. Companies like to diversify — have some PMs with the engineering/MBA path, various engineering backgrounds with no MBAs, designers, and other employees from a mix of backgrounds, who demonstrate from experience a great understanding of customer experience.

One path that works for people with non technical backgrounds is entering an intermediate role like developer relations, where you learn to communicate with customers or partners on the job and can take time to develop basic technical skills. I’ve seen several PMs who made it first into developer relations, after graduating college with liberal arts degrees.

How do you learn the technical basics if you have no technical background?

For a PM you need to learn how to communicate with engineers. You have to be respected by engineers and when they bring up an issue have the ability to understand what the issue is. You should know enough to know that you can’t provide the estimates as well. Ideally with some experience you can then start to roughly estimate and understand why it’s working the way it is. And for that you need to learn at least some basics on writing code.

I recommend Javascript for a PM. It’s very simple to learn, cheap to learn (many figure out what they need through online tutorials), and easy to learn (no need to set up a server). you can build some easy calculator apps and quickly learn what coding is. Furthermore, thanks to Node.js, you can more easily transition to trying server-side development.

After learning frontend Javascript and HTML, it’s best to understand the basics of how client to server code works, along with databases and SQL. I also recommend learning the basics of API’s, as those affect PMs on a day-to-day basis more now. From there, you’ll likely need to further improve technical chops on the job, but with the basics you should be able to learn anything else you need to learn as a PM.

I have been asked about coding schools for PMs. While companies question the value of coding schools, and whether they provide sufficient training to be a software engineering, some schools provide sufficient education to give a PM the technical skills needed. Some coding schools may be overkill, but others actually cater to PMs who aren’t looking to become software engineers.

How do you earn the respect of engineers?

There are many do’s and don’ts when working with engineers.

Among the most important to remember, you earn the respect of engineers when you can communicate well with them and understand the issues when they bring them up. Software development is not easy so have a good sense of the challenges they are facing. You have to trust them. And you have to know when to challenge them as well.

You shouldn’t have to discuss intricacies of the actual code. Engineers don’t like when PMs tell them how to code (a common challenge for PMs who are former Engineers). What you will more likely do is whiteboard with them on a conceptual level what the code is doing rather than the code itself. It’s less about how to code and more about understanding the challenges that come with it.

At Box I frequently ran into problems when integrating with partners that didn’t provide the resources we need to properly connect our services. To make the integrations work, engineering and I both dived into the API and whiteboarded different ideas, discussing how to do it architecturally.

Sometimes the PM has the wrong attitude and tells engineers what to do which you should always avoid.

What if you are looking for a Product role on a more technical product?

Product managers develop specialties over time. This can be industry specialties, such as PMs more experienced in Fintech or in Medical software. It can also be in technologies, such as mobile or APIs.

Furthermore, while Product Managers are required to have a wide range of skills, including design, business sense, communication skills, leadership skills, and technical chops, they usually meet basic requirements in all areas and stand out in one or two areas. Some PMs will focus more on UI, while others may specialize in more technical areas such as APIs.

If you are looking to manage a developer-facing product, as a PM you will need more technical knowledge.

To be a platform PM you need to know the fundamentals of API design. This requires technical knowledge, but also an understanding of other unique traits to API design over other Product areas. For example, it’s not easy to change features in an API as one could for the frontend of a website. Simple changes to an API can break important partner applications.

How do you handle tricky situations with engineers?

First of all, there should be disagreement, and there should be some push and pull. In a good agile system, engineers push on product and vice versa but the key is always to be transparent, and to respect and listen to each other.

In my experience Engineering is the least political team in any company. However, when an Engineering team is political, it can be the most dangerous. It’s easy for an Engineer to say a project will take months to complete, not because it is a difficult project but because the Engineer doesn’t want the project on roadmap — that’s usually the most common case of engineering politics I’ve encountered.

Almost always when an Engineer brings up the concern of difficulty, they’re honest. Standard agile processes help to ensure that estimates are accurate without PMs having to question whether engineers can be trusted, and without PMs trying to dictate cost estimates (which PMs never should do — Engineering is the authority on how difficult a project will be).

In sprint planning, PMs can help engineers break down large tasks into smaller tasks, as the engineering team thoroughly establishes why a project will take a while — or whether the initial estimate was higher than needed.

Disagreements can arise regarding what technology frameworks to use. Here, trust the engineer to make the right decision on stacks, frameworks and architecture. It’s fine to assist with the research and provide your own opinions on that, demonstrating technical chops but respecting their authority to make technical decisions. There’s also nothing wrong with ensuring a second opinion from another engineering colleague in the process.

Another common situation is engineers pushing for a feature freeze and refactoring the code base. Tech debt and a need to refactor is very important and needs to be taken seriously for a product roadmap. However, a feature freeze is best avoided as much as possible. Long feature freezes consistently are underestimated in how much time they actually need. Try to work with engineering to refactor in chunks and not all at once.

In conclusion the skills a PM needs are on a day to day basis are design, communication, marketing, engineering and general business. You need to be good at all of them and great at one or two of them. The secret to being successful as a PM is your ability to learn fast.

Hopefully this article has been useful for you. Please click on the heart button if you like it and leave a comment with any further questions!