#12: Product management for engineers
Why, how, and where to learn it
Learning PM skills is a topic that I discuss very often with my engineering team members. If you are an engineer, read on! If you are not, feel free to share it with your engineering colleagues :)
As an engineer, I realized that knowing about product management will help me be more effective in my job. In my next job as an engineering leader, it enabled me to also be the VP of Product. And later when I turned into a technical founder, the skills came in handy.
In this post, I will be sharing:
Three reasons to learn product management for engineers,
Three actionable tips to get started, and
Three beginner resources to dive into the topic.
Why engineers need to learn PM skills
1. Knowing PM skills increases the success rate of your project
When you know about user research, backlog prioritization, and stakeholder management—the critical PM skills—you will help your team's Product Manager not be a single point of failure.
There will be more brainpower to think about important problems and what to work on, further reducing potential mistakes and loopholes in your product.
2. PMs and stakeholders will like working with you more
When you have PM skills, your stakeholders, especially your product and business counterpart, will have an easier time working with you.
Since you will know how your company operates and what is expected from the product team, you can help them fill in the gaps and cover the nitty-gritty details—leaving the product and business team to work on more high-level problems.
3. Knowing PM gives you more ownership and opportunity
In my first job as an engineer, we don't have a product manager. So I needed to step up in learning product management until I could work on projects end-to-end, covering both engineering and product.
The product development cycle became faster because there were no back-and-forth delays between product and engineering, as it all happened in my head.
And the benefits were carried over to my next leadership role as VP of Engineering at a different company. From those experiences, my then-boss trusted me to be VP of Product for about a year until a dedicated VP of Product could be onboarded. A whole new kind of experience. And this wouldn’t be possible if I didn’t know a thing about product management.
How to get started
1. Turn your Technical Design Doc into PRD
Engineers are accustomed to writing a Technical Design Doc (let's shorten it to TDD). In contrast, one of a PM's key deliverables is a Product Requirement Document (PRD)
You can understand the aspects essential to a product manager by writing PRDs.
The goal of TDD & PRD is similar: bringing clarity to problems and solutions. With TDD, we are exploring the hows of the project, while with PRD, we are focusing on the whats and whys of the project.
There is some content overlap between TDD and PRD. To turn a TDD into PRD, you can add these extra sections commonly found in PRD:
Success Metrics: business-wise, what are the parameters & goals for the project to be considered successful?
User Persona: who are the target users, and how will they interact with the product?
User Stories: what are the features, and why are they important?
Go To Market Plan: how will you market and sell your product to users?
2. Let go of the builder hat, and pick up the user hat
One big product manager's job is to continuously improve the product. As the builder, we engineers tend to have biases that hinder having an objective view of our product. Especially if we spend most of our days looking at the codebase and tweaking the product. This makes us more challenging to assess and improve our own creations.
So, to have a clear view of our product, use it as the user, not as the builder. Imagine that you are a user trying to achieve something with your product.
Try to signup for your product with a new account. Or help someone you know use your product.
You will notice the imperfection, the issues, and the potential for improvement that we wouldn't otherwise get in our day-to-day work coding.
3. Be a master of quality
A great product manager is a gatekeeper of quality. They are the champion and the shepherd of high-quality products.
To develop an eye for quality, look at other high-quality products and understand what makes them great. Try to use them extensively, observe the details, and figure out the decision-making process for each aspect of the product.
It's like reverse engineering all the way to the product conception stage.
Beginner resources to dive into product management
So, if you are an engineer trying to learn more about Product Management, here's the best way to get started:
This book will give you a lay of the land and is a helpful way to get your bearings. There's a reason why this always came up as many PM's favorite books. The book is dense yet broad enough to introduce us to the basics of building amazing products.
2. Product Management - From Meh to Awesome
This talk by Shiva Rajaraman is a must-watch resource[ for anyone interested in learning the craft. Shiva shared many small but essential learnings from his time managing products at YouTube.
3. John Cutler on Lenny’s Podcast
And if you want to start going down the rabbit hole, listen to John Cutler's episode on Lenny Rachitsky's Podcast. John wrote a popular newsletter called The Beautiful Mess, which has been on my regular reading list for a long time.
Those three resources will greatly speed up your learning journey. Do let me know if you learned Product Management from other materials :)
My Viral Podcast Interview
Two weeks ago, I was on a podcast that went viral. Even though it was posted to a channel with zero followers, my video somehow appeared on many people's YouTube home page and managed to attract 380 thousand viewers.
My post on LinkedIn about it also received many responses, amassing 200 thousand views and over two thousand likes. It's interesting how sharing more personal stories and showing our vulnerable side can be a differentiating factor on LinkedIn, where people are usually more focused on showing off their achievements.
In the podcast, I talked about my story of growing up in poverty, how I managed to escape it, and my personal mission behind Lumina.
Here's the podcast video (in Indonesian):
Taking on Ship 30 for 30 challenge
I joined the July cohort of Ship 30 for 30. A program where I have to write something online every day for 30 days.
Aside from helping me to be more consistent, there are four reasons why I decided to do this challenge.
1. It will help me build good habits.
There's nothing more habit-forming than forcing myself to do it for thirty days straight. And since the outcome is visible, it is easy to validate the progress.
2. It will help me generate more ideas.
I get many more ideas during the writing process than before. Sitting for 30 minutes daily typing on my notepad will help me be more creative and unlock more ideas. As many people say, writing is also thinking.
3. It will improve my writing skill.
I have always been a fan of the craft but never formally learned it. This time, I will practice the principles I obtain while reading William Zinsser's book "On Writing Well."
4. My learnings will help more people.
I worry that I will forget everything I have learned before sharing it with others. By reflecting and sharing my learnings, I hope it can help you shortcut a few things and avoid similar mistakes I made.
Over the next 30 days, I plan on writing on Twitter and LinkedIn about the challenges facing early-stage technical founders. I may repurpose some of the posts to this newsletter if it fits a story that I want to write here.
That’s all for this week folks. See you next week!
No top finds section as there has been many links already :)