Yes, Product Managers Should Project Manage "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs October 10 2020 True Communication, communication skills, people management, Product Management Skills, product mindset, Project Management, Stakeholder Management, stakeholders, Mind the Product Mind the Product Ltd 1554 Female product management coach - By David Pereiras Product Management 6.216

Yes, Product Managers Should Project Manage


It’s a truism that product managers should not be project managers. They are different disciplines requiring different skill sets. But practically, as a product manager, you probably do at least some minimum amount of project management in your daily work, perhaps even to your frustration and dissatisfaction!  In this article, I address this apparent dissonance, and give a framework for project managing, as a product manager.

When should you project manage?

The Project Management Body of Knowledge (PMBOK) from the Project Management Institute (PMI) lists 10 knowledge areas in project management:

  • Project Integration Management
  • Project Scope Management
  • Project Schedule Management
  • Project Cost Management
  • Project Quality Management
  • Project Resource Management
  • Project Communications Management
  • Project Risk Management
  • Project Procurement Management
  • Project Stakeholder Management

As a product manager, you’re already doing project management from a PMI perspective! You’re managing scope when planning new product changes. You’re facilitating collaboration between engineers and designers through meetings and async communications. You’re informing internal stakeholders of product roadmaps. You’re showing new features to customers and getting feedback. You’re working on product strategy to mitigate risks. In sum, you’re doing Scope, Communications, Risk, and Stakeholder Management.

And so it’s really the other PMI knowledge areas that are often contentious. As a product manager, should you be assigning work to engineers? Should you be managing deadlines for individual tasks? Should you be coordinating task dependencies? Should a product manager be doing what we conventionally define as project management, i.e. Schedule, Cost, Quality, and Resource Management? The answer is a conditional and scaled “yes”. You should be doing more of these other PMI knowledge areas if you’re working in a small to medium-sized company, and especially where there isn’t yet a very mature engineering management organization. But why?

Why project manage at all?

Humans are very diverse and complex creatures with many varied motivations. Even in a small company full of extremely talented people, as a whole they are not optimized to cohesively further company goals, by default. There needs to be some basic structure to align folks and help them perform at their best, together. You don’t need to create efficient processes and scale in a small company. Instead, you need to identify strategic projects and execute on them, one by one, to move the company forward. Basic project management facilitates this.

Female product management coach - By David Pereiras
Product management coach (photo by David Pereiras)

Startup founders and initial hires in companies often don’t have these basic project management skills. Especially in the innovation economy, early folks in a company are typically domain experts in a particular field. It’s rare that they are also people or project managers or otherwise have strong management skills. And so consequently, small to medium-sized companies are often filled with very talented individual contributors, but don’t have the expertise to coordinate and execute on big projects effectively. Company leaders of course realize this, but often don’t value project management early enough in a company lifecycle. This is how you as a product manager can really capture a unique opportunity. You were likely hired to manage a product backlog, get feedback from customers and track relative priorities. The existing engineers actually build the product. You figure out what to build. Or so that’s what the folks hiring you originally planned. But as a product manager, you should use basic project management skills to supercharge the efficacy of the implementation team. This is a secret weapon of product managers. You are already trained to think and work at higher levels of abstraction in terms of product and company growth. You practice communications and stakeholder management with business folks internally and customers externally on a daily basis. And it turns out these skills are immediately applicable to coordinating teams of engineers and designers to ship product updates quickly, which is a critical ability itself for a small company to survive and even thrive in the marketplace.

How do you project manage as a product manager?

Unlike a traditional project manager, as a product manager in a small or medium-sized company, you don’t have the power to make simple project management decisions like assigning work or setting deadlines. Fortunately, you don’t need to attain this authority. It’s simply not an effective way to project manage, especially as a product manager. Instead, lean on the innate motivations of people in a modern workplace, assuming high trust and competency. People want space to do their best work and a welcoming atmosphere to collaborate with each other. That requires a basic level of structure and consistency, where people can operate under shared norms. So work with leaders to establish a lightweight process communicating expectations on how to do product development. Be sure to emphasize desired descriptive outcomes in the process, over prescriptive rules. Maintain a source-of-truth doc for that process. For example, it could have these sections:

  • Maintain a prioritized backlog of product changes
  • Pick the next item from the top of the backlog
  • Check acceptance criteria when finishing a feature
  • Have a monthly retrospective

You also need some ground rules or meta-process to evolve the light-weight process itself, so that folks don’t feel restricted from doing their best work. You should welcome change proposals from everyone on the team, and put the onus on leaders to approve changes and communicate process updates widely. And so as a product manager, the way to project manage, is to simply gently nudge people to follow the process, and to propose updates as necessary. Again, the goal is not adherence to a rigid process, but shipping quality product changes leading to positive business outcomes. This in turn motivates people to continue doing their best work, establishing a virtuous cycle.

Every company is different. Your business needs and workplace culture shape your product development process and how you use it as a tool to project manage, as a product manager. But there nonetheless are a few best-practice principles to strive for. Start with these, especially if you are just starting out.

  • Intentional transparency: Most folks operate under a pull model of communications in the workplace. When they need information, they seek it out, asking relevant individuals along the way. As a product manager, be intentional in pushing out information as often as possible, even for work in progress. Beyond basic project status reports and announcements, take the extra step of articulating why certain decisions have been made. A traditional project manager exercises authority over folks to make things happen. As a product manager, you should be equipping your team with as much information as possible, so that they do their best work, in the business interest of the company, aligning with your goals.
  • Make decisions obvious: In traditional project management, after a leader makes a big business decision, they spend a lot of time articulating the reasons to the greater team. The decision has been made, and the goal is to convince folks that it makes sense, in order to motivate them and get them aligned on next steps. As a product manager, you should do the reverse. Since you’re already equipping the team with as much information as possible with intentional transparency, when you propose a particular direction (since you may not have the authority to make the decision immediately), the proposal should be so obvious to the team that everyone reacts in the positive. In other words, treat decision-making as a forcing function. If most of the proposals you make to your product and product development process proceed smoothly, you’re on the right track.
  • Don’t assign work. Set priorities: As a product manager, don’t spend time worrying about assigning work or squeezing out every last drop of productivity from the engineering team. Your job is not to build the product. Your job is to determine what to build. Focus on establishing a prioritized backlog of product changes and a visionary roadmap, based on convincing user research and customer development. Your backlog and roadmap should be a continual pitch to your engineering team. If they are sold, they’ll build it for you.

A transition mindset

Product managers tend to be really good at project managing since they are already managing stakeholders from various departments with different motivations and personalities. Product managers just have good people skills since they are effectively honing them every day. So as a product manager, it can be tempting to overly focus on project managing, because you are getting a lot of positive reinforcement, especially if you are doing a good job at it. But know that it’s not your main job, especially if you want to pursue a career in product. The value that a product manager brings to a company is figuring out what to build. As a product grows and becomes more complex, the overhead of implementation increases as well. And that’s ultimately an engineering management problem. Be on the look-out as engineering managers or directors arrive at your company. Or even actively advocate hiring for them. Adopt a mindset that project management belongs to the engineering department. Think about how to transition responsibilities to future engineering leaders. So that you can spend more time on your core competency, advancing the product itself.