Too Many Product Managers End Up as Project Managers

Transitioning into product management can feel like being air-dropped into a war zone. From the moment you hit the ground there are new people and ideas bombarding you from every angle, and everything seems to be on fire. There is no clearly defined way to reach your destination, but you know you can’t just sit there. For most new product managers starting out, this is a critical moment for your career and the habits you build out as a product manager.

But…why project managers?

That’s a great question! One of the most difficult things about product management is figuring out your responsibilities, and the responsibilities of others. Project management in particular has a high degree of overlap, and it doesn’t help that most companies still view the two roles similarly.

I frequently see product people fall into the trap of either doing someone else’s job, or mistakingly spending too much time on tasks that don’t actually help move the product forward. Below I’ll cover some common pitfalls I’ve encountered in my career that lead new product managers to act like project managers. By understanding these pitfalls new product managers will better understand the real value their job is supposed to provide.

Pitfall 1 — Never Creating or Owning a Product Vision

Let’s start with defining what a product vision is before diving in too deep. Product vision is the long-tail goal of what you want to achieve, the ultimate end-state you want your product to be. This can apply to owning an entire platform, all the way down to owning a small feature. More importantly, a product vision will always exist, even if you don’t know what it is! How?

It’s actually pretty simple, if you’ve never heard or explained the product vision to someone, it’s whatever they perceive it to be. From the day you were hired on as a product manager, your product already had stakeholders (surprise!). Sales has been trying to sell features that haven’t shipped yet, the CEO is selling features you haven’t even heard of yet, and clients were promised all this a year ago.

The underlying problem? When there’s not a shared vision, perceived vision leads to perceived product focus, which further devolves into everyone demanding different things for what should be a common goal. This puts a new product manager at a crossroads — do you give into stakeholders and optimize the demands coming in, or is there something else you can do?

An existing vision is easy to go along with, even if you know it isn’t the best one to pursue. Especially if the loudest demands are coming from executives or senior leadership. Presenting new info could make it seem like you’re challenging the status quo, which is uncomfortable.

So how does this relate to project management? When a product manager loses the ability to identify and unify the company on their long-term vision of a product, you switch from satisfying a problem in the market to meeting specific success criteria (releasing a feature request). This usually ends up with the product person doing a lot of work that never really evolves the product holistically, and ironically still leaves most stakeholders disappointed.

More critically what happens if you don’t have a North Star (product vision)? For most new product managers, this leaves them searching for a way to gauge their contribution to the company, which leads to the second pitfall…

Pitfall 2 — Mistaking execution for progress

People don’t do well with ambiguity, especially if they don’t feel in control of their destiny or purpose. Maybe you were someone like me who started in product by coming in from an operational role with clearly defined responsibilities and scope. Life to this point has had clearly defined goals, but once you become a product manager your days start to look a lot more like this:

So what happens? Most people will gravitate toward something that makes it feel like they’re adding to the cause. For product managers without a product vision, this tends to results in some of the following behaviors:

• Spending your time prioritizing a backlog with tickets older than your professional career (also known as a Feature Factor)
• Comparing roadmap software because your roadmap is “too big to display in a meeting”
• Writing product requirement documents that rival the length of War & Peace

What’s the problem? Output is a limited-time proxy for progress. If a project manager delivers a project on-time, as spec’d, and no one uses it — they’ve still done their job of delivering something within a specified time. If a product manager does this, they have failed miserably at their job.

If you are a product manager and can write out a JIRA feature with the same detail as an engineer, you’re not spending enough time talking to customers or understanding where the market is going. Rearranging your short-term roadmap for the ‘n-th’ time isn’t going to save you from building a product that no one wants. Plus, if you don’t even know the end goal (product vision), how do you even know if you’re going the right way?

So as a new product manager you see the situation you’ve put yourself in and recognize the need to change, but how? The answer is define a product strategy, which brings us to pitfall #3…

Pitfall 3 — Treating the product strategy like a voting exercise

So product strategy sounds cool, but what exactly is it? Product Strategy is the tactical way a product manager intends to reach their product vision. Unlike product vision, product strategy requires taking into account the limited resources and time a business has to prove a concept. Product strategy is not perfect either, and will likely change over time. The point is that it produces actionable steps to move you toward your product vision.

Just like project management, product strategy includes optimizing limited resources to deliver a piece of work. The difference is that a project manager will be judged by their ability to best deliver a project based on those resources, while a product manager is judged relative to product and company goals. While you share similar constraints, the expected outputs are very different.

So if a product manager is judged based on company goals, why not simply take the list of requests everyone has and do them in stack-rank order? Sure it may suck, but after a few hours of holding your key stakeholders hostage you should have a nice prioritized list, right?

While this may seem innocuous, there are a slew of issues with this. Roger Cauvin has an excellent post about this from a few years ago that highlights some of the key points:

• Without a unified vision of what is important, feature prioritization becomes horse trading
• What happens when the list ultimately changes? Now you have to update every single stakeholder because there was no cohesive vision
• What happens when the most important thing ships and it wasn’t important? How does that affect your relationship with stakeholders at position 2/3/4?

