Does a Product Manager Need to Be Technical?

Photo by Sean Lim on Unsplash

Over the past few years, I had a chance to work at several companies, in which I saw different types of PM when it comes to technical skills.

On one hand, I saw the non-technical PM “I don't care how you make it happen, just do”. On the other side of the scale, I saw the too-technical PM. sometimes they were an ex-software engineer who in addition to product specs also provided database table schemas.

As there are many advantages to be a technical PM, a great PM needs to balance time and mental capacity as there is only so much they can do.

This amount of time spent changes a lot between different products and different companies. For example, working on AI products requires much more technical understanding.

When it comes to a technical solution, I like to define the product manager role as the link between the business and the technical solution. In each type mentioned above, I will explain why I think this link is broken.

The None-Technical PM

In many cases, those PMs are coming from a non-technical background (Operations, sales, etc.). They have a strong understanding of the business and know very well the users. They are very familiar with the market trend and competition and know what needs to be developed and why.

As most of their attention is devoted to the outbound — they end up not spending the time needed with the solution team during design.

In cases I saw, the result of that was a patchy product.

The PM is responsible to make sure ALL the use cases are considered and understand HOW the technical solution is answering that. when it’s not done, the solution is answering ad hoc requirements that are not creating some holistic product-solution approach. every new requirement is considered and answered with patches.

For example — a PM requested the ability to add the first name of a user into a newsletter they are issuing in order to make it more personal. The simple solution was adding just the first name hard-coded into the email. PM must understand the implications of such a technical approach — what it will mean for an additional attribute such as an identification number? Perhaps different markets require localization (the first name before the last name, or the other way around), etc. In a good design process, PM together with the solution team frames the problem better.

When the PM invests most of their time on the business side — this linkage between business and solution is broken. creating products that are a nightmare to maintain and enhance, usually resulting in multiple massive investments in retrofitting.

The Too-Technical PM

This type of PM invests most of their time in the inbound work together with engineers. They understand very well the technical solution and sometimes even sets it as requirements.

with this type of PM, the following situations can occur:

1. They are not spending much on the problem so the team might be developing features that are not quite answering the users’ pain. as a result of that — products and features are developed that no one is using.
2. They are not spending enough time analyzing market trends, competition. This may lead to developing products that might answer the current problem the users are having, however, it may leave the product behind.
3. As they are very technical and sometimes even sets the solution direction, there is no room to debate the right approach and to think about an alternative approach that will be more robust and generic. In addition, it may lead to a low engagement from the engineering team as they are well fed with the solution.
4. they tend to design products that are much more complex than really needed. Not always the perfect approach is the good approach and there is a need to know when to make shortcuts. as a result of that, they are designing complex, expensive products that are hardly used in comparison to the investment.

in this case, as well, the PM is spending most of the time on one side of the equation creating a linkage break between the business and the technical solution.

So What is the Right Balance?

In my mind, the PM should be somewhere in the middle toward the technical side. here are my dos and don’ts:

Do:

1. Learn technical concepts — understand the different parts of the system, the different layers. This will help you understand the implication of a change and also the price of it. Is it a small change just in the UI? is it missing data that require change all the way to the database? is there an alternative source to get this information?
2. Attend and be active on technical solution meetings— understand the solution and try to see what you are “losing” from this approach. there are always pros and cons for every approach and there is no “right” answer. Point the requirements that are missed by the approach and this will help to lead the solution in the correct direction. Don’t be afraid to suggest a different approach if it answers the requirement better (In order to be in this place you need to understand well how your product is working)
3. When discussing the solution, be prepared with data needed such as the estimated scale of use, conventions such as loading time, etc.
4. There is no one answer — challenges the engineering team by asking “What other options we have?” there is always more than one way to go. Try to think together with the team if there is any alternative solution and you might just find a new solution that fits the requirements better.
5. Navigate the direction — sometimes the solution will seem not generic enough and sometimes it will seem too-generic trying to answer requirements that don't exist. One example can be — a PM wants to show a number of stores that are answering certain criteria. Calculating this may take a few min which has an impact on the user experience. Here, the PM needs to decide whether to create an a-sync process OR to invest in a solution that will calculate this offline and save it. Each approach has pros and cons and a different price tag.

Don't:

1. The specs should contain only the requirements and not the solution. it should talk about the problem, the why and not specs of DB tables and impacted services.
2. Try to minimize the time spend with the eng team and try to delegate things. For example, if there is a technical dependency on a different team — try to get the team leads to manage that and have you informed. Another example is debugging a bug— leave it to the engineer to figure it out. It’s not that it’s not important to do those things, but it will leave no time nor energy to do other things.
3. Don’t just decide things — the eng team is your partner. As partners, you can’t decide to go in a certain direction. Always have the team onboarded with your direction, explain why you think a certain approach is better and what data is supporting your arguments. The PM and the team are one team designing together the solution.