An engineer’s guide to Product Management
After I decided to transition to Product Management from Engineering, the road towards becoming a Product Manager was not so straight forward. There were a lot of unanswered questions in my mind, even before I started on this journey. Mostly around if this is the right decision for my career, will I be able to create more impact as a Product Manager rather than a Senior Engineer or an Engineering Manager, will this transition bring awkwardness among my peers, what if I fail in this new role, etc.
That being said, it has been a journey full of new learnings, challenges, and lots of exciting discoveries, most of which I will try to share here. As I progressed as a Product Manager, I met several people who wanted to understand my motivation behind the transition as a Product Manager and were looking to move to Product Management at some point in time.
With this blog post, I will try to provide my perspective of Product Management, what are the key differences that you would have to embrace as you make the transition, and what are the core skills that you might have to acquire to be an impactful Product Manager.
So you want to be a Product Manager, really?
Product management as a field has boomed in recent times, and I believe that’s why there are a lot of different opinions on Product Management and what is a Product Manager’s actual job.
That is why I also feel I should first clear some air around it, and make sure that Product Management is something that you are excited about and that you are not motivated by the myths associated with the job. I have also seen that people selectively only process the amazing aspects of the role. Things like, “You’ll get to be the CEO of a product!” “You get to manage many different teams!” “You get to come up with ideas for features and new products all day long!”. But whenever something sounds too good to be true, always remember the words “There’s no such thing as free lunch.” Some of the most common misconceptions about product management are
I get to be the CEO of a product!
Let’s get one thing straight. As a Product Manager, you’re going to have to learn to throw away any ego and remember that you own the failures while your team owns the successes. The best teams work well because everyone feels ownership over the product, and it’s your job as a PM to guide your team towards a product vision and give them all the credit. Ideologically, your role will be closest to that of a sports team coach. If you win, your team will get celebrated, but if you fail, you might get fired.
Being a PM lets me do different types of work in various fields!
A lot of people think that being a PM means you get to work directly on all aspects of building a product like engineering, design, marketing, finance, strategy. Depending on the size of your company, there likely will be dedicated teams for each of those functions, and your role will be communicating, planning, and coordinating with each of these teams. As a PM, you should focus on being a champion for your users and understand their needs, so that you can work with your dedicated teams to come up with the right solutions.
There’s a ton of satisfaction in shipping the product!
Product management is a job that does not have immediate, concrete satisfaction. You’re going to be scrambling around making tons of decisions, and it will take a long time before you see a final product or feature launch. There is no moment of clarity where you find and fix broken code, design the perfect user flow, or have an ideal product that requires no more work because shipping a product is like an infinite game. With every release you learn something new, you then iterate on it to make an improvement and then release again.
The PM role is well-respected!
Product management may be the one job that the organization would get along fine without (at least for a good while). Without engineers, nothing would get built. Without salespeople, nothing gets sold. Without designers, the product looks like crap. But in a world without PMs, everyone simply fills in the gap and goes on with their lives. It’s important to remember that — as a PM, you’re expendable. Now, in the long run, successful product management usually makes the difference between winning and losing, but you have to prove it.
Now that you have understood what not to expect from the Product Manager role, I want to make sure that you have the right motivation to be the Product Manager and that you are making the right career choice. What I primarily want you to do is take some time off from your busy schedule and ask your self these three questions:
Q: Why do you want to become a PM? What’s your motivation?
Q: Do you like thinking about Problems or thinking about their Solutions?
Q: Why do you believe you will be able to create more impact as a Product Manager as compared to your current role?
I could have given you my answers to these questions, but that would have prevented you from self-evaluation and probably would have made you force-fit your answers towards your biasing.
What I would instead recommend you is that you discuss these with the Product Manager in your organization. They have worked with you closely and would help you in understanding the role of a PM better. If you don’t have a PM in your company, feel free to connect with me over LinkedIn, and we can discuss this in more detail.
So what does a Product Manager actually do?
Great PMs do whatever it takes to amplify their team’s impact on the customer experience and business. Product management can sometimes be an unglamorous job, but ultimately there is no greater joy than seeing your product launch and provide value to your users.
Great PMs do whatever it takes to amplify their team’s impact on the customer experience and business.
Like most jobs, product management involves more of an attitude than a set of skills. Great product managers:
- Execute impeccably. They say what they’ll do, and then do what they say. Their follow-through is impeccable, and they don’t let details slip. When they join a team, quality and pace seem to dramatically improve overnight as they deal with ambiguous tasks and immediately adapt to get stuff done.
- Voraciously seek out insights about customer needs and pain points through research, experiments, and cross-functional partners. They course correct constantly.
- Always try to fine-tune and build product strategy to maximize business impact, so their teams never worry about whether their hard work will matter. They don’t care about accolades from peers, Apple design awards, or press write-ups.
- Talk well and listen even better. Product Managers infuse urgency, foster collective creativity, and build great relationships with all teams they work. They establish consensus by default but can drive hard decisions when they have to. They establish enough credibility to rally a team around a product strategy
- Define and track the key metrics that matter and align the whole org around them. They know how to design and analyze reliable experiments — and know when hill-climbing isn’t worth it.
- Immerse themselves in research, feedback, data, discussions, and the market. They craft thoughtful, inspiring narratives for where the product should go — and the best path to get there.
- Maintain a framework for prioritization as well as make the right product trade-offs
If you have started doing your research about Product Management, then this is one of the most common representations that you will find about the job.
This intersection is the minimalistic way to define the different kinds of hats that a Product Manager might have to wear. This in no way means that you need to have in-depth experience of all these three fields, but what you might be expected to have abstract knowledge about, to steer through the different roadblocks, decisions, prioritization while building a product. You can read more about the things that you need to know from every circle here.
As a Product Manager, you don’t have to write code, create mockups, sign deals, but your job is to help your team ship the right product to your users that will create more value. This also brings me back to the myth that I mentioned above, You’re not the CEO of the product, but you are a team leader.
Now that you know what a Product Manager is and what they are job they are supposed to do, it is equally vital that you understand about the things a PM should be very cautious of not doing
Thinking you are the customer
You’re in the business of building products for customers, and you have to remember that you are not the end-user in the development-use cycle. Learn to take yourself out of the equation and focus on the real facts and data that support creating something people want. Stay away from planning based on the idea that “this feature will be cool to have.” No matter how “cool” it is, this doesn’t mean it will make your customers happy. Know who your target is, and build for their delight.
Building your roadmap strategy by your intuition alone
This goes back to thinking a feature will be cool to have. You may have an intuition when it comes to creating an excellent product, but you also need to back that gut feeling with some data. The desired end result is customer happiness, which leads to sales, which keep the lights on. Implement A/B testing strategies, feature requests based on valuable user stories, and feedback from your team. Then build the roadmap based on that plus your intuition.
Assuming the vision is all yours
You are there to support your team, remove roadblocks, and give them the freedom to build. Stay humble and empathetic. Don’t prioritize a feature over another just because it was your idea. Let your developers tell you how they can add features and what they have in mind, and don’t be afraid to work with a team that is smarter than you. This will go a long way when it comes to getting everyone on board with your product and influencing your stakeholders.
Using fancy tech jargon and over-the-top designs to get to your point
Your job is to tell the product story, explain how much the user experience will improve, and the end results of the new feature or addition, such as more sign-ups, in-app purchases, better retention rate, etc.… In the art of storytelling, we know it’s essential to be clear and concise, and be able to explain the “why” well enough to express how the action will drive business results.
Doing everything your CEO, customers, team, and mother ask
You should probably do most everything your mother asks, but when it comes to building your roadmap, it’s important to take ideas into account, then back up suggestions with data. Get comfortable with saying “no.” If you accept every task or additional feature suggested, you’ll never have a finished product. Often in product management, done is better than perfect, so leave space to have a finished product, A/B test potential features, then make version 2.0 or updates based on intelligent qualitative and quantitative data.
What will be different from your existing role
Of all the things that I had to do to prepare myself for the transition, the most challenging one was to drop my engineer’s mindset. Now that doesn’t mean unlearning the skills of an engineer, but to work as a successful Product Manager without being influenced by the engineer in you. During the transition, it might also be expected from you to fulfill your current role and that of a PM. But sooner you detach yourself from your existing role, more impact you will be able to create as PM. Some of the things that have helped me in achieving this transition are:
Redefine Success
Most of the time, people start considering the effort they put into something as their success. To be a great Product Manager, you need to redefine the way you measure success by calculating the impact that you create for the users, product, and the organization.
It doesn’t matter if you ship 100 new features unless it either generates more revenue, improves retention, or solves a common pain point of the user. The rest of the organization might consider shipping a new feature as their success, but for you, as a Product Manager, it might be just a waste of resources if it was not able to create an impact.
Ship early
When teams ship a significant release, you hope to get an immediate hit of value. Even operating on the assumption that you release the perfect solution with no technical issues first time (spoiler alert: it’s unlikely). There has been a massive investment made by your team (in terms of time) that has not returned anything (left diagram).
By releasing small and often, you’re shipping incremental pieces of work. It begins to pay off because you can realize value sooner and learn from mistakes faster. Value trends above effort almost consistently in the second graph, and this is what teams should be striving for.
There is no “Done”
Your job is never done, and the product is never finished. In reality, no product will ever be quite right for everyone. It’s an ongoing process of continued development and iteration to make it better. As a PM you constantly Build, Measure and Learn in a loop
One other challenge that you might run into while adopting this ideology is to keep your team motivated towards making those small but impactful changes. Engineers love to get challenged by working on larger and meatier features, but as a PM, this is your job to communicate to the team that why these small improvements are way more important than that next upcoming feature.
Become obsessed with problems, not solutions
It’s straightforward to get attached to a novice solution, which you believe is the perfect answer to the user problem that you are trying to solve. Imagine after three months you released a feature that, according to you, is a groundbreaking feature for your product, but when you looked at your growth numbers, there was no much impact.
Being obsessed with the solution will make it very tough to do an honest retrospection because you were 100% certain in your mind that it’s going to work. On the other hand, if your entire focus is on the problem in hand, then it’s a fair thing to assume that you would have multiple hypotheses to solve that. And even if one of them fails, you can always try other ones to solve that problem.
Core Product Manager Skills
Over the past year, I talked to a lot of PMs, trying to understand the essential skills which they see in successful Product Managers. PM role might have different responsibilities in different organizations, but some of the skills that are must for an effective Product Manager are:
Communication
PMs are information conduits and context builders, and therefore communication is everything. As a PM, it’s your job to communicate vision and strategy for the product in order to persuade people towards the objective rather than asking them to do stuff. Therefore brevity and clarity are your two most important rules to follow when it comes to communicating as a product manager. Don’t use jargon, but instead, make sure you’re speaking the language of whoever it is you’re talking too. Successful PMs are concise, structured, thorough, and persuasive.
Prioritization
The time of your team is the most precious resource at your disposal, and it’s your most important job to direct that in the right direction. There will always be hundreds of things that people will expect you to do in the product. You will have requests from your CEO, team, customers, etc. but as a PM, it’s your job to choose. Once you grow in this role, you will have your own way/framework of prioritizing things, but remember that core of all those should always be the impact and value that you are creating for your customers. You should be ruthless and rigorous in your prioritization and always choose the most impactful thing that you should be doing at that time. How to identify that most impactful thing is where your other skills as a PM will come in handy, such as talking to customers, gathering insights from data, user research, etc.
Analytical thinking
Great product managers should have the ability to get your hands dirty with analyzing data. While technical skills like coding aren’t mandatory, the ability to analyze data and provide recommendations/insights for the rest of your team is crucial for measuring success. For every feature you push or course of action taken through the life cycle of your product, there should be measurable results that can determine success or impact.
Empathic thinking
Empathy is the ability to walk in someone else’s shoes, to see and understand the world from their perspective. It is the sentiment of curiosity about who other people are in themselves. If you’re building something for someone else, you’ll be more successful if you can identify with their needs first.
But empathy is also essential to leading a team, especially for PMs who tend to have responsibility without authority and must earn respect and support of others. If you can see the world through your engineer’s eyes, or from the perspective of your VP of sales, you can understand what motivates them, what frustrates them, and what you can do to help.
Decision making
Product managers have to make many decisions every day, including product prioritization decisions, product design decisions, bug triage decisions, and many more. But deciding how important a decision is, is the most important decision you can make. In Amazon’s 2016 shareholder letter, Jeff Bezos touches on this concept.
When you are racing against the time to ship out a product, the pace at which you take decisions becomes critical. It might feel great to you to be at the center of every decision that’s being made, but please understand that it’s not going to scale. PMs should be the facilitator of decisions and should care about getting to the right decision, not whether they are right. As a PM, you should layout well-researched trade-offs, set timetables, and structure great discussions. Only in rare situations should you actually “make the call.”
So finally, If you’ve gotten this far, and you’re brimming with excitement, then maybe it’s time to button up, roll up your sleeves, and start your own product manager journey.
FAQs
- Do I need an MBA degree to become a Product Manager?
Well, it depends. If you are transitioning to Product Management in your existing company, then you might not require it. But if you are looking to make the switch to a new company as a PM, then having an MBA degree helps. Also, if you really ask me, people who are looking for PMs with an MBA degree are just looking for their credibility because that’s the only data point these companies have about you. So if you can establish your credibility as a PM, then you don’t need an MBA. - How much Technical a PM should be?
A PM is never required to write code, but what is expected from a Product Manager is that they can understand the system architecture at a high level and can converse with engineers about technicalities of building a new feature. - What should the initial few weeks of a new PM look like?
One of the common mistakes that I have seen new PMs making is trying too hard to establish their credibility a PM by jumping too fast into things that they don’t completely understand. I would say start by meeting your team, conducting 1:1 meetings, understanding the problem space, constraints, understanding about the initiatives that the team had tried before you joined, making sure that you have data available to get insights from, etc. Believe me; it’s ok to take some time to get comfortable rather than starting quickly but off on the wrong foot.
References
Books
- High Output Management by Andrew Grove
- The Lean Startup by Eric Ries
- The Innovator’s Dilemma by Clayton Christensen
- Inspired by Marty Cagan
- Hooked by Nir Eyal
- Measure What Matters by John Doerr
P.S: Special note of thanks to Product Manager HQ, Product School and Mind the Product for providing a wonderful community for Product Managers, some of the content is inspired from the conversations with the PMs in this community and their resources. I would definitely recommend joining their Slack communities
