Month: February 2021

I am often asked whether an engineering background is necessary to be a successful PM. The short answer is “No, it is not necessary”. Some of the strongest PMs I have worked with and learned from did not have engineering backgrounds. Indeed, a technical background can even be a disadvantage in several ways that I will talk about later in this post.

Growing up, I always thought I would be a software engineer. I first learned to program computers in the BASIC programming language on a ZX Sinclair Spectrum +3. In middle school and high school, I learned C++ and assembly language because I developed a love for high performance graphics programming. For the first few years of my career, I was a software engineer working on operating systems and cloud computing platforms. I loved my job, but felt that there were many aspects of the business that I didn’t understand. I figured that business school would be a good way to expand my perspective. During bschool, I interned in strategy consulting and venture capital. Unfortunately, those career paths did not resonate with me. I wanted to be in a role in which I could drive the vision & strategy for a tech company. I realized that product management is the discipline at many technology companies that is responsible for the vision and strategy. After business school, I was lucky to get a job at Google as a PM. Given my background as a deeply technical engineer, I figured this would be an easy transition. After all, engineers do all the “real” work right?

How wrong I was! While my technical skills were certainly an asset during my first few years as a PM, they took a backseat later in my career. In some cases, my technical skills even became a hindrance to my growth. I had to consciously and intentionally work hard to break through mental blocks that were a consequence of my engineering background but were holding me back in my PM career.

Ways in which an engineering background can help

There are certainly roles and situations in which an engineering background can help a PM. Some of these are listed below.

1. Roles in very technical areas. A very small set of roles may benefit from PMs with in-depth technical expertise. My first PM gig was to build “Virtual Reality Mode” in Android N. This required me to work closely with Google’s Android team, deeply understand high performance graphics rendering, low level operating system features, and so on. I was able to hit the ground running and deliver successful outcomes, despite being an inexperienced PM because I knew the space very well. My background as a former OS engineer and a computer graphics geek since childhood made up for my lack of PM chops.
   
2. Build credibility with engineering. PMs with technical backgrounds may find it easier to rapidly build rapport and credibility with their engineering counterparts. I’ve benefited from this in a number of roles. At the same time, this can be a double edged sword as I’ll discuss below.
   
3. Engineering skillsets transfer. I’ve found that the structured and logical thinking skills of software engineering transfers well to product management (and to management consulting, as it turns out). Designing a compact data structure, writing tight performant code, or sketching out the architecture for a large software or hardware system utilizes similar cognitive skills as developing a succinct, logical, and well-structured product thesis or a MECE business strategy analysis.
   
4. Ambitious but achievable technical goals. Technical PMs can often push engineering teams just the right amount beyond what the eng team thinks is “possible”. This is because the technical PM understands the engineering stack just as well as the engineering team, but is able to “pop up the stack” and reason from first principles because they are not as close to the code. This also has a flip side discussed below.

Ways in which an engineering background can hurt

That said, I’ve also hit speed bumps and mental blocks as a result of being a technical PM. Some of these are listed below but this is by no means exhaustive.

1. The pseudo-engineer. The easiest trap to fall into is a temptation to become a “pseudo-engineer”. A technical PM working in a technical area can find it difficult to add unique and differentiated value to the team. Instead of thinking about product strategy, user needs, and use cases, you start thinking about technical features and solutions. During my early years as a PM, I was working closely and productively with an engineering manager, let’s call him “John”. In one performance review, I got feedback that I was at risk of becoming a “John Lite”. The engineering manager brings a certain set of skills to an organization. If the Product Manager is bringing a subset of those same skills, then the PM is not doing their job. The PM should complement the engineering manager, not be the “Lite” version of the engineering manager.
   
2. Self-censoring. Some technical PMs are unable to exercise #4 above, and self-censor or agree to all the constraints given by the engineering team. I’ve fallen into this trap as well. A great PM can and should push their engineering teams to achieve goals beyond what the engineers believe to be possible. This is how teams accomplish great things. However, because I have a deep understanding of operating systems and computer graphics, I’ve sometimes fallen into the same trap as my engineering teams, censored my own crazy and far out ideas, and not pushed for sufficiently ambitious goals.
   
