Do Product Managers Need a Technical Background?
A common thread around product management involves how technical a product manager should be in order to be effective. In this article, we’ll describe the two viewpoints to this age-old question and cover steps you can take to develop your technical foundation.
Argument 1: Product Managers Need a Technical Background
The most common thread I see among people who share this viewpoint surprisingly centers around the team itself. The argument is that product managers that are technical can form stronger working relationships with the software engineers. There’s a mutual understanding and respect that’s easier to foster if the PM speaks the same language as the engineers.
In the same vein, product managers that know how to code are better equipped to understand the capability and limitations of the engineering team, and can better plan out requirements without under-utilizing or over-utilizing the team.
Many people are also in agreement that if the product serves a technical purpose, then the PM should definitely have technical knowledge. This makes a lot of sense because if the PM isn’t aware of the requirements, then that ends up jeopardizing the quality of the end product.
Argument 2: Product Managers Don’t Need a Technical Background
Many people in this school of thought argue that PMs don’t need a technical background because their job is to come up with the best possible product for the end user and not worry about how that is implemented. Every moment spent micromanaging the implementation is less time for the PM to listen to the user’s needs.
PMs without technical backgrounds can still learn the essentials on the job. Since they work with the Technology team, it’s entirely feasible that PMs can acquire a solid understanding of the architecture, technology, and team velocity.
Another reason is that PMs who don’t have a technical background aren’t limited by what they think is technically possible. For example, a technical PM may ignore a requirement because she thinks it’s not possible given the time constraints. However, a non-technical PM won’t run into that problem, and the benefit is that it could lead to something entirely innovative or provide a challenge for the engineers to address.
What You Can Do Without A Technical Background
Even if you don’t have a technical background, there are still many things you can do to “get technical” and build respect with your teams.
Take steps towards developing a technical foundation
As a product manager, you should aspire towards being able to:
- Ballpark estimate how long it would take to complete a feature (or have enough technical understanding to have a proper conversation with a direct stakeholder i.e. an engineer or engineering manager around how long it will take)
- Trace through product flows to understand fundamental user issues
- Understand the logic behind potential solutions for any technical problems that arise
- Map out areas of your product that will be affected by those proposed technical solutions (along with any associated challenges)
Timeline Estimation: Whenever a non-technical PM new to the industry asks what they should do about feature timeline estimation, I always mention that a lot of it comes down to pattern-recognition over time. As you work longer with your dev / design teams, you’ll start to understand patterns like: who works quickly, who doesn’t, who tends to overestimate their own timelines, who writes code quickly but needs extra code reviews due to frequent bugs, etc…
In the beginning of any project, you should always strive to communicate with any direct stakeholders involved to understand what they are thinking. Don’t play the hero who tries to estimate for the entire team; you may not have the full context around technical limitations / challenges that might arise during the development process. At the end of the project, you should aim to do a reflection around how accurate your estimates were. If they were wildly off, seek to understand what happened and incorporate that data into your estimations going forward.
Logic: Understanding the logic behind technical issues does not mean you need to diagnose and implement the exact solutions yourself. The first step you might want to take is understanding / mapping out all user flows in your product so that you can more easily trace any user issues to the underlying problems. Mapping out these flows creates a “mind maze” in your head so that you will also more readily be able to identify components of your product that might be affected whenever new features / solutions are proposed.
Remember, as a PM, you’re going to have to help triage a lot of potential issues. The last thing you want to do is become a useless middleman who just takes bugs and assigns them to an engineer without being able to diagnose what might be happening. That is a guaranteed way to lose respect from your engineering teams.
You want to aim to never to say “I don’t know” but rather, “Okay, we don’t know the exact fix here but we do know that A issue happened and logically, we can trace this back to B or C.” Developing the logic to identify root problems and potential fixes will save your teams time and earn their respect.
Develop Technical Curiosity: This last piece is arguably the most important part of developing a technical foundation because it requires an inherent drive towards learning more about technical subjects. We talk about this in our article around the top 5 steps you should take when ramping up as a new product manager, but whenever you get a chance (without being disruptive), you should aim to sit down with an engineer (or a few) to understand your product’s technology stack.
Going forward with any ongoing projects, you should aim to set aside time to speak with your engineers around implementation details so that you have the context around trade-offs that may arise or edge cases that you might not have thought about.
One thing that I always recommend all non-technical and technical PMs to pick up is a working knowledge of SQL. Figure out where your product’s data is stored and get a sense of how the product logs are structured. This way, if you need to pull some data points to run your own analyses, you can simply use SQL commands to query and pull down the data yourself rather than waste your engineer’s time.
Another thing you might want to do is start getting familiar with bits of the code base. For example, if you are checking the ID of a split test your team is running, you can simply access the code base yourself and search for the test. Anything you can do yourself to save your engineering team’s time and let them focus on their work will definitely be appreciated.
At the end of the day there is no single correct answer. It depends a lot on the company, product, and team, and each company can stress different qualities for the ideal PM.
The most important takeaway is that as a PM, your job is to come up with the best possible end product for your user. Whether that requires you to be a bit more involved in the development process or more involved gaining additional insight into customer behavior, the product has to be delivered, and it has to be amazing for your users.
—
Note: This article originally appeared on Product Manager HQ.
Kevin Lee is the founder of Product Manager HQ and was formerly in product roles at AltSchool and Kabam. He has been the author/co-author of 10+ gaming patents. He has taught product management classes in San Francisco and Berkeley. Outside of work, he cares deeply about education and has served on the Board of Directors of Raising a Reader Bay Area and the San Francisco Creative Arts Charter School.
