The One Question You Need to Answer as a New Product Leader

The One Question

When you’re starting a new role as a Product Manager in a company, there’s a lot of roiling chaos that comes along with the new role. You’re trying to hit the ground running as best you can, meet new people every day, get up to speed with product strategy, grasp the processes and the differences between what’s being told to you and what you’re seeing in reality. It can be an arduous journey from your start date to the day that you feel like you’re really contributing. And all of that is important — but more important to your success is finding the answer to one basic question: “What could inhibit my ability to succeed?” The answer to that question is by far the most important thing you can learn in your first 60-90 days in a new Product Management role.

What Could Inhibit My Ability to Succeed?

It seems like an obvious question, but it’s one that’s very often overlooked in the maelstrom that is our first months in a new role. And while it might sound like a generic question that everyone should consider, it’s particularly important for the Product Manager who leads through influence and not authority. Unlike other leadership roles, we’re not generally empowered to just tell people what to do; and unlike most individual contributors, we don’t directly have someone telling us exactly what to do or how to do it. When the teams, processes, people, and politics of the organization all align with our efforts, this isn’t a problem. But when they don’t, it can throw a serious wrench into our well-laid plans. The sooner we know what the likely candidates for disruption are, the sooner we can create and execute plans to mitigate their influence on our work.

The first step in identifying the aspects of the business or company that might throw roadblocks in your way is to think through all the possible areas that such roadblocks might come from. These could include people, processes, policies, politics, vision, existing roadmaps, customer commitments -- the list can be a very long one. But the more comprehensive we are in starting our analysis and collecting data on the areas we are most concerned about, the more likely we are to foresee trouble and the better prepared we can be to offset its impacts. At the same time, we don’t want to create some kind of encyclopedic catalog of every single part of the business -- we should start with a rough sketch, and build the model out where we think it needs more detail or depth, leaving most of it at a high level.

The next step, once you’ve identified the general areas of the company that you’re interested in understanding, is to analyze each one to assess how much control you’re likely to have on that area. While it’s very true that Product Managers generally do not have direct authority to make changes, we’re still capable of exerting control through the use of indirect authority to influence change. For example, the actual development process (whether that’s Kanban, Scrum, or some form of Waterfall) is often “owned” by the development team, but by virtue of being the primary input into that process, and a key stakeholder in it, we often have a very high level of influence on it. Conversely, we rarely have any strong influence over the workings of the Sales team, especially at the beginning of our tenure at a company. Knowing where you have the ability to exert some control -- be it direct or indirect -- is essential to understanding what’s likely to bite you in the future.

The last thing that we need to consider is how much each of these areas is likely to impact our efforts -- not everything that happens in the organization necessarily impacts the Product Manager’s work in the same way. Rather, some teams and some dysfunction will have an outsized effect on the Product Manager’s role, while others will have minimal impact. We need to understand these potential impacts in order to really take the next step -- prioritizing them according to their urgency, importance, and likely success in effecting change.

Prioritizing Potential Problem Areas

There’s a very famous quote by President Dwight D. Eisenhower which has led to a truly useful model for dealing with the confluence of urgency and importance: "I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent." This concept is essential for Product Managers to understand and apply not only in their first 90 days but also throughout their careers. People come to us all the time with things that are “urgent” to them but which are frankly not very important to us in the moment. This quote led to the development of what is referred to as the “Eisenhower Model” of prioritization, which directly applies to the things that we think might inhibit our success in a new organization. The model looks something like this:

We can (and should) apply this model to the things that we think are likely to affect our ability to succeed in the organization -- those things that we deem to be both important and urgent require immediate action, while potential disruptors that we deem to be neither urgent nor important should be set aside until we change our assessment in the future. The use of the “Eisenhower Model” to determine whether action should be taken and who should take it is a great tool for Product Managers throughout their work, but here it serves to focus our efforts on those things that are going to have the biggest impact on us in the near term.

While the “Eisenhower Model” is a great tool, it’s a blunt tool that allows us to quickly create buckets of work -- but even within those buckets, we’ll need to further prioritize our efforts -- there might be 20 things that wind up being both urgent and important, and we can’t possibly take action against all of them at once. If there are more than three or five things in your buckets, you’ll likely want to stack rank them, so that there’s a clear second-level priority beyond just urgency/importance. In doing this, there are a couple often-overlooked considerations that Product Managers should take into account -- let’s call those “time vampires” and “zombie efforts,” for color.

