Brad Allen bio photo

Brad Allen

Absent-minded, but always learning.

Email Twitter Facebook LinkedIn Instagram Github

Challenging launches. Product supply visibility. Prioritizing design reviews, market feedback, the project burn rate, and developing compelling value propositions. For recent MBAs, the role of the Product Manager can be very attractive – the opportunity to think about a product’s success from end to end, and (if successful) the excitement of seeing users appreciating in and engaging with your hard work.

Another reason for this buzz is the variation and uncertainty between companies as to what “Product” represents. PM roles change based on company needs, culture, size, and even values. PMs may come into a company with a “Product Manager” title, but find themselves doing more complimentary roles that are generally defined as a “Program Manager”, “Project Coordinator”, or “Product Marketing Manager.”

Having had these discussions with colleagues and having been a part of the Product Management function for two companies, I have seen how misaligned expectations for responsibilities can create winners and losers – for both the organization and an individual’s career progress. I decided to research if there were any patterns that highlight how “Product” is successfully grown within a company, and how the function evolves as an organization scales.

Throughout Fall 2014, I conducted interviews to learn about the PM function at 11 different US technology companies. The full sample needed to represent a breadth of sizes and growth stages (our sample has current sizes from ~30 to ~1,000) and meet 2 of 3 criteria: have an analytic or “data product” capability, have a hardware component and team, and have the primary value delivered through software. The interviewee needed to have direct experience with their organization’s “Product” activities.

In having these conversations, three key considerations emerged for how to balance Product success and Product Manager expectations:

  • Is there a practical framework for thinking about Product Management (PM) talent? (Answer, yes.)
  • How might a CEO or HR executive think about matching PM talent to a company’s needs?
  • How can a Product Manager enter a new organization and quickly establish effectiveness?

This article will explore the third question here; the first and second question can be found in separate posts.

The Foundation: Getting started on the right foot.

Gain quick wins, build a vision, and set expectations.

Although the responsibilities within Product Management can feel disparate, many can be defined as providing a single point of ownership for key company initiatives and effectively identifying and managing the risk inherent in the project. This could include identifying if the company has the appropriate resources at hand, laying out an effective plan for full lifecycle management (such as go-to-market (GTM) and servicing strategies), and balancing product iteration and technical execution during development.

Sometimes some education and socialization is required before developing a market vision. For one company we spoke with, one new product development effort involved the internationalization of a successful domestic product. Beyond tailoring the product to meet the legal and technical specifications in the new countries, research showed that the customer demands would change greatly in a deregulated environment. It became the responsibility of the PM to educate the organization on both the risk and the upside of the project, and articulate a path for successfully navigating a new marketplace. At another, ideas were vetted by mapping the product and market landscape, pushing to some core truths through customer interviews, and socializing the heuristics: for example, “no shopping ever.”

For a technical vision, it is important to be clear in the experience and functionality that the company wants to provide. For example, there is a difference between “working well” and “being delightful”, and both need to be done well. For one company we spoke with, financial transactions needed an operational backend that tracked every dollar as money moved between accounts. Similarly, as the product is tracking risk, the underwriting required flawless algorithms. These must work well. But - to be delightful. the direct customer experience is what is considered! Little things, such as a sound to indicate that “the interaction was successful” will have an impact on satisfaction. In is the role of the PM to hold these together, while giving the impression of a “looming launch date.”

Communicate “risk” clearly: Create systems to mitigate professional gaps.

In any stretch role, it is assumed that the employee is both considered to be high potential and being given responsibilities for which they may only have tangential experience. For Product Management, it is imperative that this is gap is closely managed, as it can directly impact the overall health of the business and the fortunes of the company. One mechanism for supporting this is to first clearly articulate what aspects of the role are considered to be challenging and create a plan for resolving those conflicts.

For an exposure to market risk, this could include conversation around customization and strategies for how agile sprints will be managed. For earlier start-ups, customization can be a siren song of early revenue and user feedback – but can lead to product pigeonholing and imperfect market information. When prioritization and customization can dictated by the maturity of the product, up-front conversations create buy-in and gives PMs more autonomy in decision making when balancing sales targets with engineering upkeep.

Similarly, PMs can use agile management to resolve the economics of their business plan by developing real information for their models. At many large software companies, PMs will follow monthly goals – between hard metrics, such as revenue, and soft metrics, such as DAU and time on site to understand engagement. This process builds rigor and confidence as the product matures and user and product dynamics are better understood.

For an exposure to technical or product risk, the PM can either partner formally with experienced engineers or set up informal mentoring partnerships to manage risk. For a product development process that was scale quickly (a growth of $50MM in one year), the head infrastructure engineer provided strong, regular guidance to young PMs – walking through different options, helping weigh decisions, and pushing the PM to be explicit in how data would be used internally and externally – things that directly had an impact on the structure of the backend. Creating a long- term oriented mindset, instituting a feedback and coaching process, and setting regular check-ins to understand and improve working relationships is important towards building trust and a positive engineering culture.

Be sensitive to team dynamics and raise flags early.

Finally, it is important to note that as a new employee, either at an established company or an early-stage start-up, that the culture of the organization is continually being formed. Provided that many of the organizational issues listed above have been managed well, there can still be a tendency for the responsibilities between senior leadership and managers to delineate between strategy and execution (where much of the “Heavyweight”/”Lightweight” gap exists).

Understanding these tendencies, appropriately identifying them, and developing feedback and performance mechanisms that build trust and accountability are important for organizations to build talent that is capable of taking a holistic perspective to problem solving.