3. PMs need to have product and strategic credibility. This is the flip side of #2 in the pros list. A great engineering leader should hold their PM accountable for thinking deeply about the strategy, user needs, and use cases, not for the PM’s technical chops. Sure, it might be fun to chat about the new features in C++20 or debate the pros and cons of microkernels, but those are not the value add of the PM.
   
4. Overly enamored by the tech. Finally, in my personal experience, PMs without technical backgrounds can be better at empathizing with the user and building creative solutions. One of the strongest PMs I have ever worked with was in the music industry prior to becoming a PM. This person repeatedly built amazing and magical consumer software products that appealed to mainstream users. Whereas I would get enamored by the tech, this person kept their eye on the value and delight they must deliver to the user.

If you’re an engineer thinking about switching into product, watch out for the traps I described above. If you’re a PM without an engineering background, remember that you have skills and mental models that may not come as naturally to your technical PM peers. Hope this helps both categories of product managers!

I’ve written before about how data, frameworks, and intuition can help make product decisions. In this post I will drill down into how frameworks are one of the most powerful tools in your product management toolkit.

According to Wikipedia, “A conceptual framework is an analytical tool with several variations and contexts. It can be applied in different categories of work where an overall picture is needed. It is used to make conceptual distinctions and organize ideas. Strong conceptual frameworks capture something real and do this in a way that is easy to remember and apply.”

Frameworks are useful in two distinct ways. First, they can help you cut through ambiguity and bring clarity to a problem. Second, they can help you communicate a complex product problem in a simple and digestible way.

Most interesting product problems have high degrees of ambiguity and complexity. There might be many degrees of design freedom and the potential solution space can quickly become overwhelming. If you imagine the design problem as a multidimensional space, you need to carve up that space in a way that helps you make sense of the problem. How do you do this?

One approach is to think through the major levers on which the design problem hinges. It is unlikely that every dimension in your design space is equally important. If you can identify the major levers, then the next step is to bifurcate the space along those levers, kind of like running the binary space partition algorithm on your design space. In two-dimensions, this often looks like the classical 2×2 grid.

Another approach is to think through the criteria that your product solution must meet. Keep the number of criteria to a “minimum spanning set”. The minimum spanning set is the smallest number of criteria that your solution must meet to be viable. If you can remove a criteria and your solution does not change, then you are not at the minimum spanning set. If you add a criteria and your solution swings to a wildly different answer, you are probably missing a major dimension.

A third approach is to use negative space. I’ve written before about explicitly laying out the assumptions, goals, and non-goals in your business writing. Negative space is similar to the non-goals. Think about problems that you are explicitly not attempting to solve. What is out-of-scope? By carving out the out-of-scope clutter, the in-scope solution might stand out more clearly.

A fourth approach is to hold some dimensions constant. This is particularly important when your problem space is multi-dimensional. Humans cannot visualize 4D or higher dimensions. One way to make such problems tractable is to hold one or more dimensions constant and analyze the problem space in that lower dimensional plane. For example, a three dimensional problem space could be analyzed by starting with a planar “slice”. The slice is a simpler problem to tackle. Once you’ve cracked the problem on the planar slice, it will be easier to generalize the solution to the original 3D space.

I consider the four suggestions above as examples of “meta-frameworks”. They are tools to help you develop your own frameworks, specific to the domain in which you work. You will notice that I have not provided frameworks that I use in my own work here. This is because canned frameworks obtained from someone else are usually not very effective. Every domain is unique and while some frameworks can and should apply across domains, the skill to develop is “framework-driven thinking”. I’d encourage you to develop your own frameworks to analyze the product problems you are tackling. Practice structured communication of complex problems using on-the-fly frameworks. As you build this skill, you will start to naturally think and communicate in more structured, logical, and effective ways.