Do you need to be technically savvy to be a great Startup Product Manager?

"Should I improve my technical knowledge?" is a common question for many product managers or PM wannabes. And there are two major camps: people who believe that a PM should only focus on communication, strategy, cross-functional cooperation skills, and other people who say that technical knowledge is necessary to create superior products and better relationships with engineering teams.

My short answer is YES; you need technical skills, but not for the reasons above. You will be surprised by the arguments I present. First, you will learn a unique framework that helps you envision what can fit as technical skills in the PM world. Then, you can adapt the framework to suit your needs and circumstances, allowing you to create better products and work smoothly with your teams.

There are types and levels of technical knowledge.

When PMs discuss technical knowledge, it can mean many different things. For example, some technical knowledge is related to how mobile and web apps are architectured; others are related to specific domain knowledge such as money transfer regulations. Companies such as Google will prefer to hire Computer Scientists to work as Product Managers due to algorithms, optimizations, and other CS skills. Some other companies will treat technical knowledge as nice to have. Instead, they want people with superior knowledge and experience in specific industries to develop valuable customer insights and strategies. Based on these examples, you can conclude there is no common ground about what technical skills are supposed to mean.

Furthermore, some jobs will ask for technical knowledge when looking at job descriptions, while others don't. The lack of uniformity in what companies ask for muddles what technical skills mean in the Product Management job market. It is impossible to improve on something that you don't know what is supposed to be.

I created the following framework that helps us map and categorize the many different technical skills required from a Product Manager. In addition, the framework encompasses all other variations of technical skills by breaking them into two significant characteristics by Type and Level.

Types of Technical Skills:

• Technology and processes
• This type refers to the application of scientific methods into practical applications
• Domain-Specific knowledge and experience

Levels of Technical Skills:

• Superficial Level
• Operational Level
• Architectural Level

There are two main types of technical knowledge. The first one is about the application of science into processes and practical uses. For instance, applying quantum physics allows us to shrink computer processors. Understanding organic chemistry enables us to create new materials and medicines. Science, technology, engineering, and mathematics (STEM) subjects are technical skills of the first type.

No less critical than STEM subjects, Domain-Specific knowledge and experience are related to arts, relationships, laws and regulations, psychology, history, politics, and they are usually grouped into liberal-arts subjects. Great painters, such as Monet, Edward Hoppers, Vincent van Gogh, and many more, use experience, subjectivity, and practice to perfect their "technical knowledge." In the Fintech industry, entrepreneurs and product managers need to understand or work with people who can navigate the intricacies of the banking and finance regulations to avoid being shut down. Even though there are books, courses, and even established rules about how things should work, Domain-Specific knowledge requires experience, creativity, and surrounding context to be enabled.

Once you have categorized the type of technical skill, you will have to define how deep you need to understand the subject. Three levels represent the levels of understanding, and they depend on what function you do in your role as a Product Manager.

The first level is the Superficial level, and it's defined by asking if you can answer the What and Why of that subject. For example, superficial knowledge of Cryptocurrency is about what it is and why people, companies, and governments are interested in it. That level allows you to have a conversation and proceed to learn more about it.

The second level is the Operational level, and it's defined not only by What, Why but also the How. Continuing the cryptocurrency example, you reach the operational level if you have traded a crypto coin, created an account, lost/gained money or the wallet, etc. You experienced the subject, and you know what is out there with the current state of the art. As a PM, you can create copycat UX for crypto products, but there is a challenge to develop an innovative solution; that gap is the difference between the second to the third level of knowledge level.

The final one is the Architectural level. A person with the third level of technical skill can replicate what is out there and risk creating alternatives and pushing the limit of that technical skill. Interestingly, most of the problems those people try to solve are scalability problems.

The architectural level requires understanding the subject's impact at the individual level to the grand scale and predicting second or third order of thinking. Examples could range from creating a microscope that can see an atom, decrease the cost of transportation by 50%, decrease the usage of energy to mint Bitcoins, etc. A closing example is how to plant a tree is a type of local-level impact, but to build a forest, for instance, you cannot grow the same kind of tree because that can inhibit shrubs and other plants; that's the second-order thinking level.

The lack of clarity of what technical skill is supposed to mean in the Product Management community is not helpful. Using the framework that defines the technical skill into types and levels helps you understand what you need to know and learn. With that baseline, we can have a better conversation about technical skills and improve ourselves as product managers.

Your startup resources will define the type, level, and scope of your technical knowledge.

It may not be evident at first, but the scrappier a company is, the more hats and technical knowledge is required from a startup Product Manager versus a PM in a FAANG company. Another thing that the community discusses a lot, it's the fact that a Product Manager may have to make a trade-off of working for a FAANG or big company with a narrow scope of work in exchange for money and prestige versus working for a startup where you have control of the strategy to development. Still, you may end up in a failed venture. That's precisely where the context and the needs of your personal and company situation will define what is needed from the technical knowledge.

First, you have to understand your career goals and your personal needs. There is nothing wrong with aspiring to have prestige and money, but that will set how much effort you should pursue the type and level of technical knowledge.

Second, the job description and the company's needs will determine what you need to look after. There is a quick way to sort this out:

If you are working for a big corporation:

• The higher your seniority, the more focus is on your technical knowledge for Domain-Specific knowledge; the focus will be on soft skills such as human relationship management, product management process, team building, budgeting, and strategy
• The level required is the architectural level.
• The bigger is your team; the narrower is your scope of work; probably more focused on STEM type of technical knowledge.
• If there are many other PMs in the same team, the level required is operational.
• If the unit is small or you are the solo PM from the group, then the level necessary could be the architectural level since you will be the only one holding the project together.
  

If you are working for a startup (not the "big" unicorns - they are big corporations):

• You may be required to have both types of technical knowledge.
• Usually, you need to have it at the operational level or above for both types.

When you compare the vast resources of a corporation with 100K employees versus a startup with 10, it looks obvious how much technical knowledge you will need—working for a big company where you have subject expert matters to consult looks to be an advantage and can also hinder experimentations. The lack of resources in a startup pushes people to explore alternatives; that's when the innovation happens, but there is a high probability of something not working as expected.

Last but not least, the culture of a company determines how much you need to know. It's not about the size but the preferences of the collective. In cultures where technical knowledge is encouraged and praised, the PMs will be incentivized to further their technical knowledge. To the other extreme, organizations that care more about the results but not the how, PMs will have fewer incentives to pursue technical knowledge; instead, they will outsource that to their colleagues and consultants.

Check the pros and cons of having technical knowledge.

Having technical in absolute terms is a substantial competitive advantage in your career; however, it can bring unwanted things too.

Pros of having technical knowledge:

• Ability to create competitive products.
• Ability to troubleshoot issues and problems.
• Being respected by peers.
• Easiness in absorbing new information and technology.

Cons of having technical knowledge:

• Overthinking and having anxiety for problem-solving.
• Difficulty in delegating the search for answers.
• Lack of recognition due to the muddiness of wearing multiple hats.
• Assuming that you have the correct answer.

Technical knowledge can unlock unique opportunities. It can bridge your next career move. So regardless of the work required, all points to the benefits of having more technical knowledge, but it's important to know what kind of technical knowledge to pursue and not for anything at all cost.

To conclude, it's essential to have technical knowledge. Even if the market does not have a common understanding of what that means, we can still apply the framework above to define it. With knowledge, you can focus on what matters to you and your company's needs so you can build great products.

I hope the framework presented here can serve your journey in becoming a better startup product manager!