A common thread around product management involves how technical a product manager should be in order to be effective. In this post 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 who have technical skills can form stronger working relationships with the software engineers. It’s easier to foster mutual understanding and respect if the PM speaks the same language as the product development team.

In the same vein, product managers that know how to code are better equipped to understand the capability and limitations of the software engineering team, and can better plan out the roadmap without under-utilizing or over-utilizing the team. Given their strong grasp of computer science fundamentals, they can foresee upcoming prioritization problems much more quickly than their non-technical counterparts can.

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.

In fact, some products are inherently technical, such as platform products, data products, or integrations products. For example, a machine learning product requires technical product management. In those cases, employers might create a job description for a Technical Product Manager (TPM), where the technical product manager is expected to have past software development experience.

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. After all, you don’t need to be a software developer to know how to work in an agile fashion. Similarly, you can still set a product vision, identify a product strategy, and craft a product roadmap even though you don’t know how to code yourself.

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. A non-technical PM will continue to drive the business requirements and will continue to focus on customer needs, regardless of technical difficulty. Furthermore, they can focus much more on the customer experience, rather than being bound to what technology has currently been implemented.

On top of that, non-technical PMs generally perform better with cross-functional teams, including go-to-market teams such as product marketing. They’re more likely to work better with the business side of the organization, since they’ll be less worried about technical specifications and will be more focused on deliverables and objectives.

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.

Closing Thoughts

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.

 

---

Interested in discussing this topic with other product managers who may or may not have technical backgrounds? Meet and chat with product managers from all different backgrounds in our global Product Manager HQ Community.