Becoming a (more) Technical Product Manager, Part I: Diagnosing the Problem
In this series, I will take you through my journey to improve my technical knowledge as a Product Manager in an early-stage startup. I hope it can provide you with inspiration for your own development plans, and that you can save time using the resources and frameworks I share.
Why become more technical?
Since I moved into product three years ago, it’s been clear to me I would eventually need to ‘become more technical’. Whilst increasing number of product managers in the tech industry come from computer science degrees or have practical software engineering experience, I read History at university. My first post-grad job was in recruitment. I adore user research interviews, storytelling, ideation, writing and stakeholder management. And I’m not that technical.
I’ve gotten some push-back at the use of those words. When I told a career coach I was “not that technical” she recoiled as if I had told her I had an infectious disease. She told me not to repeat those words, as if avoiding the topic altogether might banish what she diagnosed as imposter syndrome.
It is true that I do have some technical strengths; I moved into data analytics early in my career and worked closely with data science and competitive intelligence at Expedia Group. Every day, I work closely with a solutions architect and tech lead to define the solutions to user problems and I learn from them. I’m constantly asking my developers questions. And yet, I am acutely aware that I can not actually call myself a ‘technical’ product manager, and that I am missing some core knowledge of software architecture that might make my job easier.
- Experience I have: Basic css/html from my teen years, python/javascript courses from work, sql/r/data analytics practical experience from a past data analytics role.
- Experience I do not have: a degree in computer science, work experience as a software developer.
The product management triangle
The model I use to explain my skill gap is the product management triangle. (Credit: Daniel Schmidt) It puts ‘users’, ‘developers’, and ‘business’ at the corners of a triangle, with the product manager working as a bridge between the areas.
Whilst my knowledge of users and understanding of the business grew organically in every role as I took part in continuous discovery and stakeholder management… asking the developers to teach me technical concepts did not offer the same return on investment. I simply needed to dedicate more time myself to the area.
There are many product managers who argue that ‘bridging’ between developers and business does not require technical skills. Indeed, different roles and different products require different skills of product managers.
However, believing in the principals of continuous improvement, and evaluating my own career as a product, I still see ‘technical skills’ as an opportunity area that will empower me in my current role and improve my career capital going forwards.
Knowing that I had a broad area of opportunity under ‘technical skills’, it was time to define exactly what to learn.
Figuring out what I didn’t know
1. I looked at existing resources and compiled a list of topics
Firstly, there are plenty of existing resources targeted at product managers. I was initially very tempted to pay for the SkipLevel technical PM course — I’ll go into why I decided not to later.
As a first step, I combined the high-level topics listed for the SkipLevel course with advice from articles I found written by product management leaders. Thankfully, product managers REALLY like to share their opinions online, so there were plenty of suggestions on what to study. I’ll link to some of my favourite resources at the end of the article.
At this point, the list of topics was pretty general and non-specific to my own knowledge gaps. For example, I didn’t exclude ‘relational databases’ as a topic, just because I was already familiar with it.
2. Asked my network to challenge the content
Once I had a list of topics and sub-topics, I reached out to the Solutions Architect and Engineering Manager at work and asked for their opinions. They could tell me right away where they felt topics were highly relevant for me, or just interesting but unlikely to impact job performance.
I also sent the list out to some PM friends and mentors for additional feedback from people whose careers I wished to emulate.
3. Picked success metrics to guide the solution direction
Why set a success metric?
- Clarify what I needed to learn — guide the “what”
- Help me enter the solution phase — inform the “how”
The success metrics I landed upon:
- Develop a deep understanding of how software is built and an awareness of what technologies exist
- Create a shareable resource for others
I decided to add a secondary success metric which would shape the format of my learning, and help me work on another goal for 2023; improving my informative writing skills via online content. Writing is such a core skill for product management; you really can’t work on it too much. This success metric ruled out the possibility of me taking a pre-built course like SkipLevel, and meant that I would be building my own solution!
It also meant I wouldn’t be excluding topics I was already very familiar with, but seeing those ‘chapters’ as a chance to refresh my knowledge and share my own expertise.
So now I have a high level curriculum and success metrics for this product. Step 1 is complete. What’s next?
Next up, Part II: Planning the work
The next article will take me into the planning phase, where I need to consider the following.
- Where will I get the information and course content from?
- How should I document my learnings to easily share them?
- How can I plan this work alongside my day-to-day work and other commitments, whilst keeping velocity and motivation high?
- Are there any blockers or rabbit holes I haven’t considered?
Want to stay updated on my progress? Give me a follow. I’ll be posting next steps, learnings, and useful resources in the coming weeks until the course content itself is ready to be shared.
Helpful resources for Part I
- Technical Product Manager Course Curriculum — skiplevel.co (Irene also has some Medium articles for free, thanks Irene!)
- The Technical PM’s Newsletter on Substack
- Do I need a CS Degree to break into Product Management
Editor’s Note — 23/05
You can now go straight to the “meaty stuff” below!
The Introductory Content
The Technical Content
