One of the most interesting things about Product Management is the wide variety of things that the role is expected to do and to cover. While we can pretty much all agree that the primary purpose of product management is to discover new and valuable problems that we can solve through innovation and iteration, the very process of bringing those ideas to life often requires that we fill in gaps in the organization that other groups may not understand or even recognize. This is a big benefit to most Product Managers, as we tend to come from a variety of backgrounds and enjoy applying our “jack-of-all-trades” skill set to all sorts of different problems. But it can also be a challenge, especially for a Product Manager starting a new role in an organization -- because the problems one might have had to solve in a previous position may or may not be the same ones you’ll have to tackle in the new one. To accelerate the process of getting up to speed, one tool that any new Product Manager can use is to perform an “audit” of the new organization, to identify any personnel or process gaps that you’re inheriting in your new role. In today's article, we'll dive into a further breakdown:
The classic aphorism, “Physician heal thyself” applies equally to Product Managers -- before you start taking an assessment of the people and processes around you, you need to get the lay of the land with regard to your role in the organization first. We all know that Product Management means different things in different companies, so the first step toward identifying gaps in your new company’s structure is to actually step back and take a close look at how this role is actually defined within the new organization.Hopefully, you’ve done at least a little due diligence ahead of time, before taking on the role -- often a few key questions asked at the right time during the interview process can really shine a bright light on the shadowy secrets of the company. These questions won’t tell you everything, nor will they necessarily make or break your decisions to join, but at the very least you should have an understanding of how the company defines “Product Management” within its four walls before accepting any such role. Beyond that, it’s really key to start on day one getting a grasp of the overall structure of the organization, how the different departments inter-relate and interact with one another, and starting to dig into the politics of the organization (and don’t believe anyone who claims that their company “has no politics”). All of these preliminary explorations are there to ensure that when the time comes to being truly assessing the gaps that might exist in the company, you’re starting with a firm understanding of the underlying framework that supports their efforts. We’re not making value judgments (yet), we’re just understanding how the system is believed to be working, from the people closest to it. We need to understand the theory behind the company’s work before we can truly assess the practice that implements it.
When talking about gaps in an organization, it can be very easy to forget that Product Management is primarily a people-oriented role, far more than it is a process-oriented role. Our role in the organization is almost always charged with heavy responsibilities but no direct authority over those whom we rely on daily to achieve our goals. No matter how good your process might be, if the people with whom you work on a daily basis don’t respect you, you’re not likely to succeed at all. Similarly, if there are gaps in the people whom the company has placed in their organization, you’re not just going to be able to step in and fill them without some established trust and respect from others in the organization -- otherwise, you’ll be seen as “stepping on toes” and blocked from doing what needs to be done.Similarly, a company is far more than just the structure that’s defined by some random organization chart. It can be really tempting as a new Product Manager to short-cut our analysis of the people within the organization by just taking a look at the org chart and seeing what gaps we think exist. But that’s short-sighted and unlikely to reflect reality -- just because there’s a gap in the org chart doesn’t mean that there’s a gap in practice within the organization. Particularly in smaller organizations, Product Management isn’t likely to be the only role filled by jacks-of-all-trades; it’s likely that org chart gaps are actually being filled by someone, somewhere. And that’s what we can use them for -- to identify those areas that we can note for follow-up with others in the organization, to take the theoretical org chart and bounce it off of the day-to-day reality of the company.The process of finding gaps in positions or personnel is one that takes time, effort, and not a small amount of savoir faire. The advantage that you have when starting a new position, however, is that you’re able to blend in your discovery efforts with your overall learning process -- you can use the standard “get to know you” meetings to being to build a deeper understanding of who does what, where those tasks roll up in the organization, and where there are real gaps versus gaps already being filled by others.
As much as we need to be able to effectively manage our relationships with people in our organization, the flip side of the Product Management coin is that we’re often also deeply involved in the definition and implementation of process in our organizations. This makes a lot of sense, as we’re one of the hubs around which the spokes of the company tend to revolve. As a result, we often have insight as an outsider into the various issues that the different teams we work with struggle with on a daily basis -- we constantly see the outcomes of those issues as we’re trying to push our product ideas through to fruition. It’s a position in the organization that comes with great power, and with all apologies to Spider-Man’s Uncle Ben -- with great power comes great responsibility.Especially as a new Product Manager, we can be very susceptible to a vicious form of recency bias, and start from the position that anything that’s “different” in the new company must be “dysfunction”. We might want to impose strict Scrum practices when we see what appears to be “Scrum-but” (as in, “we do Scrum, but…”), or to jump to the conclusion that the way requirements are handled is backwards and dysfunctional. This, however, is a path that leads to trouble -- first, you’re likely new enough that you haven’t yet built the reputation to start making such huge waves from the get-go. Second, we should understand that just because something is “different” doesn’t mean that it’s necessarily “dysfunctional”, and the corollary that just because something worked for us before doesn’t mean that it’s going to work in the new organization. We need to take time to understand, assess, and realistically examine what’s going around us. Rash decisions will only serve to undercut your burgeoning reputation.This doesn’t mean that we shouldn’t use previous success to inform future efforts -- only that we need to be aware of our biases and spend some time actually watching the processes unfold before we start to make proposals or plans to change the way things are being done. Nobody likes the guy who just walks in the door, announces that “you’re doing it wrong” and immediately wants to change everything. And we can’t afford to be seen as that person, we need to be seen as the data-driven, outcome-oriented, reasonable voice of influence and improvement in our organization. We build that reputation by working with the teams and helping them to understand the weak points in their process, offering our own suggestions as the natural progression of a consultative relationship.
Being a new Product Manager is a maelstrom of chaos -- it can be difficult sometimes to know what the next hour is going to bring, much less the next week or month. But to some degree we can exert a modicum of control over that chaos by taking every opportunity we can to gain a better and deeper understanding of how the company works, how they make things happen, and where they have known (and unknown) gaps in their organization. As we build this mental map of the landscape, we can simultaneously identify those people, teams, and processes that are likely to be more open to change and improvement. We can identify small wins which we can use to build a reputation as a successful change agent, and expand our gap-filling efforts slowly until the company itself is running as a well-oiled machine -- or at least as smoothly as possible!