I once worked on a project with a 10-year completion estimate. In software. 10 years. As you can imagine, this project was at a large company with many legacy approaches. And as you can imagine, executing a 10-year project requires a lot of project management. In fact, the majority of the project was not product or engineering work but project management work.

I didn't stick around long enough to see that project come close to completion, but I think even with smaller-scale projects, legacy processes like these creep up in older organizations and even in some startups. If you come from an organization like this or are trying to transition into a true product management role at most modern organizations, you'll need to find a way to throw away the project management hat and focus on product management instead.

First, let's define what project management is. Project management is a reporting and accountability function. Project managers are tasked with ensuring a project stays on track. They do this with Gantt charts and PowerPoints. They do this with spreadsheets and Slack messages. Project managers generally do not do the work. Instead, they bring people together to help facilitate the completion of the work. They force communication when communication is lacking. They push process where chaos might reign supreme.

Project management is an important function in every company, even startups. However, in a product-led, fast-moving startup or organization, project management cannot be conflated with product management. Project management is everyone's job in these companies, while product management is the job of people who have a completely different skillsets focused on strategy, collaboration, and execution. I don't want to minimize the role of project managers, but I do think they tend not to be the right role for fast-moving software companies.

What exactly is product management, then? Product management is a function that takes in research and critical thinking and outputs products and features. Product managers are not there to move Jira tickets around. If you subscribe to the idea that project management is a team effort, then anyone on the team can move these tickets and help create transparency. Product managers are on the team to help do two main things:

1. Distill the vision of the founders/CEO into products and features that can be implemented for today's customers.

2. Speak with customers directly and research the market to formulate product strategies that drive the company's mission forward.

Hopefully, the delineation of roles is clear. Now, we can get into how and why you might need to shed the project manager hat as you transition into a product manager role. Many companies have roles with "product" in the title. These roles are not created. For example, the role of a product owner is one that confused me early in my career. I thought that's what I wanted. And for many people, it's exactly what they want. But a product owner is not a product manager. A product owner is similar to a scrum master or a project manager. Their job is to coordinate tasks. If your company has team collaboration and ownership of this process, you don't need a product owner. But you do need product managers.

So, it's a natural career progression opportunity to move from product owner or project manager to product manager. But the actions you'll take on the job are different. The biggest change you'll face when shedding the project manager hat is that of process. Process is everything when you're the one managing a project. If you, alone, have to report and coordinate, processes are key. However, in a collaborative product development environment, process is distributed across team members. Opening tickets and moving those tickets through whatever tracking system the engineering team uses is likely going to be the responsibility of the individual contributor (IC). Project planning is going to be more iterative and less process-driven as well. And pivots…oh, there will be pivots.

The last point is, perhaps, the hardest part of the project manager hat to shed. When managing projects, future visibility is important. When working on a fast-moving product team, long-term visibility does not exist. It's like driving through dense fog. You can prepare, you can create strategies for piercing the fog, but you also have to be ready to swerve if needed. When you are coming from a process-first background, these types of pivots can be hard.

The best way to prepare yourself for the unknown is to commit to current work and hold your future plans loosely. Seems easy, but it's not. As soon as you start planning for the future, it's easy for you mind to cement those details. This is why I tend not to like roadmaps. Roadmaps are concrete and hard to pivot around. Bets are things you can prioritize, though. Ideas are things you can categorize. If something in the market changes and you suddenly have new direction, your ideas live on, but the bets you take related to those ideas change.

One day, I'll finally get around to writing about my Loosely Held Ideas framework, but the tl;dr is that when you plan for the future in product management, you need to drop the "plan". You're not ever planning. You're thinking. When I sit on a beach, staring at the ocean, I'm not making plans. I'm thinking. That's how you should approach the future of your product. By doing this, you'll be much better equipped to handle the transition from project management to product management.

Project managers, scrum masters, product owners, et al are useful roles in the right context. I'm assuming throughout this article that you are moving into a context where those roles do not make sense. If that's true, it's time for you to hang up your old hat and grab a new one from the rack. Because project management and product management are two different beasts.