There seems to be a strong bias in many large companies toward assessing a product manager’s ability to perform based as much (if not more) on their technical ability, background, and knowledge as their real-world, market, and user experience. To me, this is an entirely backward way of approaching the problem, as the entire purpose of having a strong product manager is not to provide an additional technical resource to determine the “how”, but to provide a strong and knowledgeable resource that can accurately describe the “what” and the “why” of the problems that your product should be solving.
This means that someone who brings a lot of knowledge and ability to the table, but who lacks certain “check the box” background skills in the technical realm may be at a disadvantage. Here are some tips and tricks that someone coming from a non-technical background can use to excel as a Product Manager in nearly any company.
Know Exactly What You Bring to the Table
The biggest issue that most non-technical PMs face is the fact that they can’t confidently and accurately describe to others the value that they do bring to the table. It’s almost a certainty that you will start any PM role with skepticism on the part of the engineering and test teams with regard to who you are and what you do, but being able to clearly articulate the value that you do bring to the role, and how you plan to use that value, to communicate that value, and to leverage that value is essential to putting your best foot forward. Obviously, you have to do this with a little bit of humor and a lot of humility, but you still need the people you work with to understand the reason you got the job and how your non-technical skills are going to help them and the product to succeed. Most technical teams need someone with deep market insight and user knowledge in order to help them properly prioritize their efforts — they may not admit it, but this is what the non-technical PM brings most clearly to the table. Own it.
Don’t “Fake It Until You Make It”
I’ve seen some non-technical people make the mistake of taking a “fake it until you make it” approach, trying to hide the fact that they aren’t strongly technical by doing some quick studies and searches online to come up with words, technologies, and approaches that they think sound good and are at least tangentially related to the business that they’re in. Engineers see through this charade faster than you can say “MySQL”. Just don’t do it — there may be a time and a place to take a chance on looking like you know more than you do, but all this does in this context is to accentuate your lack of technical ability, and undercuts your ability to establish trust…
Establish Trusted Relationships
…which is really the cornerstone of any Product Manager’s success. The only way that any Product Manager can be successful is by building relationships based on mutual trust and respect. You need to know that you can count on your technical team to fill in the gaps of your own knowledge, and that they will listen to you when it comes to the gaps in their knowledge related to the market and the end users’ needs. All relationships are give-and-take, and the non-technical PM has to accept this and work within the confines of their knowledge and ability, demonstrating sufficient deference to the technical team that they don’t feel like they’re being “pushed” by someone without a real understanding of what they’re doing — but at the same time being very clear about where the market direction and user definition is primarily coming from. Open and honest discussions are key here – if someone says something that you don’t understand technically, engage on it — focus on learning how it meets the end goals, not on the technical details. Enable your teams to focus on the “how” while you focus on the “what”, “who”, and “why”.
Be Curious and Willing to Learn
One of the quickest and easiest ways to build a relationship with your technical team as a non-technical PM is to demonstrate honest curiosity about what it is they actually do and how they do it. Talk with them about the architecture and the technology in your product. Attend any technical training sessions that they have, or brown-bag lunches on technical topics. Some of it may go over your head — hell, a lot of it may go over your head. But showing the team that you actually care about them is far more important than feeding your ego by not showing weakness in front of the team. Ask questions when and where appropriate, listen to what they’re telling you, and learn a little bit about that technology that you knew nothing about previously. Technology isn’t scary, and since you’re trying to manage a product that has a foundation on this technology, you should probably learn at least a little bit about it, don’t you think?
Stretch Yourself – Try Something Technical
Last, and most importantly, if you want to build a career as a Product Manager, and you want to maximize the flexibility in that career, you’re quite frankly going to have to learn some technical skills at some point in your career. Fortunately, we live in a world where there are innumerable opportunities to expand our horizons and try out new and different things — particularly where technical skills are concerned. There are hundreds (if not thousands) of online courses that you can take to learn HTML, CSS, JavaScript, Object-Oriented Programming, MySQL database design, and any other technical capability that you might want to add to your toolbelt. Use your product management skills to identify a problem that you want to solve, and just do it. Build something, anything — it doesn’t have to be fancy, it doesn’t have to be pretty, it barely even has to work. But by showing that you have the personal drive to expand your knowledge, to leverage what you do know into something tangible, and by actually doing it, you’ve just taken yourself out of the non-technical box and moved into another classification of Product Manager. I personally have three apps on the Google Play store — one of which is nearing 2,000 downloads. All because I identified a problem, idealized a solution, and just built it. They’re not super pretty, they’re not loaded with features, but they do solve a specific problem. And, it was fun learning.