The problem? People in your company all have different goals, and siloed goals tend to compete with each other. Voting polls or an attempt to ‘magic formula’ your way to a product via a spreadsheet doesn’t create a better product. In fact, voting sacrifices organizational cohesiveness and product strategy for short-term decision making.

A product manager making this mistake will walk away not fully understanding how agreed upon priorities relates to users and products. This is dangerous — if a product manager doesn’t understand why they are building something, neither will the engineers. Sales won’t understand the benefit to their clients, marketing won’t understand how to position it, and the product will ultimately suffer.

So now that we’ve gone over 3 pitfalls, how do we address them?

Solution 1 — Obsess over the problem you’re solving, not the solution to the problem

If a product manager does not properly understand the problem they are trying to solve, it will cascade down to everything else you do. If you build something without understanding what the problem is or who the problem is experienced by, then you’ll build something no one wants. Plus a solution can change over time, even if the problem remains the same.

By finding out the true problem(s) a user is experiencing, you create a commonly understood problem the company is collectively trying to solve, vs. a solution to something that may not actually be a problem in the first place.

You’ll also find that if the problem is well understood, you don’t need to resort to blind feature prioritization or pet projects. Instead, everything becomes a question of whether something adds or detracts from solving the problem at hand. By doing this, you are able to build toward a vision that will live beyond the scope of any single project.

Solution 2 — Communicate in ways that are meaningful to your stakeholders

Product management is very much a game of psychology. It’s impossible for a product manager to deliver any kind of product without a team to execute on the vision. Not only that, but you need to unite a diverse group of people with different talents and motivations toward an ambiguous future state (the product vision). But how can someone unify people with different goals towards a common path?

One of the simplest and most impactful things that will accelerate your career as a product manager is to learn and care about the goals of other stakeholders. Paul Jackson wrote a great article on this a few years back that I would highly recommend reading. Yes, that means actually going to people, asking them what success looks like for them, and actively listening to what they have to say. Internal stakeholder goals are just as important as external stakeholders because it can affect your ability to deliver the solution to the problem.

By understanding a problem, how others understand and talk about the space, and the things they need to be successful, you can start to have conversations with people in a way that is meaningful to them. By showing people you care, you’re giving them a reason to put their trust in you to help them succeed.

But how do you go about communicating in ways that people from different backgrounds can understand? As a product manager this means learning the roles of other people in your organization, understanding what’s important to them, and how your knowledge can help them succeed. This can happen in simple way like:

• Talking through new competitors in the market you’ve done research on to marketing so that they can craft thought pieces
• Letting the business development team know about new companies you’re excited about so they can start seeking out potential partnerships
• Telling sales how your product can drive down costs for certain user groups so they have an unique angle on how to position the product

As a plus, a well-understood problem combined with a way to translate it to different stakeholders can be crafted into a compelling product vision. This is a powerful way to unify people and drive toward a common overarching goal.

Solution 3 — Be ruthless aligning metrics to your product strategy and vision

OKRs are a disaster almost anytime companies decide to use them, so much so Marty Cagan has even stopped recommending them to companies. But why? OKRs at their core are meant as an empowerment technique — here is a company goal, now create your own goals to work toward solving it.

What they usually become is a free-for-fall for departments to set their own agendas or create over-obvious goals like ‘obtain more customers’ or ‘release product x’. This doesn’t come from a bad place, but once again fills the void when there is not a coherent and understandable product strategy in place. At its worst, this can completely blind the business to what success actually looks like!

I chose to pick on OKRs because one of the most important aspects of product strategy is showing stakeholders that you are moving towards some kind of end-state. This boils down to choosing metrics that provide proof that your product strategy is moving you toward your ultimate product vision.

This is challenging because it requires thinking of something that is not only measurable, but meaningful. A good metric should always tie into a meaningful future state along your product strategy. For example, if your product vision is ‘create the largest marketplace for authentic luxury sneakers on the planet’:

Bad metric: Increase traffic to the site by 100%

Why?: Your traffic increases but revenue is flat, so the metric may not support a sustainable growth path

Better metric: Increase sales on the platform by 15%

Why?: Your revenue increases, but customer complaints are up since an increase of counterfeits appeared on the site

Better still: Increase sales by 15% while holding complaint rate flat

Why?: This goal not only moves the company forward (revenue), but also accounts for conditions that could skew actual ‘success’

If you can point to a product vision, a product strategy (increase sales), then a metric that ties those together, you will save yourself hundreds of hours a year trying to get people on the same page. In fact, you may even find yourself with free time since you have given people a single coherent framework where they can best apply their skills to work toward a common goal that matters!

Product management is a hectic field that often feels like swimming through a sea of possibilities and people pulling you in different directions. It’s important that as product managers we not only understand where to prioritize time, but also how to best unify and rally the people around us to collectively achieve greatness. Hopefully this was helpful to anyone out there, and feel free to reach out or comment below with questions/comments. Thanks for reading!