How To Become A Technically Literate Product Manager
I don’t have a technical background. I took the minimum math level classes in college to fulfill general ed requirements and graduated with a degree in political science. Ten years later, I call myself a technical product manager not because I commit code (I rarely do), but because I can advocate for users in technical conversations. It’s about understanding the implicit tradeoffs for users that come with technical decisions.
There is no “I’ve made it” milestone in this effort. It’s like learning a foreign language. Over time, the more you learn, the more you realize how much we subconsciously tune out what we don’t understand. Conversations around you gradually turn from being white noise to words, then phrases, then sentences, then richer sentences. The benefits don’t pay off in a “Eureka!” moment, it will be in subtle improvements in your product decisions and relationships with team members.
Here are the practical, somewhat sequential, steps a PM can take to become technical in a practical way. It roughly mimics my journey and demonstrates it can be done in tandem with your day job.
1. Start with the basics
Learn the basics of the platform you work on. If you work on products on the web, start with free courses in HTML, CSS, Javascript, and one back-end language — likely what your current employer’s tech stack uses (I still have a soft spot for PHP).
I started with Codecademy, but I have also used and love Khan Academy and Lynda.
2. Build a personal website
Your first chance to put your skills to use in a real, low-stakes environment is a personal site. Build something practical, like a website for your resumé where you can continuously update a portfolio.
There are lots of options to host it. I like Github, Heroku, WordPress, and DigitalOcean.
3. Show interest in the technical aspects of your projects at work
This is the semester abroad part of your journey. There will be a culture shock, you will be humbled by how little you know despite how much effort you’ve already put in, and it will feel daunting. Push through.
Develop trust with the engineers on your team by demonstrating curiosity in the technical details of what they are currently working on. I was lucky enough to work on an incredibly supportive team that was patient and appreciated my desire to learn. When appropriate, ask follow up questions. If you’re sitting in on technical meetings, wait until after to ask questions so you don’t derail meetings where key decisions need to be made. Listen even when it sounds like gibberish and eventually it won’t.
4. Make small contributions
There is nothing quite so tedious to do as a PM as creating a Jira ticket for something like, “Confirm button on email newsletter unsubscribe page should be primary color (is black)”.
In situations like this, it’s the perfect place to start putting your skills to use in, again, a low-stakes environment. Open PRs, not Jira tickets. After I got my local dev environment set up, when I ran across bugs like these — small CSS fixes, minor broken client-side JS, pulling the churn rate for the newsletter team with a SQL query — I wrote up these non-urgent tickets, added them to the backlog, and opened PRs for them in my spare time.
Don’t take on any time-sensitive tickets, no matter how small. I guarantee you will underestimate how long it will take to fix. Also, don’t be afraid to ask for direction. At this point, you’re probably pals with at least one developer on the team.
Over time, you’ll develop a sense for how to take on bigger and bigger tickets (if you want).
5. Apply this curiosity everywhere
There are a lot of technical components to a product that you can learn that don’t require coding. Thinking about integrating a new service? Learn how to make a REST API call to that service when the team is exploring this option. Your feature is not being tracked correctly? Learn to debug analytics events in your console. These skills will build credibility with your team and are transferable wherever you go.
I’ve met a certain type of person who could read mid-century literature in a foreign language, but couldn’t carry on a conversation because they got stuck in a loop trying to expand their vocabulary rather than put it to practical use. Similarly, it can be easy to go down a technical rabbit hole. The counterintuitive trend of learning technical skills is that as you move up in your organization, the less time you should have to do things like code. Make sure you keep using these skills to advocate for your users and build empathy between you and your technical teammates. Don’t miss the forest for the trees.
