/ Product Management

How Technical Should Product Managers Be?

One of the most frequently asked questions from those aspiring to enter the product management field is: how technical do I need to be if I want to be a PM? PMs build and manage technical products. To do so, they interact with software engineers and data scientists on a daily basis. However, PMs are not hired to write code or conduct data science work. It is important to be able to strike this balance in a team and be a good partner to those you work closely with. In this article, we will explore how technical a good product manager should be.

Do I Need to Be Able to Code?

The role of a product manager is to lead the direction and strategy of the product. This means communicating the user's pain points and clarifying requirements to software engineers. Certainly, PMs are not expected to write any of the code that is to be shipped. That's what software engineers do. However, a basic understanding of how technologies interact can help PMs better perform their duties like sizing and prioritization.

Product managers clarify requirements and provide insights to market trends. They talk to users to understand their pain points, and work with the team to outline how those pain points can be addressed. If you do not have a technical background but have experience in the space where the product competes, you can add value by providing those specific market insights. For example, someone with a working background in the radio or music industry might make a good PM at Spotify. Or, a market researcher at Marriott International could bring valuable insights and be a good product manager at Airbnb. Folks with strong and educated opinions about the product space can help guide the team in times of uncertainty.

When it comes to performing duties like sizing and prioritization, it can be helpful to understand how certain technologies work. This can be difficult for those without a technical background to handle, especially when working with products that are technical by nature. Oftentimes these technical products, such as platforms, have intended users who are very technical people. A PM working to ship a data lake repository must understand databases, security, and how the cloud works. Day to day, these PMs will encounter topics that require prior technical knowledge to understand. While PMs do not write the code for the product, they are expected to maintain proficiency with the technology in order to engage in meaningful discussions with engineering.

Being a Good Partner to Engineers

To effectively prioritize and explain why the team is pursuing certain decisions and features, it can be helpful to have an understanding of the main technical concepts surrounding the product. This understanding will help the PM build a relationship with engineering. Requirements and requests will be perceived as coming from a place of understanding with engineering. After all when you have a list of changes you'd like made to a website, it can be difficult to properly make estimations if you do not understand the difference between CSS and CMS.

The best way a PM can get started on being a good partner to engineers is to simply talk to them more and ask a ton of questions! When some concept is unclear and an internet search does not yield any good explanations, chat with an engineer. Understand why certain technical trade offs exist. Understand what concepts like front-end, back-end, API, git, and pull request mean. By clarifying the day-to-day jargon, a PM can gradually become more well-versed in engineering discussions. If possible, find a good friend on the engineering team -- someone you are close to whom you're not afraid to ask what you may perceive to be dumb questions.

These chats with engineers do not need to be limited to the happenings of the current sprint. A good PM understands the new, exciting, and trending technologies relevant to their product. These can be discovered through a variety of mediums: internet articles, podcasts, and even Twitter thought leaders in the space. As an example, PMs who work in the data management space can keep up with technology trends by listening to the Data Engineering Podcast. However, it can sometimes be difficult to weed out the meaningful emerging technologies from the ones that are just flashy. Here, it can be helpful to propose the new emerging libraries, frameworks, and technologies that caught your attention to the engineering team. Then, you can learn why some will work and some will not.

It also helps to be more familiar with the product. For web products, try using the "inspect element" tool to move components around in the UI. If you don't like something about the user interface, try making some edits to the CSS. Experiment with changing and deleting some properties. The basics of web development (HTML, CSS, and JavaScript) are both simple and cheap to learn. The PM does not need to code and in no way should the PM tell the engineer how to code. But after having some understanding of the technology, then the PM can whiteboard and brainstorm with an engineer to understand challenges and discuss trade-offs, helping the PM better partner with their development counterparts.

For web products, try using the "inspect element" tool to move components around in the UI

For more technical products like cloud computing or data analytics platforms, learn to use the product as a user would. Provision your own instance. See what it's like to go through a basic use case. Then try an intermediate level use case. When the nature of the product (such as cloud computing, platforms, or APIs) is geared towards developers, then it may be more useful to understand more advanced concepts like software architecture. You can learn about concepts like MVC architecture, load balancers, and caching strategies in Exponent's TPM course. Go through the bug reporting tool and inspect the most commonly reported issues. Then as you go through the product as a user would, you can try to predict future problems around scale, maintainability, and architectural design. Ideally, you will get to a point where even if you have a non-technical background, you will have enough hands on experience with the technical product that you can give a meaningful demo to a customer.

Making Data-Driven Decisions

Product managers make many decisions every day. While some of these decisions can be made intuitively, how will you know if a button really should be red or blue? What will you say if stakeholders push back on your decision because they think their intuition is incorrect? Good product managers are able to discover, analyze, and present data to back up their opinions or to form new decisions and recommendations.

Product managers are not required to know Python or R to the level that data scientists and engineers know. Product managers are not responsible for building ETL pipelines or coming up with new ML algorithms. Instead, PMs are to handle the application of data analysis. Roles and responsibilities vary from company to company, especially for more nascent teams where responsibilities overlap more and folks wear more hats. But in general, data engineers handle the collection and organization of data. Data scientists handle the analysis of data. Then, product managers handle the application of these analyses.

Data is like oil. It is valuable, but only when it is cleaned and refined. Data engineers take the plethora of raw and unstructured data and shape it so that it is ready for analysis. Data must be taken from storage, transformed, and cleansed. This can be achieved by managing data infrastructure, building and refining data pipelines, and leveraging parallel computing to handle the velocity of data. This helps ensure that the flow of data is reliable and clear of any anomalies. They also design and develop systems and tools to enable others in the company to consume the data.

