How Technical Should Product Managers Be?

•

The most frequent question I get is “How technical do product managers need to be?” It’s a reasonable question that, like a lot of elements of product management, doesn’t have a straightforward answer. For those with a CS background, the foundation has already been set, along with a mindset of exploration well-suited for picking up new concepts. For those starting with little to no context, technical concepts can be not only daunting in nature, but seemingly infinite in their breadth.

This article will lay out a few different ways of approaching the question.

For those of you currently in school, I recommend my article PM Major, on how to craft a “Product Management Degree” using the resources you have available in a university setting.

Why, not how

A product manager’s job is to manage the holistic process of shipping a product. That means balancing the breadth of knowledge areas and the depth required for each. When it comes to the technical decisions around your product, it’s easy to fall down a sinkhole of increasingly pedantic details, missing the forest for the trees. Knowing when you’ve received enough information to stop mining for more details is crucial, which is where the “why, not how” framework comes in.

Insofar as you need to stay up to speed with the technical changes and limitations of your product, your litmus test should be being able to explain the “why” behind any answer you give, but not necessarily the “how”. Here are some examples:

Building a basic understanding of the product. The onboarding process for a product manager will include a meeting with technical diagrams and workflows on a whiteboard. You should already understand what a “standard” structure looks like (see below), and for any elements that deviate, you should know why that is. These deviations will amount to the nuanced understanding of the product needed in order to navigate tradeoffs and decisions.

However, it’s your engineering team’s responsibility to determine how to extend and build around these nuances.

Understanding the advantages of your system. The next step of understanding the technical underpinnings of a product is to understand the advantages and disadvantages of components as they relate to product goals. A side effect is that this knowledge will typically be relevant when “tech debt” tickets are brought up — a class of ticket that has seemingly no immediate effect on the user-facing product but promises to increase some ability in the future.

As an example, migrating from one database system to another is no trivial task, will tie up resources that could otherwise be used in product development, and in the end, will seemingly only replicate the existing product experience. However, knowing that the new database has a higher degree of flexibility to change your data model would greatly simplify a major feature update you’re planning for the next quarter.

You don’t need to know how a new technology will achieve “greater flexibility”, but you should know that flexibility is ones of the axises upon which a database performs, and how that impacts your product roadmap.

Rudiments

In drumming, there is the notion of “rudiments”. A “rudiment” is a rudimentary rhythm that can be combined into longer phrases, or expanded upon to create a more complex variation of the rudiment.

This is a fitting analogy for how a product manager should approach technical concepts.

At the moment, the world of modern software development relies less on innovative breakthroughs and more on clever remixing of existing components, the “rudiments” of a modern application. By having a solid grasp on the rudiments objectively, without the noise of the surrounding application or context, you can more clearly identify and understand those components as they appear in any application.

A sticking pattern of “right left right left” will be the same in an orchestra or a jazz band. An API will serve the same purpose in a ride-sharing app or in a B2B payments processing platform. Mastering the basics is the most generally applicable skillset a product manager can develop.

Software products will also repeat the same structure. The ability to identify a structure, sketch its basic diagram, and draw blanks for engineers to fill is vital for quickly sizing up projects, and identifying unnecessary complexity.

The idea of a “product manager calling BS on engineering” is a tired one, but boiling down an overly complex system to its check pattern will expose its vestigial components.

The following is a starter list of “rudiments” for product managers to familiarize:

Learn to learn

A Google search can reveal computer science course curriculums, bootcamp curriculums, and “must know concepts” lists. While a fine starting point for those who are spinning in search of a path, grasping too tightly to these lists provides a false sense of security and completeness.

In truth, there is no limit to which technical concepts you can learn — for one, you could become an engineer and secondly, not even engineers know everything. A more sustainable approach is to develop yourself to the point where there’s no concept you’re afraid to learn.

Most developers don’t know how to do most things before they start, as evidenced by the constant desire to take on new projects, new teams, even new companies to satisfy the urge to work on new problems. But not knowing how to do something should never prevent you from figuring it out. For product managers, technical expertise is not defined by what you know, but by how you can develop what you don’t know.

Learn to learn. Start with your rudiments, your basic patterns, the structure of the product you work on, but don’t stop there. Find an double down on the techniques that work best for you, whether it’s building a project yourself, watching tutorials online, or reading articles like the ones you can find here on PM Tech Lessons.

The mark of a good product manager is not knowing all the answers, but knowing how to find them.

I hope PMTL can help you learn a few things along the way



Programming-curious?

I put together a 9-part course on algorithms designed for non-technical readers that's a great, gentle introduction to thinking like a programmer. Get the course for only $5, or download the first chapter.