The Product Manager Makeover - Know Thy Tech
We have all been lied to. About how much tech you need to know as a PM. If you are going to your first PM gig thinking you need to know X amount of tech, make it 3X, and you still might fall short!
You’ll not code. But that’s about it. You’ll need to know everything else.
This is Post 2 of my series - The Product Manager Makeover where I discuss skills needed to make a top-performing product manager. If you haven’t read the previous post, you can read it here.
There seems to be a common misconception among PM aspirants that you don’t need to know too much tech as a PM. I can assure you that apart from a few PM roles, you will be expected/required to have considerable tech knowledge in almost all tech-first companies.
Why does a PM need to know tech? Short answer - it is a tech role.
Long answer -
You need to understand the services you are PM for. How are you building products using these services if you don’t know how they work?
No, you don’t need to go over the code. But you need to know which other downstream/ upstream services it interacts with. What are the Key APIs? What are the inputs? What are the outputs? What is the logic? What happens if other services fail? What events are you capturing? And so forth.
Unless you know your service inside out, you’ll never be able to write a PRD that is comprehensive and covers all use cases including corner cases. You don’t want to go to engineers with a half-baked PRD. Do you? which brings me to my second point
You need to work with engineers. You need to go into meetings with architects and lead engineers where you need to tell them about what to build. You need to understand how they are building it and then you need to make sure it is being built the right way.
The first PRD I ever wrote and presented, my EM said to me- “Please learn the basics, and then come back” in a room full of people. I was incredibly embarrassed and I vowed never to be embarrassed again.
If you are technically weak, at best they will grill the daylights out of you in meetings. At worst, they will not respect you. And if they don’t respect you, you’ll never get anything done.
Someone very wisely told me once - If you need engineers to respect you, you need to speak their language. And if you don’t know it, then you need to learn it. As simple as that!
The final reason to learn tech is self-serving. If makes you important for the org. If makes you indispensable.
Imagine you and another PM are in a pod and now they need to let go of one. You have demonstrated in the past that you know your services thoroughly and are very competent even for technically challenging projects while the other PM heavily relies on engineers for any tech discussions. All other things remaining constant, who do you think they are getting rid of?
This hypothetical scenario is becoming a reality more than not these days and having a strong grasp on tech is only going to give you an edge over your peers!
Now that we have established that PMs need to know tech. How do we learn it?
Talk to engineers.
Yes, the same engineers who will eat you alive if you don’t know your stuff will also help you learn your stuff. You just need to ask them.
Here is how you do it
You need to do it in three phases.
Phase 1
Phase 1 is Day 0-30 of joining a new pod/ becoming a PM. This phase focussed on rapid scaling up to make you useful. The time commitment required is 30-50% of your bandwidth.
In the first week itself, sit with your manager and make a list of all the services you need to know about and classify them as core and non-core services. Core services are the most important services that you’ll be working on every day. Non-core services are other services you’ll work on but not daily/ not useful for all products.
After you have this list, set up 1-1 with your lead engineer and validate the list. Make addition/ subtraction based on their suggestion and now you have the final list.
Then ask them what is the best way to learn about each of those core topics. It is unlikely that anyone will have time to go over all the topics personally so they’ll suggest one of the two things
Point you to resources - tech documents/ KT recordings/ training videos for a topic
Point you to a POC who can help you learn the topic - That POC might again do the same as point 1 or if it’s a small topic, just walk you through
After you have gone through the documentation and meetings; for each topic, you are still going to have multiple doubts/concepts you still don’t understand.
Set up 1-1 again with engineers and get your doubts covered.
Sometimes your fellow PMs may be able to help you too but I still recommend going to engineers for tech doubts because as I will cover in a later post, this is a golden opportunity for you to build rapport with your engineers in the first few weeks.
After you are done with Phase 1 - you should now be able to answer all basic questions about your service and what it does.
Phase 2
Phase 2 is Months 1-6. This phase focuses on non-core services and an in-depth exploration of core services. The time commitment required is 15-20% of your bandwidth.
You need to do the same thing as phase 1 but for non-core services. You’ll also cover the topics related to core services that you weren’t able to cover in the first month.
After Phase 2 - you should now be able to write an end-to-end PRD for a 0-1 product for your pod.
Phase 3
Phase 3 is Month 7 and onwards and focuses on continuous learning. You’ll never learn 100% about your services. If you did, you’d be the architect and not the PM. But you’ll need to know more about your services than any other PM in the org.
In this phase, you’ll already be working on multiple products so you’ll not have as much time but you still need to take out 5-10% of your time each week to go over advanced concepts/ learn more about other services in the org.
You can still set up 1-1 meetings with your engineering counterparts, but you’ll find that you prefer learning at your own pace using documentation you now know where to find.
Read documentation
Yes, read the documentation! Something that sounds so intuitive and yet so few people do. You’ll be in either of two scenarios.
You are in a document rich-pod/org and you have tons of documents per service/ product by both engineers and PMs on Confluence/ any other repository.
Your pod/ org sucks at documenting and everything is just oral history passed down from one engineer to another like mythical tales.
If you are in boat 1, consider yourself lucky and your job is straightforward. Find time to read through important documentation, note doubts, and get them cleared.
If you are in boat 2, I am sorry mate, You are on your own! You can still do 3 things
Continue learning through 1-1s. Your engineers will be annoyed, but hey, who decided not to make documents in the first place?
Read your competitor’s documentation! Yes, you’ll be surprised how much you can learn from your competitors. Let’s take the example of card transactions. You’ll find everything you need to know about card transactions in Stripe’s publicly hosted documentation apart from of course the internal implementation.
This might not be the case for all companies/ teams but hey give it a try at least!
Make sure for your sake and others after you, to allocate a 10% buffer in project timelines just for documentation and make sure engineers do it. Influencing EM might be a good idea!
Ask questions
Again, intuitive but still so many do not.
Repeat after me.
“No question is a bad question”
“I do not look stupid for asking a question”
Your goal is to accumulate knowledge and you’ll have to ask as many questions as you need to. In meetings, in DMs, over emails, or in person. When you don’t understand anything just ask.
I’ll share a personal anecdote - In the first week of my job, I had heard ‘AMJ’ and ‘JAS’ in conversations and meetings at least a hundred times. I had no clue what they were. But I thought that I might look stupid if I asked what it was since it seemed to be common knowledge across roles and pods. Instead, I turned to Google and after days of scratching my brains and not finding reasonable answers, I relented and asked my manager. “ Oh that is just the quarters - Q2 is AMJ which stands for April May June and Q3 is JAS which stands for July August September! I felt so stupid at the moment. Not for asking the question, but for not asking it earlier.
Which brings me to my next point. Let’s modify what we said earlier - “No question is a bad question if asked at the right time”.
Imagine being in an org for six months and not understanding a particular concept ‘X’ for six months straight. You have managed so far just by nodding or deflecting. But now there is no getting around. You need to write a one-pager and ‘X’ is central to it. What do you do now? Ask the question? What on earth were you doing for the last 6 months? Were you just pretending when you were nodding aggressively in all those meetings? Do you understand anything at all?
Hence ask the questions before it’s too late to do so and save yourself from this train wreck of a scenario.
If you still get into it, your best option might be to go quietly to your peers, drag them into a corner, and pray to God that they know about it. I am speaking from the experience of a friend of mine :p
My last two cents on the topic are - “ No question is a bad question, but there are great questions”. Learn the art of asking the right question. A good question is worth 5 okay questions. How do you ask good questions? Maybe I’ll cover it in a separate post someday.
Study
You might be asking, I have already set up 1-1, gone through the documentation, and cleared all my doubts. I now know all about my services. So study why and what?
Well, my friend - I need to tell you this hard truth which I alluded to earlier. You are dispensable. No matter your role, no matter your company, no matter how much time you have spent in the org.
If 2023-24 has taught us anything, it is that you always must be prepared for the worst!
And hence
You need to know more than your peers
You need to know more than other PMs in other companies who will compete with you for the same jobs in a brutal market
How do you do that? Continuously learn and up-skill. Fortunately or unfortunately we live in times where knowledge is available at your fingertips. Keep abreast of what is happening in your industry and what are the future bets. What are your competitors doing that you can emulate? Follow PM leaders/ founders on X/LinkedIn. Subscribe to the industry newsletters. Do whatever you need to.
Taking the same example of fintech, imagine the CEO comes in tomorrow and says to revamp the payment UX leveraging gen AI. It’s never been done before and hence they can’t decide who among you and your peers can do it. You proactively put your name forward and discuss ways to do it using your knowledge of the topic from the internet. Who do you think keeps their jobs in case of a layoff?
Food for thought?
I know this has been a long read but I’ll keep (try) the next one shorter. Stay tuned for the next part of The Product Manager Makeover, where I discuss relationship building for a PM.
