How to be a Successful Product Manager
Product Managers are an absolute necessity to scale any product as your company grows. They can have a huge impact on your company, positive or negative.
Product Managers are an absolute necessity to scale any product as your company grows. Well to restate that, good product managers are a necessity. They can have a huge impact on your company, positive or negative.
Product Managers are also very hard to find. However, I actually believe you can hire someone into a product manager role even if they have never done it before.
A lot of my advice here is about how you interact with your dev team. There are other areas where you need to be good, but this is the one sure fire way to ensure failure if you don't have a great and trustful relationship with your dev team. After all, there is an unwritten contract all PM's and their dev team abide by: "I will drive the roadmap for the product. You will trust that I will have the right process to pick the right features to focus on, and that customers will love what you build. I will trust that you will deliver my features when you say you will."
So when I look to hire in this role, this is my breakdown of the focus areas I feel are critical for a product manager to be successful.
Be customer facing
Most good product managers came from a customer facing role. Maybe they were a sales engineer, a solution architect, a support person, services person, etc. Whatever it is, they were in the business of solving problems for customers. They learned how to solve a problem for a customer, and were involved in it from beginning to end. It's an essential skill.
Pattern distillation
Now if you have the customer facing experience, AND you understand how to look for patterns in the feedback you get, you could be a deadly PM. You can’t have one without the other. A customer facing person who solves customer problems in a one-off very custom way needs to recognize that this approach will not work. What type of business do we sell to? Who in that business buys, recommends, or uses our product? What feedback are thosepeople giving us about the product? After 10 conversations with the right type of customer, what are the top reoccurring themes?
Understanding of trade offs, ability to make good decisions
PM’s are constantly thinking about 10 features they legitimately need, and can probably execute on 3 of them. Which 3? Why those 3? This analysis and thought process is critical to make sure your team is always working on the most impactful things.
Sleeves always rolled up
As a PM, especially in the early days you may write website messaging, sales enablement content, jump into support tickets, do product demos, visit customers, whatever. Good PM’s happily jump into all this, because it only makes them more effective at their job because they see how the front line engagement with their product actually works.
Know your space cold
You need to know your market better than anyone. Setup Feedly, Google Alerts, or whatever system you use and make sure you are reading your relevant blogs/publications. If you have ever been a PM before and were asked about a competitor to your product you never heard of, that sting you felt is probably enough lesson to make sure that doesn’t happen again. I am not saying obsess over your competitors, but know them. Know the 3 reasons you are different and better.
Know your product cold
This one may confuse you but I swear I have seen it. If you can’t demo and use your product with confidence, immediately go attend your product bootcamp. This also applies to “feature PM’s” - where you own a segment of your product, usually when companies get bigger. Try to know as much of the product as you can anyway. How your features impact the rest of the product will always need to be contemplated.
Understand the cost of what you are asking for
I always cringe on behalf of the dev team when I hear comments like, "well, we could either do X, or, we could Y" followed by an explanation of each. The problem is X costs $10 of engineering time and Y costs $10,000,000. If you put them in the same sentence, you are creating a reputation that you don't understand the implications of your asks.
On the other hand working collaboratively with your dev team on doing that cost analysis before you present anything, or even just re-wording that same sentence to say "hey I have been thinking through some concepts after speaking with XYZ customers. Can I run them by you to see what it means from a dev perspective?" Perfect. Now you are getting at least a ballpark of the implications of what you might be asking for and you can use that in your description of the feature "I know this will be an expensive ask, but I think we need it because of these reasons...".
Get your dev teams back
Your customer facing teams will forever have a laundry list of asks for the product. Sometimes they are great, as they are well thought out and reflective of your ICP and sometimes the ask is something they just heard one time earlier that morning :).
Want to become best friends with your dev team? Say this: "hey please tell our sales and support and services teams to route all product feedback requests through me. I am going to catalogue them and track which customers ask for which things so we have a clear understanding of what our priorities should be." You are doing a few things here. (1) depending on the company, you may have just freed up a substantial amount of the your devs time, and they may buy you beer, and (2) you are showing them that you have a process for prioritizing product features.
Earn credibility with the dev team
Nothing tanks a PM faster than if the dev team doesn’t think they know what they are doing. After all, as the PM you own the roadmap for you product and are responsible for prioritizing what gets worked on.
Look at this list above. Do these things, and your dev team will respect you. When you review the next set of features with them, you will get challenged by them, as you should. If your answers are all backed by customer conversations, market research, and a thoughtful explanation of tradeoffs to get the decision you made, you will get head nods and a motivated team ready to execute. If your answers are opinions backed by an article you read last night, good luck :).
In the beginning of your company, one of the founders will be the Product Manager. Their co-founder will many times be the CTO. Everything I just laid out is the same way founders think about their product too. I have heard people describe PM’s as the “CEO of their Product” and I think that's right. As your company grows, you will eventually hire PM's. This is a key hand off, and following these guidelines will set you up for success both with your co-founder as well as your dev team.
Product Managers are an absolute necessity to scale any product as your company grows. Well to restate that, good product managers are a necessity. They can have a huge impact on your company, positive or negative.
Product Managers are also very hard to find. However, I actually believe you can hire someone into a product manager role even if they have never done it before.
A lot of my advice here is about how you interact with your dev team. There are other areas where you need to be good, but this is the one sure fire way to ensure failure if you don't have a great and trustful relationship with your dev team. After all, there is an unwritten contract all PM's and their dev team abide by: "I will drive the roadmap for the product. You will trust that I will have the right process to pick the right features to focus on, and that customers will love what you build. I will trust that you will deliver my features when you say you will."
So when I look to hire in this role, this is my breakdown of the focus areas I feel are critical for a product manager to be successful.
Be customer facing
Most good product managers came from a customer facing role. Maybe they were a sales engineer, a solution architect, a support person, services person, etc. Whatever it is, they were in the business of solving problems for customers. They learned how to solve a problem for a customer, and were involved in it from beginning to end. It's an essential skill.
Pattern distillation
Now if you have the customer facing experience, AND you understand how to look for patterns in the feedback you get, you could be a deadly PM. You can’t have one without the other. A customer facing person who solves customer problems in a one-off very custom way needs to recognize that this approach will not work. What type of business do we sell to? Who in that business buys, recommends, or uses our product? What feedback are thosepeople giving us about the product? After 10 conversations with the right type of customer, what are the top reoccurring themes?
Understanding of trade offs, ability to make good decisions
PM’s are constantly thinking about 10 features they legitimately need, and can probably execute on 3 of them. Which 3? Why those 3? This analysis and thought process is critical to make sure your team is always working on the most impactful things.
Sleeves always rolled up
As a PM, especially in the early days you may write website messaging, sales enablement content, jump into support tickets, do product demos, visit customers, whatever. Good PM’s happily jump into all this, because it only makes them more effective at their job because they see how the front line engagement with their product actually works.
Know your space cold
You need to know your market better than anyone. Setup Feedly, Google Alerts, or whatever system you use and make sure you are reading your relevant blogs/publications. If you have ever been a PM before and were asked about a competitor to your product you never heard of, that sting you felt is probably enough lesson to make sure that doesn’t happen again. I am not saying obsess over your competitors, but know them. Know the 3 reasons you are different and better.
Know your product cold
This one may confuse you but I swear I have seen it. If you can’t demo and use your product with confidence, immediately go attend your product bootcamp. This also applies to “feature PM’s” - where you own a segment of your product, usually when companies get bigger. Try to know as much of the product as you can anyway. How your features impact the rest of the product will always need to be contemplated.
Understand the cost of what you are asking for
I always cringe on behalf of the dev team when I hear comments like, "well, we could either do X, or, we could Y" followed by an explanation of each. The problem is X costs $10 of engineering time and Y costs $10,000,000. If you put them in the same sentence, you are creating a reputation that you don't understand the implications of your asks.
On the other hand working collaboratively with your dev team on doing that cost analysis before you present anything, or even just re-wording that same sentence to say "hey I have been thinking through some concepts after speaking with XYZ customers. Can I run them by you to see what it means from a dev perspective?" Perfect. Now you are getting at least a ballpark of the implications of what you might be asking for and you can use that in your description of the feature "I know this will be an expensive ask, but I think we need it because of these reasons...".
Get your dev teams back
Your customer facing teams will forever have a laundry list of asks for the product. Sometimes they are great, as they are well thought out and reflective of your ICP and sometimes the ask is something they just heard one time earlier that morning :).
Want to become best friends with your dev team? Say this: "hey please tell our sales and support and services teams to route all product feedback requests through me. I am going to catalogue them and track which customers ask for which things so we have a clear understanding of what our priorities should be." You are doing a few things here. (1) depending on the company, you may have just freed up a substantial amount of the your devs time, and they may buy you beer, and (2) you are showing them that you have a process for prioritizing product features.
Earn credibility with the dev team
Nothing tanks a PM faster than if the dev team doesn’t think they know what they are doing. After all, as the PM you own the roadmap for you product and are responsible for prioritizing what gets worked on.
Look at this list above. Do these things, and your dev team will respect you. When you review the next set of features with them, you will get challenged by them, as you should. If your answers are all backed by customer conversations, market research, and a thoughtful explanation of tradeoffs to get the decision you made, you will get head nods and a motivated team ready to execute. If your answers are opinions backed by an article you read last night, good luck :).
In the beginning of your company, one of the founders will be the Product Manager. Their co-founder will many times be the CTO. Everything I just laid out is the same way founders think about their product too. I have heard people describe PM’s as the “CEO of their Product” and I think that's right. As your company grows, you will eventually hire PM's. This is a key hand off, and following these guidelines will set you up for success both with your co-founder as well as your dev team.
Experience the power of the Guru platform firsthand – take our interactive product tour
Take a tour
