Editor’s Note: Not too long after I started my career as a product manager , I also stumbled upon Irene’s Skiplevel course about how to become more technical as a PM. Like many other product managers, I thought learning how to code was the only way to become more technical, when in fact you can become more technical through the understanding of certain core concepts.
Read on to learn more.
CAREER BACKGROUND
What made you decide to become a developer? What was it like when you were first learning how to code?
Honestly, I kind of fell into it. I was a bit of a precocious kid. In middle school I started writing short stories, pencil drawing portraits, doing graphic design, and blogging. It was the combination of graphic design and blogging that eventually led me to become a developer. I just really wanted my blog to look cool and the way to do that was through these things called HTML, CSS, and JavaScript. I didn’t know you could make a career out of these things–they were just a creative outlet and hobby for me at the time.
So yeah, most of my early coding experiences were self-taught. When I really started becoming a developer, I did an in-person beginner’s JavaScript course. That helped formalize my coding chops a ton. From there I just learned at every job I went to. When I jumped from frontend development to backend, I bought a Java book called “Headfirst Java”. I spent consecutive weekends in coffee shops going through every chapter in the book and doing the exercises. I was also lucky to have co-workers that were super willing to answer my questions.
“It was a commitment, but learning anything new and that’s hard is a commitment. “
It’s so worth it! I’d say any resource will work but the most important thing is getting that hands-on practice. Whatever training you take, make sure there are hands-on exercises that’ll allow you to apply abstract concepts into practical activities.
You worked at Amazon for almost 4 years as an engineer, what was that experience like? What was it like working with the product managers there?
Yep, I worked at Amazon as a software engineer for 3 and a half years. I started out in the advertising org building custom advertising experiences for companies like Universal Studios, and then on the internal “Wiki” team that managed Amazon’s company wide internal documents app. Each team is a little different, but overall Amazon’s culture of innovation, customer-centricity, and long-term thinking is pretty pervasive so you’re expected to bring your A-game at all times. And yeah, that was challenging and draining in the long run. You couldn’t ever really get too comfortable or complacent and there was always so much on the roadmap that there wasn’t a lot of room to ‘take it easy’.
It was a tough environment that really pushed me out of my comfort zone. I’d definitely say my time at Amazon was a love/hate relationship. I had a lot more anxiety even though I’m not an anxious person by nature. But it also really raised my personal bar of standards. I’m a much better engineer because of it and even though it was a tough experience, I’d recommend it to anyone as a valuable growth experience, especially those starting out in their careers.
As for working with the product managers, it really varied based on the team and the product. The product managers I worked with in the advertising org were held to higher standards than the ones on the internal team. I also worked with product managers based in London and the culture and expectations there were also very different.
Overall, I definitely worked with some of the smartest product managers ever during my time at Amazon. They held themselves to high standards and I was really impressed by their ability to multitask, communicate, and just execute. But 9 out of 10 of them were not technical so there was always a gap in communication that needed to be bridged.
BEING TECHNICAL
You mentioned challenges working with product managers throughout your career as an engineer, can you expand on that? What challenges did you feel were most difficult to navigate?
Well, as a software engineer I’m always thinking about how to build a feature in the most efficient way possible that fulfills the requirements while balancing long-term tradeoffs. That’s the perspective all software engineers come from. For better or worse, many product managers I’ve worked with don’t have the technical knowledge, vocabulary, and understanding of how software is built, and what it takes to build it. That inevitably creates a big communication and knowledge gap and in my experience, it can be difficult to know how to navigate that misalignment. Many product managers I’ve worked with didn’t have an understanding of the technical limitations of the software, which led to unrealistic expectations and timelines. It’s also not uncommon for them to ask for features that were not feasible or would take much longer to build than they anticipated. This definitely led to a lot of frustration and miscommunication between product managers and the engineering team.
When you say “many of the product managers you worked with lacked a technical education”, what do you mean that? Are you suggesting product managers need to have a technical background?
It’s on a spectrum. If you’re a PM working on a product where the customers are developers, or the product itself is highly technical then yes, you’re on the higher end of the spectrum for how technical you need to be. In that case, it’s really helpful to have a technical background. But if you’re a PM working on a website that doesn’t require working with lots of data, APIs, and thinking about scaling, then your technical literacy is on the lower end and primarily UI/UX focused.
The rule of thumb is that if you work on software or any type of app, whether it’s a web app or mobile app, then you need to at least have a fundamental understanding of what the availabilities and limitations in technology are and the process of building and shipping software or what I like to call the software development lifecycle (SDLC).
To be clear, this sort of technical education doesn’t mean you need to have a technical background. You don’t need to have been a developer or have a degree in computer science.
“Just understanding the core concepts and the engineering mindset when building software will get you a really long way.”
Then it’s just a matter of filling in the spaces as you’re exposed to more technologies and challenges throughout your career.
Can you share some common technical concepts that you feel many product managers don’t understand but need to improve their understanding on?
Definitely. I see a lot of product managers take a coding class and get overwhelmed. The trick is to focus on gaining knowledge and skills in technical areas that will benefit the product management role specifically.
For example, you’ll definitely run into situations where understanding the anatomy of APIs come in handy like during engineering demos, looking at API documentation for third-party integrations, troubleshooting errors, etc. So APIs are definitely one important area to focus on learning.
Another is software architecture / system design. The vast majority of your technical discussions with engineers is going to be about how to architect the system. Things like whether or not to go serverless, how many services to create and which ones, which programming language to use, cloud services to integrate with, and whether to use a queue or a job scheduler. So if you want to keep up during technical discussions, you’ll definitely want to focus your attention on system design and understanding technical trade-offs so you can evaluate different technical solutions.
Photo by Christina @ wocintechchat.com on Unsplash
Why do you think so many product managers feel the need to learn how to code to become more technical?
A few reasons.
In our industry there’s this idea that being technical means being able to code. But there are lots of developers that can code yet if I asked them to evaluate two different system designs for the same problem, they wouldn’t be able to give a coherent answer. You see this with coding bootcamps. Students come out of bootcamps knowing how to set up a development environment and code features in some language, but don’t have the expertise to know how to optimize systems for fault tolerance, scalability, maintainability, fast latency, etc.
I’m not knocking coding bootcamps btw, I think they’ve started the journey of a lot of amazing engineers and that’s incredible.
“My point is that being technical is on a spectrum and technical education should be tailored to the specific role. “
There isn’t enough conversation about this hence the default mode of just learning how to code to become more technical.
That brings me to the next reason that there just aren’t enough resources out there that teaches technical literacy tailored for the product management role. You can search for YouTube videos and technical articles, but little bits of information here and there make it pretty hard to understand how everything in technology is connected. This is why I set out to create the Skiplevel program. It’s a comprehensive 5-week course and community designed specifically for product managers to learn the most vital technical skills and knowledge they need to succeed.
SKIPLEVEL COURSE
Can you provide a high-level overview of your course?
Yeah, the course is designed for product managers so there are real product case studies and tips for different situations PMs might find themselves in. It’s also created for beginners so we start from the basics and work up to high complexity topics like containers.
The course has 5 modules covering 6 core areas in software:
- Infrastructure
- Applications
- Performance
- Data
- Architecture
- The Software Development Lifecycle
Each module follows the same structure:
- Watch video lessons
- Read articles
- Do a hands-on exercise with a dev tool to apply what you learned
Then of course there’s the community where students get feedback on their exercises and ask additional questions.
What is your favorite section of the course and why?
Oh man, that’s honestly hard to choose… but if I had to, it’s probably the first module on Infrastructure and Applications, and the fourth module on Software Architecture.
The infrastructure and applications module is the longest one in the course and it really sets the foundation for connecting all the dots in software. I’ve had a lot of students reach out to me and tell me they had “aha” moments just from that first module.
I love the software architecture section because it’s an area that product managers have the least experience and exposure to but is so so so important to understand the engineering mindset. The exercise for this section is designing a microservices system from an existing monolithic system and so many students struggle with this section. It’s great experience though.
Can cross-functional teams benefit from this course?
Yes, definitely! The course was designed for the product management role in mind, but lots of students are also designers, marketers, and operators. The course really benefits anyone that’s looking to improve their technical chops.
What advice would you give to people who want to get the most of your course?
Probably the same advice you’d get for taking any course. Commit to working on the course. Stay curious. Be engaged and active.
The course really is what you make of it. The students that get the most out of the course are the ones that are the most engaged in the community. It’s obvious how committed a student is by the frequency and depth of the questions they ask. Some students will refer to things they’ve seen on their job and ask how it relates to the concepts I teach in class. I love questions like these because I end up learning something new about a tool I’ve never had experience with and the student gets to apply the knowledge immediately to their jobs.
Are you planning on creating any other courses in the future? I.e. AI?
Yes, though the timeline for new courses is TBD.
Aside from taking your course, what are other ways that product managers can become more technical?
Broadly, anything you can do to immerse yourself in the world is the right move. The most important advice I have is to be curious in your day-to-day role as a product manager. Having that strong curiosity to learn AND the confidence to know that becoming more technical is completely within your realm of ability even without a technical background is the best motivator for asking more questions, looking for resources to learn technology, and doing whatever you need to to really elevate your technical chops.
By the way, ‘be curious’ might seem like obvious advice, but I’ve worked with product managers that really lack this mindset and that’s tough because there’s no motivation to stick to something that’s hard.
In terms of practical advice, my favorite hack is to get yourself a tech mentor. We all know what mentorship is. Tech mentorship is a spicier version where instead of finding a more senior person in your same role to mentor you, you look for someone in a different role to mentor you in their expertise. In this case, you want to find someone that’s technical. So that could be a developer or a TPM or a systems architect, etc. Tech mentorship allows you to have a safe space to ask all the “stupid” questions you want and you have a dedicated person that gets to know your weak areas and can really spend time going into the details with you.
For tech mentorship sessions, I suggest meeting on a regular basis–say once every 2 weeks. Prep in advance what you want to bring to the meeting as a jumping off point for the convo. That could be internal dev docs, API documentation, or just asking the dev to walk you through how a specific feature is implemented. You’ll want to ask open-ended questions during sessions so you really understand the thinking that goes behind implementing. For example: “If you had to re-build this feature, how would you re-build it and why?” Tech mentorship really is an amazing way to stay up-to-date with technology and in the know.
I was a tech mentor to a couple of product managers while I was at Amazon and it was an awesome experience. For you as a product manager, it’s an amazing way to stay up-to-date with technology and in the know. For me as an engineer, I learned so much about product management. I was blown away by how many moving pieces my PM was juggling the first time I saw a product roadmap. It’s really a win-win for everyone.
ABOUT THE AUTHOR
Irene is a former software developer for Amazon, where she found herself mentoring non-technical product managers to help them get better at tech. Inspired by her success, she left to found Skiplevel, a technical training startup aimed at teaching actually useful tech skills to product managers & non tech founders.
Connect with Irene:
Twitter: @skiplevelcourse
Instagram: @irenefromskiplevel
YouTube: @skiplevel
Leave a Reply