How to balance tech, product, and industry learning as a PM
I recently contributed to an ongoing series called Ask Women in Product by answering this question: “How do you balance keeping up with knowledge about Product Management with deeper technical knowledge?” Below is my answer in full.
Always be learning
As product leaders, we have to always be learning. During the interview for my current role at IFTTT, one of the engineers highlighted the company values printed on the office wall and told me that I epitomized one of those values: “Always Learning.” He didn’t know it at the time, but he pretty much sold me on the job. Curiosity is vital for product thinking. And being at a place where that’s not only encouraged, but actively sought after, is incredibly exciting.
The question I was asked to answer for Women in Product is how to balance staying current with both technical and product management best practices. While deciding what to learn can be tricky, I believe you can find that balance by dividing your learning effort between three things:
- Understand the tech behind your product
- Develop product management skills and thinking
- Become an expert in the industry served by your product
The best way to balance these learning areas is to think about what you need to learn and how it pertains to your daily work, so you can invest your time wisely.
Understand the tech behind your product
Most product managers worry about not having enough or the right type of technical knowledge for their product role. Some female PMs struggle with imposter syndrome when starting a new product role even if they ultimately end up being great at it. But it’s usually not very productive to try to gain a lot of technical skills just for the sake of having them, even for a particularly technical vertical.
In general, it’s a good idea to teach yourself to code (in any language!). Take the time to build something to get a sense of what engineers do. Pick an interesting side project that solves a need you have, rather than writing code for the purpose of developing a technical background.
Beyond that, the best way to gain relevant technical understanding is to talk with your engineers about the technology stack and identify gaps in your knowledge to read up on. You want to identify engineers who are good at explaining both specific concepts and the general architecture. They may start by describing the stack at a pretty high level. Over time, you want to ask questions to get a full understanding of what languages and frameworks the company uses and why. You want to understand where there’s technical debt and how it relates to future product initiatives — particularly in terms of performance, security, and implementation complexity — so you can make room for solutions that will be more robust over time. For me, this is an ongoing process as part of my role and not something that I set aside time for specifically.
You should feel confident in your technical grasp when you can think through new product initiatives, anticipate implementation issues, and comfortably brainstorm technical solutions with the engineers.
You should feel confident in your technical grasp when you can think through new product initiatives, anticipate implementation issues, and comfortably brainstorm technical solutions with the engineers. Engineers want you to provide product direction, ask good questions, and be a thought partner in how to design solutions and prioritize work for maximum product impact. In other words, they want you to help them figure out the right thing to build, but not tell them how to build it or review their code.
There are also related technical skills that PMs need to develop to understand what users need. For example, you want to understand and influence what data you collect about how users interact with the product. Depending on the data framework that your company uses, this may mean learning SQL (or a proprietary language like SPL for Splunk).
You also want to learn to use tools that effectively communicate product initiatives through flowcharts, wireframes, and mockups. To avoid disrupting how the team operates, learn the tools that they already use rather than bringing in new tools. Remember that there’s just one of you and many of them, so any time they spend trying to figure out how to leave a comment on your wireframe is a waste of time for the team.
Develop product management skills and thinking
While you can gain technical understanding organically in a product role, the same can’t be said of PM skills. You definitely want to set aside time to develop product skills and analyze related products to advance your product thinking. These skills are what you uniquely bring to the team. If you work at a company with many PMs, you may occasionally share product practices across the PM org, but PM techniques are generally not something that you will pick up from the team members you work with most closely every day. For me, this type of learning usually happens on weekends or other time off.
I usually tackle topics from my to-learn list that are most applicable to what I’m working on right now, then immediately apply what I’ve learned.
I find it helpful to keep a to-learn list. I usually tackle topics from that list that are most applicable to what I’m working on right now, then immediately apply what I’ve learned. This approach helps me to think critically about what I read and adapt it to my work in a way that makes sense for my particular product and team.
My list contains blog posts, talks, and books. Sometimes, it’s good to sit down with a book and a notebook, far from internet distractions and wikiholes. Some of my favorite PM books that I keep returning to during these sessions are Product Leadership and Product Management in Practice for product skills and Hooked for product thinking.
A huge bonus point of keeping a to-learn list is the satisfaction of ticking off items when you finish reading about them. Though in reality, you’re never done learning. 🤓
Become an expert in the industry served by your product
The third type of learning that you need to invest time in as a PM is building up domain expertise. In fact, this is the most important learning area. If you’re a PM for a self-driving car, you should spend most of your time learning about the auto industry and not C++ or how to use Aha!
If you’re a PM for a self-driving car, you should spend most of your time learning about the auto industry and not C++ or how to use Aha!
With the exception of the banking sector, hiring managers tend to deprioritize domain expertise when hiring PMs. This means most PMs have to develop their knowledge of the industry on the job. Personally, I’ve always been excited to get the opportunity to learn a completely new domain, so I’ve worked on very diverse products almost by design.
I’ve usually gained an understanding of the specific industry through three different activities:
- Market research. While reading about relevant market trends is super interesting, it’s the task that’s least connected to a PM’s regular work. Market research is something you need to consciously make time for as it’s imperative for developing the right product.
- Customer or user interviews. Interviews with customers or users provide a much deeper understanding of the problems you’re solving. Keep in mind, though, that there may be parts of the problem that users don’t have good insight into or aren’t able to articulate. To paraphrase the often misattributed Ford adage, users may ask for a faster horse when what they really need is a self-driving car.
- User data analysis. An analysis of user interviews and user interaction data helps build up domain expertise that can’t be learned elsewhere. In fact, you’re most likely to uncover critical insights about user needs from analyzing how users interact with your product. So although these tasks should really be part of a PM’s day-to-day work, it’s important to make room for this type of learning as it’s easy to get sucked into doing other work, particularly at a smaller company.
Finally, learn and unlearn
Reid Hoffman did an excellent interview of Barry Diller for his Masters of Scale podcast where he said:
“To move from one success to another, you have to learn to unlearn. Take everything that helped you win the first time, then discard it and learn a new way.”
That episode really struck a chord with me. As a PM, you constantly have to learn new things and sometimes that means having to set aside techniques that helped you achieve success in the past so you can use a better approach. You need to be comfortable leading under a lot of ambiguity and learning as you go.
It also means that the learning never ends. There’s no such thing as a perfected Product Manager. While that notion may be daunting for some, I love that aspect of our profession because it means there’s always something new waiting on the horizon.
I hope the tactics above help you find a balance in your learning and would love to hear any thoughts you have on my learning approach.
This article was originally published in the May 7, 2018 edition of Ask Women in Product. Huge thanks to Sarah Swanke for editing this piece.
