Being technical enough as a product manager
“If you’re not technical, why did you apply for a product management job?”
The question was asked with the same seriousness—and the same friendliness—you would expect from people in Silicon Valley, and of course it made sense. Thanks to the interviewer’s credibility, it was the kind of question that in the first five minutes of an interview might get me thrown out. But does a product manager need technical knowledge? What does being technical enough as a product manager mean?
By convention, most product manager job postings say they should have at least a computer science bachelor’s degree or experience delivering a related project. There are exceptions, but technical experience is important.
Recently companies have started changing product manager requirements to “the product manager must be technical enough,” for example:
- Be fluent enough in technical topics to ask engineers technical questions.
- Strong public relations and the ability to manage technical conversations.
- Have acquired deep analytical skills. A computer science degree or programming experience is ideal, or a love of data and analysis.
Although I look at this a bit one-sidedly, I believe this change is a positive one and only increases demand and awareness of those demands. Product management is both an art and a science. It is psychology and it is statistics-based, and while it needs a big-picture view, it also does not skip the smallest details. Day-to-day responsibilities and technological progress differ by industry and company size. Meanwhile, the qualitative traits that turn people into admired product managers rarely relate to an individual’s technical experience.
But the question remains: what does being technical enough as a product manager mean? How do we get to that “enough”? And at the same time, how do we earn credibility with our team members?
When I moved from the marketing team to the product management team three months ago, I found how little there is about this topic on the internet. I want to share my experience of trying to find answers to these questions while I was spinning through my first 90 days as a product manager at Pinterest.
The rest of this article is split into two parts:
- Explaining technical understanding and investing more in it over time
- Building confidence and credibility by understanding how you can create value quickly
To understand technical issues, build a technical background for yourself and then spend time
First, what does “being technical enough as a product manager” mean? There are different views, but I think it means the ability to do the following, ordered by difficulty:
- Trace a user problem (or a set of problems) back to the starting point of the problem.
- Estimate how long it will take to build product A versus product B.
- Anticipate implementation challenges and their reasonable proposed solutions.
- Run brainstorms to solve technical problems.
- Identify opportunities that come from advances in technology.
The relative importance of these criteria will differ depending on your product. For a consumer application it may be more important than keeping up with new technology, for example, while B2B companies need to pay more attention to project scope and progress in order to hit planned goals. It is reasonable to expect a product manager to keep all of these in view.
Now that we have a basic understanding of product management, the next question is how to become a product manager with technical understanding. Some of the steps I find useful, roughly ordered by importance:
Start with curiosity
This is the one item on this list you must do. Of course too much curiosity about technical problems can lengthen your path, but without it nothing can begin. Curiosity can be cultivated to some degree, but in interviews I try to pay more attention to the other person’s points.
Use engineers’ creativity!
Following the previous paragraph, you do not need to go deep into engineering science to know that engineering is building something from nothing. You can see that simply by watching engineers work. At the same time, engineering comes with all the subtleties that are part of any mental process. Behind every attempt to create a feature there is an engineer who runs dozens of calculations, examines subtle attributes, and thinks through the details. Not understanding this deprives engineers of the autonomy and ownership they need to do their best work.
Start early to find an engineering way of thinking
Read everything you can get in the first few days, keep a list of questions, and go to a real engineer with a whiteboard so you can find answers. Ask your technical questions intelligently and grow a basic understanding of engineering; make sure this does not pull you away from your actual job or go on too long. You can learn things even by staring at a screen, let alone by investing your time. To get to being technical enough as a product manager you need to spend a little time.
Make everything you have learned shareable with others
At this stage you are probably swimming in a sea of acronyms, diagrams, and terms. Keep all this new information by writing it in a document. Give this document to other people you hire; they can add to it or remove things from it. Even better, find a chance to present the information to another team—for example, present a new search to your partners. This is a great way to test your understanding and highlight areas you still need to go deeper on.
Use feedback and bug reports to match patterns across issues
Back to our definition of what “technical enough” means: the first criterion is that you can trace a set of user problems back to the root problem. One way to do that is to match patterns in feedback and bug reports.
As a product manager you have the privilege of being first to respond to product feedback. On any given day you may file several reports about things that are confusing or broken. A colleague interrupts your reporting: “When I put a comma in my search I get no suggestions.” Then your mother emails that she was searching for “Williams-Sonoma” and because of the same hyphen or comma found nothing.
If you can trace the issue, two things happen over time:
- You pick up the vocabulary engineers use to talk about specific bugs.
- You start linking issues together as symptoms of a problem with the same roots.
So the reports from your colleague and your mother get collected as: “Full orthographic normalization logic is not working.” Through this process you will also build a relative understanding and priority of different topics.
Get familiar with basic coding concepts
No need to worry; the goal is to be able to answer simple questions such as where and how a particular variable is defined, without bothering an engineer.
Focus on core concepts
In every domain there is a set of concepts that come up again and again—for example, recall versus precision in search, the importance of efficiency in data modeling, and so on. Identify them so that in computer science in general and in your product domain they sit in your learning priorities.
Grow a thick skin!
Cunningham’s Law says, “The best way to get the right answer on the internet is not to ask a question; it’s to post the wrong answer.” In many ways this is a fitting metaphor for the product manager role—your job is to look at an initial spec or a ridiculous Google Drawing that everyone else then picks apart. That is only the beginning.
Build credibility by understanding how you can add immediate value
Learning any new skill takes time, but when it happens on the job you do not have the option of being a full-time student. You have to identify the points where you can have an immediate impact and start contributing while the work ramps up. Hopefully this will not be too hard, because part of why you were hired in the first place is complementary skills in these areas. Things to consider:
Think deeply in the data
There is an idea that every function has a superpower; the evidence is that when used, it makes other people want to work with you. For designers, that might be the ability to quickly produce a wide range of high-level explorations. For engineers, it might be the ability to create a prototype quickly, but also knowing when to invest in clean, extensible code.
For product managers, I think the closest equivalent is mastery of data. Every time someone asks, “Do we know how many people use feature ABC?” and you can say “Yes, about 123 people,” you gain credibility. That is probably why product analyst roles have become one of the most important roles in product management.
In practical terms, mastery means knowing:
- What front-end or back-end information is logged
- Where this data is stored
- How to query the data
- How to analyze and test this data
What is your experience of having technical knowledge as a product manager? How necessary do you consider technical knowledge? How technical enough should a product manager be?
Author: Lulu Cheng
Source: Medium