As a leader in product management organization, one needs to think about building a great product management team and getting the best out of their product managers all the time. Whenever I have brought up this topic most of the conversation revolves around ‘building the right culture’ in a team. While the right culture is an essential ingredient of any team, building a great product management team must start with the acquisition of the right talent for the role and the company. Selecting the right candidates into your team can foster an environment of creativity, productivity, and collaboration, and prepare the ground for the success of your organization.
Most of the companies do a pretty decent job in identifying a talent based on Job-skill match. However, the architects of a “great product management team” differentiate themselves by bringing additional factors into their decision-making process. Factors such as what kind of product is a company building; does it require a higher technical competence in my PM; what kind of company philosophy about PM exists in my organization; what kind of soft skills such as Emotional Intelligence does my organization values; and what’s the current stage of my company - Startup Vs Mature. These were some of the questions I grappled with while building a product management team from the grounds up in Alpha Ori Technologies. Thanks to our diligent efforts, today we can boast about being a top-class Product Management organization, and if you allow me some indulgence - the Best Product Management Team in Maritime Digital Transformation. Having done it a few times across multiple technology companies, I wanted to share some of my thought process in building a product management organization. I will spare you the generic PM core competency exercise as it’s a common knowledge, and rather focus on areas that often tend to get overlooked but are critical in building a great product management team.
How Technical should be the Product Manager in my organization?
Let’s start with technical competence requirements since one grapples with this common question all the time in a technology company - How Technical should be the Product Manager in my organization? I have also heard it countless times when engineers from my own organization wanted to be product managers due to either a “true calling” or a certain allure attached to the position of product manager.
The real answer is - IT DEPENDS. No, it’s not a cop-out. I truly mean it. For example, it depends on what kind of product is a company building. Let’s dig in a bit further to find out what I mean.
The type of product, who uses it, and the type of company will determine how technical a PM needs to be. Google requires PMs to pass a technical skills test regardless of what product they’ll work on. It works for Google as they view themselves as innovator where a breakthrough and moonshot projects are valued more than user feedback.
However, if a 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 coded. Even in one of our own product line in Alpha Ori Technologies, User Experience is valued the most and therefore, we focus on getting domain experts as product managers who have been the end-users of such products in the past and can build deeper relationships with current users of the product. 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 the product is built but also how to talk credibly with the customers who will use it.
That said, having a basic technical understanding of what is under the hood and mastery of the tools that PMs use is definitely important for the role, irrespective of the type of product or the type of your company.
What is the company philosophy about PMs in an organization?
It’s difficult to categorize an overall company philosophy about product managers since a company can have various products and the philosophy may vary from one product to another. Nonetheless, here are the three most common approaches practiced in the industry.
Product Manager drives engineering: In such an organization, the PMs are the domain experts and stay in close contact with customers and end-users. The PMs gather requirements, write the product requirements document, and hand it off to engineering to spec out the technical requirements, LOE (level of effort) and Sprint planning in case of agile development. The expectation is that PMs know best about what customers need and Engineering is there to meet the requirements. This helps Engineering focus on coding without any distraction. However, engineers can lose sight of the big picture and do not develop empathy for customers, which can lead to a poor user experience unless PMs are on top of UAT and the engineering follows iterative process focussed on user experience. This can also lead to unhealthy tension within the organization when Engineering wants to prioritize technical infrastructure work over customer requirements.
Engineering drives product: In many companies that are at the cutting edge of technology (i.e. Cloud, Semiconductors, Networking, Big Data Science, Bio-Tech) the entire product strategy revolves around R&D and Engineering, where engineers are advancing the science in their domain and PMs figure out how to create solutions or front end access points (UIs, APIs) to tap into the new technology. For example, let’s consider 3 major milestones of a high tech company - Qualcomm. Engineers at Qualcomm invented CDMA, created the world’s first 40 band LTE modem, and invented a dual-core chipset for faster processing. In each case, the PMs validated the solutions and figured out a go-to-market strategy for a lucrative market. All three cases mentioned above resulted in a multi-billion dollar business for the company.
There can be a collaborative relationship and feedback loop between customers, PMs, and engineering, but typically PMs are following Engineering lead in these companies. In such an arrangement, breakthrough technology can offer customers products they didn’t even know they needed. On the flip side, it creates an opportunity for engineers to chase the “shiny new thing”, or over-architect a solution before getting customer feedback. PM input on priorities is ignored, which sometimes includes the most basic needs of customers.
Partnership (PM - Engineering) drives product: This is based on joint discovery, joint decision making, and joint accountability. Engineers join PMs in customer interviews, and PMs are in sprint meetings to help 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. Sounds like panacea? Utopia of product development - Better design processes leading to a more positive user experience; higher performing teams with improved product velocity, quality, and, typically, happier customers. There is nothing to dislike here. Wish it were that easy! While proponents swear by the benefits the detractors say it rarely results in breakthrough innovation, the product launch is always behind schedule and tensions simmer between PM and Engineering as they constantly get into other’s territory.
This model is highly favored by academicians but finds many skeptics in practice. Just like “Merger of Equals” was favored by B-School professors at one time but found few takers in the market after some high profile misadventures (Remember Sprint-Nextel and HP-Compaq mergers?) At Alpha Ori Technologies, we knew from the beginning that PMs will drive Engineering, given the domain expertise requirements and an industry which may not be considered mainstream for software engineers. Therefore, we emphasized on selecting PMs who had cross-functional expertise - Maritime technology and Software engineering.
What’s the current stage of my company - Startup Vs Mature?
The role of the PM can differ quite a bit based on the stage of the company. In a Startup, where ambiguity is the norm, they are generally responsible for “everything” whereas their roles are much more defined in a mature company.
Mature company: In a mature company, the PMs have a well defined, albeit narrower scope and have other colleagues who handle product marketing, pricing, go-to-market strategies, etc. Therefore, they can focus on building a strong relationship with customers as well as engineers ensuring the product is built as per market demand. Due to product-market fit more or less established there is an established customer base and a baseline to work from rather than guessing if there is a product-market fit. You are likely to find standard development practices in the organization where senior members of the team emphasize on best industry practices. Of course, such stability comes at a price - less exposure to company strategy, less influence on the product as you are one of the many voices of customers, more company politics.
Startup: PMs in a startup may be responsible for a plethora of activities. In addition to the traditional role of discovery, definition, and launch, PMs may also be responsible for pricing, marketing, support, and potentially even sales of the product. These PMs are deeply engaged with top management as well as customers in defining product strategy. The general environment in such companies is scrappy and ambiguous, and there are frequent changes in direction as the company works towards product-market fit and learns to scale their product. PMs feel more empowered as they can see the direct impact they are making in the organization. They also have more influence and authority over company resources. On the flip side, they may be overworked, lack of best practices can create gaps and rework. Budgets are typically tight, and PMs may not have the requisite experience to succeed at some of the things they’re tasked to do. Here again, AOT being a startup, we handpicked PMs who could thrive in ambiguity - especially in the beginning, change and adapt quickly, didn’t mind getting hands into new areas and were quick learners.
There are, of course, many other factors to consider for any role, such as the type of product you are building (B2B, B2C, industry), team and manager compatibility, the overall company culture (diverse, inclusive, flexible work hours, remote working), and, of course, the compensation and benefits expectations of prospective candidates. However, if you are striving to build a great product management team, consider all of the above before hiring the next PM on your team. Developing core competencies will be an ongoing activity throughout PM’s career (you can train them on the job too). But where they work, how they work, and who they work with and for will ultimately determine their as well as the team’s long-term success. Happy building a great PM team!
Sam is the Chief Product Officer at Alpha Ori Technologies (AOT). Alpha Ori is a B2B Technology company operating in IoT (Internet of Things), Ship ERP (Enterprise Resource Planning) and Big Data Science. For any comments reach out to email@example.com