There is an abundance of great advice offered to new/aspiring Product Managers. There is also some easy to spot bad advice doing the rounds. The most dangerous type, however, is advice that looks good at the surface but is actually bad. I like to call such advice as, ‘terrible advice’. This post calls out some pieces of terrible advice that are very commonly shared with new/aspiring PMs. I have personally read/been told all of these at the beginning of my career and believed a lot of these until some experience taught me better. Here goes, “You need to be technical as a PM, otherwise your engineers will tell you it’ll take years to get simple things done.” A classic early-career PM question is, “do I need a technical background to land a PM role?” This is a heavily debated topic and the broad consensus is that it is necessary for some organizations and roles while not so in others. Hence, the premise in the first part of the above sentence could be true depending on the context. However, the reason presented in the second part of the sentence is a major fallacy. Think about the implications of the statement, you’ve reached a point where you need to challenge your domain experts aka your primary collaborators aka your engineering team’s judgment on a topic of their expertise. This means you either have some reason not to trust them or they have reason to deliberately mislead you. At this point, is being technical/non-technical really going to make a difference? PMs can and should work together with engineering on scoping constraints and be able to drop/work around parts that bloat up the effort required. However, blatantly challenging estimates made by engineers is a pretty bad idea. The need for mutual trust and respect for each other’s expertise and judgment is far greater in the long term than cutting scope estimates on a singular feature. “Don’t take salespeople seriously. They constantly push for features that singular customers need.” This is a gross overstatement. Some bad salespeople do match those described above. However, most of them, especially great salespeople are amazing voices to listen to. They are a gold mine of information about your customers since they interact with them a lot more than you do. They have a clear understanding of the customer pain points, goals and workflows. Very often I have found salespeople to be more familiar with key parts of the product’s UI than PMs. Ultimately, they do have to demo the product to customers every day. I have also seen them find creative ways to solve customer pain points that the product doesn’t natively support at this point. For instance, they could convince the customer to write 100 lines of python code since you don’t have an API yet. Yes, you may occasionally find yourself listening to feature requests that may not align with your roadmap. However, you don’t necessarily have to go build everything they tell you to if it doesn’t make sense. I’ve found that good salespeople are always happy to hear you explain why something can/can’t be done. The merits of seriously considering what your salespeople tell you far outweighs any time lost listening to singular feature requests. “Give your designer mockups for your vision and he/she will convert it to hi-fi designs” In an early-stage company you may not have the luxury of hiring any UX designers at all, let alone a UX designer dedicated to your product. In such cases, you should most definitely double up as the mockup and perhaps even the design person. However, if you do have UX designers on your product team and have been told to take mockups to them, you are missing out on a large part of their strengths. Don’t get me wrong, having a vision for a product and an ability to communicate it in visuals is always appreciated. However, if you find yourself defining the precise form factor of the product before your designer, you are smothering their inputs. Good UX designers have a comprehensive understanding of the users pain points, motivations and behaviors. They can explore the problem space at great depth, test diverging solutions before converging on a preferred mockup. If you start by handing your designer a mockup, you’ve either lost all of that exploration phase or spread yourself too thin by doing things he/she can probably do better than you. As a PM, you should bring your UX designers into the conversation early on. Help them build empathy with your customers and the pain point you are collectively trying to solve. If you want to truly see great designs for your product, the worst thing you can do is manufacture creative bias by hacking up half-baked wireframes that they have to abide by. “A peer review or competitive analysis is the best starting point for your product/feature” This reasonable-looking statement is often the birthplace of bad products/features. I don’t mean to undermine the importance of being aware of your competitive landscape or conducting a peer review when in the solution space. However, your starting point should be a persona and a hypothesis that solves a pain point for them. Beginning with a peer review often encourages you to jump to a solution without enough emphasis on understanding the problem. This leads to entire PRDs created solely based on features that a competitor has. Whether the feature actually solves a problem for your customers is often subject to little or no validation with customer interviews or implicit data signals. Most products and customer use-cases are not one-size-fits-all and what works for a competitor’s customers (or product) will likely not work for you. In the long-term, it makes a lot more sense to be customer-focused than competitor-focused. Being competitor-focused might make your product a worse version of your competitor at best while being customer focused will certainly make your product a better version of itself. “Read product manager job descriptions to understand what the role involves.” This one’s a bit of a stretch, reading job descriptions to get an idea of what the job involves is actually good advice. However, treating these as a comprehensive list of responsibilities is a problem. For most job roles, large companies are typically known to have well-defined responsibilities while startups are known to require you to wear multiple hats. However, when it comes to Product Manager roles, both large companies, as well as startups, require you to do a lot more than can be found on a Product Manager job description. You may get a few helping hands at larger companies in the form of dedicated PMMs, UX researchers, etc. However, you are still responsible for the outcome of your product. If something needs to be done and somebody else isn’t available to do it, it is your job. You will frequently find yourself switching between tasks, doing things that aren’t the most glam and surrounded in ambiguity. You simply need to embrace it. Building good products is hard, your hypotheses will be proved wrong multiple times, and will have to correct course. Hence, the real job description for a Product Manager’s job pretty much is, “do whatever it takes to make this product more successful”. You won’t really see that on a job board. That was some of the terrible advice I have received. Please feel free to add more bad advice you’ve received in the comments’ section below. Liked this post? Please let me know by sending a message here .
