How Product Managers Should Understand a Technical Product

How Much Do I Need to Understand?

There’s no clear cut answer here. It’ll depend, both on the project and on you. You need to make sure you understand enough to do the job the team needs from you.

When talking with engineering, you should understand enough to be able to make decisions. You won’t need to develop the system diagram, but you will be asked for your opinions on system designs. You'll have to translate the technical implications into what actually matters to the product and your stakeholders.

When talking to other teams, you may be asked if your team can support specific features. Sometimes you won’t know, but you should be able to answer basic questions. Larger technical decisions and deeper explorations should be handled by the engineers. You can bring your TL or an engineer into a meeting with you if needed.

Some ways to figure out what you need:

• Ask your counterpart what’s most important for you to know.
• Keep track of concepts or systems that come up a lot.
• Ask your PM peers or the PM you backfilled (if you have access to them).

Common Technical Components

While this may not be universally applicable, here is a list of questions by each "component" that your team likely operates with, to start understanding the technical parts of your product.

Core System Design

• What’s the key system here?
• What does the system diagram look like? How does information flow through it?
• Why does it work the way it does? What are some benefits of it? What are the current constraints or downsides?

Dev & Launch Processes

• What does it take from the engineering side to take a project from someone’s machine, to internal beta, to experiment, to launch?
• Are there engineering gates, e.g., for quality, performance, or stability?
• Are there external dependencies, e.g., feature cuts, app updates, or hardware launches? Your timelines will need to account for these and you’ll often need to work with them.

Critical Infrastructure

• What infrastructure does your technology depend on? You may need to submit feature requests to these teams. Understanding the relevant infrastructure will make it easier for you to communicate a request and it will help you build rapport with that team.
• If relevant, what teams are you the critical infrastructure for? You may not need to understand them deeply, but you may need to prioritize their requests and figure out the best way to help them.

History

• Why were things built the way they were? What key decisions would be made differently in hindsight?
• Who are the historic partners of the team within the company? Does the team rely on other teams?
• What have been the engineering VP / CTO's main goals with the technology? How does this team fit into the larger goals for the company?

How Do I Get Up to Speed?

• Read through the docs. Ideally, your team should have a Get Started guide for engineers detailing critical systems. If not, take notes as you learn and eventually work with some of the engineers to put one together.
• Sit down with engineers to get a run through and ask whatever questions you have. In the early days asking dumb questions is not just ok, it’s expected. You can even ask multiple people the same question–then see if you can follow along with their answer.
• Ask for docs on recent projects that have been done. The product and technical docs for these projects should still be fairly up to date. Reading through them can help you understand how your systems are being used, how they can be changed, and what kinds of considerations you’ll need to make with your own projects.
• (Optional) - try shipping a fix for a very small, low priority bug. It could be something as simple as a single word change. This builds credibility with the engineering team, shows your immediate value, and is a great way to understand how engineers are building code.