Ideal Company for Product Manager
Aspiring PMs should consider three primary factors when evaluating a role: core competencies, emotional intelligence (EQ), and company fit. Beyond shipping new features on a regular cadence and keeping the peace between engineering and the design team, the best PMs create products with strong user adoption that have exponential revenue growth and perhaps even disrupt an industry.
There are core competencies that every PM must have — many of which can start in the classroom — but most are developed with experience, good role models, and mentoring. Some examples of these competencies include:
- conducting customer interviews and user testing
- running design sprints
- feature prioritization and road map planning
- the art of resource allocation (it is not a science!)
- performing market assessments
- translating business-to-technical requirements, and vice versa
- pricing and revenue modeling
- defining and tracking success metrics
These core competencies are the baseline for any PM, and the best PMs hone these skills over years of defining, shipping, and iterating on products. These PMs excel at reflecting on where each of these competencies have contributed to the success or failure of their products and continuously adjusting their approach based on customer feedback.
A good PM may know the dos and don’ts of a customer interview, but the best PMs have the ability to empathize with customers in that interview, are tuned into their body language and emotions, and can astutely suss out the pain points that the product or feature will address.
Relationship management. Probably one of the most important characteristics of a great PM is their relationship management skills. By forming authentic and trustworthy connections with both internal and external stakeholders, the best PMs inspire people and help them reach their full potential. Relationship management is also vital in successful negotiation, resolving conflicts, and working with others toward a shared goal, which is especially challenging when a PM is tasked with balancing the needs of customers, resource-constrained engineering teams, and the company’s revenue goals. Authentic and trusting relationships within an organization can lead to more support when additional funding is needed for a product or when an engineer must be swayed to include a quick bug fix in the next sprint. Outside an organization, these skills could encourage existing customers to beta test a new feature for early feedback or to convince a target customer to try the MVP of a product still in stealth mode. These relationship skills can also be what makes the difference between having irate customers because of a bug introduced into the product and those who say, “No worries, we know you’ll fix this!”
Self-awareness. PMs must be self-aware so as to remain objective and avoid projecting their own preferences onto users of their products. If a PM is in love with a feature because it addresses their own pain points — PMs are often super-users of the products for which they are responsible — they may cause a user to say they love it too. If not self-aware, a PM may push to prioritize a feature they conceived even when all the customer interviews and evidence are stacked against it. This lack of self-awareness could derail more important priorities or damage the PM’s relationship with engineers, who may lose confidence in their PM when the feature isn’t readily adopted by users.
Self-management. Being a PM can be incredibly stressful. The CEO wants one thing, the engineering team another, and customers have their own opinions about feature priorities. Managing tight deadlines, revenue targets, market demands, prioritization conflicts, and resource constraints all at once is not for the faint of heart. If a PM cannot maintain their emotions and keep it cool under pressure, they can quickly lose the confidence of all their constituents. The best PMs know how to push hard on the right priorities, with urgency but without conveying a sense of panic or stress. These PMs also know when to take a breath and step away to regroup.
Social awareness. According to Goleman, the competencies associated with being socially aware are empathy, organizational awareness, and service. PMs must understand customers’ emotions and concerns about their product as much as they understand the concerns of the sales team on how to sell that product, or the support team on how to support it, or the engineering team on how to build it. PMs have to have a deep understanding of how the organization operates and must build social capital to influence the success of their product, from obtaining budget and staffing to securing a top engineer to work on their product. Finally, social awareness ensures the best PMs service their customers with a product that addresses their jobs to be done, which is ultimately what drives product-market fit.
If the best PMs have well-developed core competencies and a high EQ, does that mean they are destined for success no matter where they work? Not necessarily. In fact, taking these skills and personality traits and applying them to the right company is what will ultimately guarantee success.
Here are a few of the key areas in which companies differ in what they want from a PM:
Technical skill. The type of product, who uses it, and the type of company will determine how technical a PM needs to be. For example, Google requires PMs to pass a technical skills test regardless of what product they’ll work on. If the company is building a SaaS CRM, there may be more requirements around experience with go-to-market and customer lifecycles than around how the product is built. By contrast, if it’s a data science product with machine learning algorithms and APIs, the role may require a lot more technical depth to not only understand how to build the product but also how to talk credibly with the customers who will use it.
Company philosophy about PM. Every company has a different philosophy about the product development process and where PMs fit into that process. Below are the three most common types, with pros and cons:
- PM drives engineering. This is a “throw it over the wall” approach, where PMs gather requirements, write the quintessential product requirements document, and hand it off to engineering to spec out the technical requirements. Contemporary organizations may do this process in a more agile and collaborative way, but the expectation is that PMs know best about what customers need and engineering is there to serve.
- Engineering drives product. More technically oriented product companies (cloud, big data, networking) tend to be engineering-driven, where engineers are advancing the science in their domain and PMs validate solutions or create front end access points (UIs, APIs) to tap into this new technology. There can be a collaborative relationship and feedback loop between customers, PMs, and engineering, but typically PMs are serving engineering in these companies.
- The PM-engineering partnership. In these cases, there is a strong yin-yang between PM and engineering, with joint discovery, decision making, and shared accountability. Engineers join PMs in customer interviews, and PMs are in sprint meetings to help unblock tasks or clarify requirements. But the two roles respect the line where one starts and the other stops. PMs understand what’s being coded but don’t tell engineers how to code, and engineers have empathy for customers’ needs but leave the prioritization to the PMs.
Stage of company. The role of the PM at a startup is far more likely to be responsible for “all the things,” whereas at a mature company their role will be more distinctly defined.
- Startup. Beyond discovery, definition, and shipping, PMs may also be responsible for pricing, marketing, support, and potentially even sales of the product. These PMs thrive in a scrappy environment and are comfortable with ambiguity and frequent changes to direction as the company works towards product-market fit and learns to operate at scale.
- Mature company. The PM may have a narrower scope and have coworkers who handle pricing, go-to-market strategies, and so on. And they are likely to be part of a larger team of product managers.
Founder/CTO/CEO relationship with PM. Especially in earlier-stage companies, it’s important to know how involved the founder/CEO/CTO is in the product process. If they are deeply involved, the PM role may play more of a support role, to flesh out their ideas or validate concepts with customers, versus conceiving and driving ideas of their own. This can be great fun for some PMs who enjoy partnering with founders and C-level executives and collaborating on the product evolution.