Certain people in your organization will, whenever possible, suck your time out from under you. They might be overly chatty, might demand ever-increasing amounts of data and analysis, or constantly engage in extreme cases of “what if” and “devil’s advocate” discussions. These people are the “time vampires” in your organization, and engaging with them without a clear plan and goal in mind will rarely result in solid results. It may take time to figure out who these people are in your organization (though generally they’re pretty obvious), but once you do it’s essential to ensure that you consider these people in your prioritization and planning efforts.

There’s another aspect of organizations that can have devastating impacts on our abilities to understand and protect ourselves from potential impediments to our success -- the “zombie projects” that never truly die but also never really succeed (or fail). In some organizations, you might see Agile or Scrum fall into this bucket, or maybe it’s test-driven development, or possibly “value-based” sales strategies. As a new Product Manager, you won’t necessarily know what these projects might be -- and if we wind up accidentally reviving one of them, we might get stuck in the morass that they usually create. People want the dead to stay dead, and “zombie projects” aren’t likely to help us remove impediments as much as they are to drag us down with them. Be aware of this concept, and as you’re prioritizing the type of impediments you want to tackle, ensure that you’re watching for signs of the living dead projects just waiting to wrap their cold hands around you.

Make a Plan to Tackle Potential Blockers

Once we’ve identified the potential areas that might prevent us from being successful, and we’ve gone through some level of analysis to assess the priority of those, we need to prepare a plan to tackle them. This shouldn’t be terribly difficult for most Product Managers -- we are, after all, planners by nature and by profession. There are a few considerations above simple priority that we should take into account when building that plan out, however.

First off, we want that plan to reflect our ability to change the things over which we have control (even if that control is just through a high level of influence). When we’re trying to effect change, it’s often critical that we start out with small efforts that will have a big win associated with it. This proves that we actually do know what we’re doing and allows us to build on that success with larger efforts. We want to ensure that as we’re working to remove blockers to our own success, that we don’t at the same time stir up dissent or objections in other places, with other teams. Starting off with those things that we have more direct control and influence over hedges our bets to be less likely to cause even more impediments to arise.

Next, we want to make sure that we understand how we’re going to influence change in areas over which we do not have direct control or influence. Many of these areas might not be things that we’re actually capable of knocking down in our first 90 days, but simply being aware of them and having an actionable plan to tackle them puts us ahead of the game. To remove these impediments to success, we’re going to need to rely on building our social capital with those who are in control -- through establishing a strong relationship built on mutual trust and respect. As we get more comfortable in our organization, we’ll find that we’re more successful in removing these impediments, but it’s likely to take patience to ensure that we’re squashing blockers and not creating new ones.

Lastly, it’s important as Product Managers that we really take to heart our prioritization of the potential blockers that might exist in our organization. More than any other role in the organization, a Product Manager needs to be very careful in picking which matters are worth fighting for and which are more important to drop (even if it’s just in the moment). Because our entire job revolves around leading through influence, we can’t afford to stand on principle just to do so -- if that comes at the cost of our reputation in the organization, we’ve traded pragmatism for principle. Sure, that’s sometimes the right thing to do, but only when we do it knowingly and intentionally. Most issues and impediments really aren’t worth making a last stand over -- there are often alternative means to achieve our goals. Knowing how to pick which battles are worth fighting, and which should be tabled, is an essential skill for any Product Manager to develop.

Identify, Assess, Plan, and Execute!

What seems like such a simple question on its face turns out to have a myriad of considerations and potential consequences, particularly for a role so dependent on establishing and maintaining strong relationships throughout an organization. But the worst thing that any Product Manager can do is remain willfully blind to those impediments posed to their success by the structure, people, or processes of their organization. There will always be misalignments and dysfunctions, and at the very least identifying them allows us to be aware of their presence and their looming threat, even if we don’t actively and immediately take action to remedy them. Knowing and understanding really can be half of the battle, and it gives us a direction to look deeper for an alternative path to success.