Data scientists then turn this refined data into analysis. These analyses help the company make business decisions using data. They can help the company learn more about user behavior. Changes in product metrics can determine if the product is successful. A/B tests can help the company make decisions. The result of the analysis performed by data scientists can all help make decisions at the product level.

On some teams, if there are additional resources or if the role is one more specialized in research, data scientists may experiment with artificial intelligence or machine learning to answer product questions. They can drive the collection of new data or use statistical techniques to develop new insights.

All in all, good product managers work with their counterparts on the data team to intuitively extract insights to make data-driven decisions.

Being a Good Partner to Data Scientists

Product managers work cross functionally with data teams. More and more companies are becoming heavily data-driven, and value making decisions based on data. To do so, PMs must work with their counterparts on the data team to run the right analysis and conduct meaningful experiments.

While data scientists bring the data and analysis to the table, PMs should be there to help brainstorm what else the team can unlock with the data. What happens when we separate the users by different demographics? What cohorts can we group them by? With this analysis, PMs can also forecast and set goals. They work with data scientists to design new experiments.

One of the most popular experiments PMs run are A/B tests (also known as split tests). A/B tests remove the guesswork and biases humans have when it comes to making decisions. By conducting A/B tests, you test some hypothesis with a subset of your users to see how you can improve a business opportunity like conversion.

You do not need to have the statistical depth of a data scientist to understand and interpret A/B tests. However, you should know the basics to be able to call the right winner for experiments you run. There must be a sufficient sample size to be representative of your customers. The winner from the test needs to be a consistent winner. If your winning experiment is fluctuating between two or more choices, you will need more data, as this indicates you have a low statistical confidence so no matter how long you run the experiment, you will have winners that continue to change.

Some folks like to run experiments for 2 weeks to take into account 2 business cycles and weekends of data, but this can vary based on your business cycle. You also want to get differentiated data. If you do nothing to your product, there will be natural variations and fluctuations to your data. A differentiated result means your lift is above (or below) that natural variance. If you have good data that is sufficient, consistent, and differentiated, then you can be confident that this winner will persist.

Here are some quick statistics definitions product managers should know:

  • Control - the current, original version of your product (the base against which all your test results are compared)
  • Variant - the modified version of your product that you want to test against your control
  • Population - all of the potential visitors to your product
  • Sample - a subset of the population
  • Random sample - a subset of the population in which each member has an equal probability to be chosen (this is done to prevent biased representation of a demographic)
  • Representative sample - a sample that to gives you an idea of the population, usually done by ensuring the sample is a large enough size
  • Lift - the increase or decrease in a metric of the variant when compared to the control
  • Statistical significance - likelihood of seeing the same results if you run the same test again
  • P-Value - probability of a result being a winner (lower is better; this is the inverse of the confidence. A P-Value of 0.05 means you have 95% confidence)
  • Confidence interval - range of expected outcomes (smaller is better since this will give you more certainty of what to expect)

The PM Interview

Now that you understand how technical product managers should be, your next question is likely "How technical is the PM interview"?

The PM interview process can vary from being more design focused to having technical components, depending on the company. You can explore some of Exponent's Interview Guides to get an idea of the type of questions companies ask. In these guides, we explore the various backgrounds that companies like Google, Microsoft, and Amazon look for. It is also explained here what you can expect in the interview stages, what the hiring decision comprises, and any tips and strategies you can employ in your interview process.

You will notice that many companies have a bias towards PMs coming from a technical background. But you do not have to have a technical background. Many PMs with non-technical backgrounds thrive. As mentioned, you should be a good partner to developers and data teams. It is more important to prove that you can successfully lead the team to ship meaningful features and products.

Always speak to your recruiter to get a sense as to what to expect in the interviews. If you have an engineering round and you are concerned about the technical depth needed for the interview, your recruiter should be able to clarify and set the right expectations. More often than not, you will not be asked to code. However, especially for TPM and PM roles for more technical products (like platforms and APIs) you should be familiar with high-level system design and tradeoffs for the popular data structures and algorithms (including time and space complexity). Solutions you propose should be scalable, reliable, and efficient.

For more in-depth PM interview preparation help, check out the product management interview course. You can also learn about concepts like MVC architecture, load balancers, and caching strategies in Exponent's TPM course.

Closing Thoughts

Non-technical product managers bring many ideas and values to the table. Some have deep expertise in the product space. Others have an eye for design and sense for user experience. While there are many great non-technical product managers, those with a technical background can more easily form strong relationships with software engineers and data scientists.

While you do not need to start off with having a technical background, there are several ways to acquire more familiarity with the technology and become more data-drive. Ask lots of questions to engineers when there are concepts you're unfamiliar with. Chat to learn and understand the tradeoffs and limitations of technologies. Find a buddy on the engineering team -- someone you can ask what you may think are "dumb questions." Web development (HTML, CSS, JavaScript) is also simple and cheap to learn, offering many non-technical product managers a relatively easy way to become more technical. When it comes to becoming more data-driven, a general understanding of statistics is helpful. Work with your counterparts on the data team to learn what analysis they have done. Learn how to call a winner in experiments and work with data scientists to design future tests. Then, you may effectively work across engineering and data teams to turn development and analysis into data-driven business decisions.

Ace your Product Management Interview