Project Manager versus Product Manager in Tech Startups
Understanding the difference between what Project Managers are, and what Product Managers are, is critical in tech startups since the way that manager operates has the potential to create all the business value of a tech product, or destroy that business value that would otherwise have been created.
Picking the wrong fit for the job of Product Management in tech startups is a common pitfall, and if done wrong is also a common glaring indicator of a tech company with a bad product culture from top to bottom.
Before we get into the differences between the two roles (in the context of tech startups), let’s try to understand where the roles came from in the first place.
The Project Manager:
As with anyone armed with an idea or a plan, if they feel like they don’t have the capability or skills to execute it well, will be hiring a “Project Manager” (a PjM) to get the idea and plan delivered properly— we call that thing a “project” of course.
Projects may want to start, but people desperately want them to end as quick as possible.
The defining qualities of a project is that it starts at some point and ends at some time later, after something specific has been done or delivered. Typically, projects come with other constraints too: like how long it should take, how much should they cost, some have a budget, some have a timeline, most have both. Most projects have other more detailed constraints like compliance needs and preferences and needs and requirements from those benefiting from the outputs of the project. Some projects come with pre-defined plans, and some require that a plan be made first.
It is fair to say that today, the mechanism of using “projects” as-a-tool — to get something achieved or done or completed are very varied, but in essence, the tool is the same.
Define the project -> create a plan -> get someone to deliver to that plan -> job done!
Someone has to manage the project work to completion — the Project Manager. They generally have a “directive” to get something done from the person that hired them in that role, “a stakeholder”. The stakeholder(s) usually have some stake in the output of the project. They are also, usually the party paying for the project to get done.
“Done”, being the operative word here. Projects end when they are completed. That may take some time, but they are completed when all the work on the plan is done. Sometimes they never get there, sometime they are abandoned.
One last word on projects. You rarely have a project without a “project plan”, or some idea of a set of outputs that need delivering. Sometimes the project gets underway, and the initial activity is to create the project plan, but the project is almost never actually begun until you can answer two questions: (1) How long will it take and (2) How much will it cost. Two inputs the project stakeholders are likely to care the most about since, they are likely not controlling the work to complete on the project. They remain in control of the project by controlling duration and cost. These two factors are usually set in stone by the stakeholders and with very little tolerance for a change in the plan. Now, there are, of course, variants to all these aspects of projects, but generally speaking, all of this holds true for most projects in tech.
Project Managers have been around for eons, nothing new here. Everyone can relate to projects because we use them at work and at home in our personal lives. ie. climbing a mountain peak, knitting a jumper for our kids, building a shed, renovating the bathroom, or building a new family home.
All projects, performed by someone, all require some project management to some degree to be done by someone we call a Project Manager.
The Product Manager:
The role of Product Manager (a PdM) is far newer to the tech industry (less than 50 years old), and is harder to define clearly in terms everyone in business can relate to - particularly how it is used in the tech space. Most people can’t relate to doing Product Management in how they go about their daily lives — like you can more easily do with a Project Manager. (eg. we can all relate to pet projects/hobbies/things to get done/things to improve/things to change about our lives in and around home and at work).
However, “Products” seem to be something quite different, and they are. We use hundreds of them everyday, many in combination with each other, throughout the day an night. We are all so familiar with the usage of them, but only a small percentage of the population are familiar with how they are designed and built. Some group of people made all the products for us, packaged them for us, shipped them to us, and improve, support and maintain them for us. We pay them money for those products of course, in various ways, but those products were not created as the result of a project, by a Project Manager.
As a designer/builder of a “Product” in tech, our goal is to have some consumers buy our product — unlike most projects we know about. We invest a great deal into making the product, getting it in front of consumers (marketing), and then selling it to consumers (sales), and then fixing or improving it (support). Again, all things things you don’t typically consider with a project.
We almost always require that we sell our product to a multitude of consumers/buyers to recover the total cost of all this extra effort — we typically do that to take advantage of economies of scale (build once: market, sell and support many units — spread the cost across many units). Building and maintaining a product is super expensive over its entire lifetime, and so generally, no buyer/consumer of the product will ever be paying for the entire cost of making and selling all the products that are made. Unlike a stakeholder pays for the entire cost of their project, when it is delivered. The total cost of a product is generally shared across many buyers over long periods of time.
Most tech products have some kind of shelf-life and in most cases, require ongoing maintenance and support to keep them going for long periods of time, maybe even decades. The product may be customized for an individual consumer, but that individual experience is also curated for them as part of the product work too. The product is developed/evolved over time (this is what we mean by “Product Development”), and that whole process is lead by a Product Manager.
A Product Manager, just like a Project Manager, is hired by business/company stakeholder(s), usually those who hold stakes in the business outcomes created by the presence of the product in a market of multiple buyers/consumers. Those business outcomes are more than likely to be predetermined before any product is even made, and even without any plan to make the product.
In fact, most tech products are initiated and funded and started on the idea or bet that a market for it will come into existence at some point in the future, once the product is available! Not like a project at all.
And herein lies one of the defining differences between managing a product and managing a project. It is the lack of certainty and abundance of unmitigated risk about what the product may be, or how it will be made, or what it actually will be (on any dimension) in the future! Unlike projects, products are never done. They are constantly evolving and improving over time, most of the time trying to reach more consumers/buyers and sticking to existing consumers.
A product is done only when the last customer stops using it!
Products is a whole different game than Projects — which are just a tool to get things started or done.
Project Manager versus Product Manager
Now that we’ve touched on some key differences in general, it is time to get a little more specific about projects and products when applied to tech startups.
Let’s now see how the roles compare:
Project Managers and Product Managers are both hired by Stakeholders. In a tech startup, that is likely to be a founder or a CEO of the company who knows that their job is to focus on the business strategy and leave the product strategy up to the product part of their organisation. A founder or CEO of a startup is going to learn pretty fast they cannot scale (as a person), and their business cannot scale (as a company) if they try to take on this role as well as running the company. However, there is nothing to say that a founder of a tech company must be a CEO either. Many successful tech startups have been founded by Product Managers, who have stayed as Product Managers and founders, leaving the CEO slot to others better skilled at running and administering businesses.
Early Warning Sign: Not doing this well, and dictating the product strategy from the top of the company is another common pitfall in tech startups that results in a poor product that just limps along, and never scales in revenue. Why? you need to deeply understand two inconvenient truths about product, that you can’t ignore and can’t mitigate from the top of the company.
Project Managers are hired with a clear directive to deliver a clear set of outputs along with a plan to describe the execution, within a predefined time at a predefined cost. Product Managers are hired with a specific set of business outcomes and results in mind, be those defined in: number of customers, revenue, market share, brand, reputation, or whatever.
Project Managers manage the completion a project plan that includes numerous detailed tasks, times, costs, milestones, deadlines, phases, iterations, and a bunch of stakeholder controls to ensure that the project is completed on time and in budget to the stakeholders’ satisfaction. This plan affords stakeholders confidence that major risks in time and money are mitigated for them. Product Managers manage a roadmap of opportunities that includes best guesses/bets on a small number of opportunities to develop in the market, and pursue over the next planning horizon. This roadmap may sometimes include deadlines for coordinating market events in that period, but this roadmap constantly changes. This “strategy” affords stakeholders the confidence that the product can be shaped and can change according to what the market demands, as both the market and product changes over time.
Early Warning Sign: The certainty level of things on a product “roadmap” is inversely proportional to the trust between the Stakeholder(s) and a Product Manager. Higher level of detail and certainty = Lower stakeholder trust. Opportunity versus Commitment.
Project Managers use incentives and personal commitments to hold those doing the work personally accountable to complete the planned work according to plan. Product Managers share business opportunities, business context and customer evidence with product team(s), and inspire them with a product vision to discover, design and build product that delivers actual measurable results to the business.
Early Warning Sign: You can easily tell a project team from a product team. Are they made up of contracted Mercenaries working for the stakeholders needs or are they made up of empowered Missionaries working for the customers needs?
Project Managers never question the directive they are hired for, nor question their stakeholders, and rarely question the integrity of the plan they are executing. Stakeholders are the only ones empowered to change the plan — requiring contract negotiation. Product Managers seek the actual truth about whether the actual product is producing the actual results it needs to at any point in time, and then empowers the product team(s) to innovate to address any gaps that actually exist in the product.
Project Managers act as an agent for their stakeholders and deliver pred-defined outputs to those stakeholders. Product Managers act as an agent for their customers, and discover, design and innovate product that delivers business results to their stakeholders.
Project Managers have all the answers to all the questions about their project in their plan, or they ask their Stakeholders for clarity. Product Managers seek the answers from evidence created by their customers, the data from the market, the data that the product produces, and from their product teams directly.
Project Managers don’t want innovations or experimentation that detract attention from delivering to the agreed plan. Product Managers must innovate to find the right product that customers will actually find value in and and pay for.
Project Managers believe in division of labor and specialization to complete specific individual steps in the plan the best they can. Product Managers seek diversity in skill sets in product teams that can experiment together, solve complex problems together, and innovate unique solutions together. The teams fill the specialization gaps themselves.
Early Warning Sign: Is your product team only composed of contractor superstar developers, or do you have a team of diverse people with skill sets in design, discovery, delivery and support?
Project Managers identify with and hang out with their stakeholders (for safety). Product Managers identify with their customers and hangout with their product teams (for communicating context).
Project Managers describe their customers as their stakeholders. Product Managers describe their customers as the ones buying their product.
Project Managers are satisfied with delivering features on the plan, and seek signoff from the stakeholders. Product Managers iterate on versions of features until they are satisfied when they deliver the actual business results from their customers.
Project Managers define success as completing the plan, before time and/or within budget, with satisfied stakeholders. Product Managers define success as delivering a product that customers desire and actually pay for, that also satisfies business objectives.
we could go on…..
Apples and Oranges
Now, hopefully you now see that Project Managers and Product Managers are two almost entirely different roles, that are really not comparable for the same type of work, nor are they just subtle nuances of each other, that can be conflated or glossed over.
With different focus, different objectives, different tools, different relationships and different motivations. Yes, both work for and are hired by stakeholders, but that is about all they have in common, apart from a similar name that is often misunderstood and often disregarded as being the same role, requiring the same skill sets.
It is true to say that part of product management sometimes requires doing some small pieces of project management, but this is certainly not the main part of product management at all.
Far too many hiring managers, trying to keep up with industry trends, naively think that the names of these manager roles sound so similar that the skill sets and activities must be about the same. Or that a once experienced Project Manager will be a fine Product Manager. But that is far from the reality, it is crazy in fact, given what we’ve just outlined above to you.
Where are the Project Managers?
You may be surprised to hear that your favorite software companies/tech startups don’t have any Project Managers in their orgs! I’ll let you re-read that statement again, so it can sink in.
This is not a trend, this was deliberate. It was figured out way back in the 1980’s, and has been the case ever since then. No Project Managers in Product!
The role of Project Management simply has no value or place in developing products. In fact, not even the successful large software companies hire project managers. If you are a Microsoft or a Google or an Apple, or the next 1B dollar tech company then you may carry a tiny team of strategic project managers at the exec level in your company, reserved for getting various strategic programs of work off the ground. And yes, if you are a major systems integrator you may also have Sales and Services subsidiaries around the world with people called Project Managers in them. But those PjMs are managing tactical one-off sales, integration or customization projects. All those kinds of PjM’s are kept a long way away from the company’s product units.
A final note for Startup Founders
If you are a tech startup and you are hiring a Project Manager or have hired a Project Manager to design, build and innovate your product, then please seriously rethink that decision.
If this is indeed the case at your company, then it’s likely that this Project Manager is treating the Founder/CEO or the exec team as their end-customer to the product!
It is also likely that the entire product organisation is thus relying on the Founder/CEO/exec team to define the detailed plan/roadmap of the definitive product features that must be built within some budget and arbitrary timeline. This is the #1 killer of innovation in any company.
Armed with the false sense of certainty that those roadmapped features are exactly what are going to create real business value for the customers, the Project Manager is going to be quite righteously driving the developers (who are just code monkeys in this model) to burn themselves out building those unproven features to arbitrary deadlines. Just because the boss said so. It is just as likely there are no product designers around, nor any user researchers or discovery work going on with real customers. Those things just won’t be needed when you have already convinced yourself that you know better then your market.
You will also notice that in fact, the real customers for the product are nowhere to be seen near this company, no one except the Founder/CEO has ever seen them, met them or spoken to them. Even then, it’s been over email, coffee or a boardroom table. No product discovery is going on (What is Product Discovery?), there is no product design going on (We don’t need no Product Designers!) there is no iteration of the delivered features going on, and therefore no durable design or architecture to the product. There will be no time to deal with the mounting technical debt left in the wake of this death-march, since everyone is too busy building more and more features at an ever increasing and desperate rate.
Notice how there is an underlying flawed assumption that still remains unchallenged, that: “adding more features to the product equals more sales of the product”, so to get more sales must mean we need more and more features.
Notice how no one wants to risk their job challenging the Founder/CEO/exec team and their ideas as to what the product should be, or even where the product is actually going. Notice that there is no cohesive product vision or strategy for the product communicated to those actually building it. Notice the blame talk at the water cooler. Notice how people are churning through the organisation seeking better places to work, or seeking new opportunities.
The Founder/CEO/exec team, in their self-soothing reality distortion fields dictating their ideas are never going to be challenged that: most of their product ideas are simply not going to work. They are never going to discover and learn the real truth about their customers and their market potential for their product. They will not built an innovation engine to do that necessary discovery work. They just rely on their personal opinions, domain expertise and a trial and error process to get them through. If you build it they will come.
This is all precisely NOT Product Management, but rather an expensive stroking of a stakeholders ego, just thinking you are building a good product.
Please don’t do that to people and to your product! You need Product Management!
