The important difference between project management and product management.

And the one thing everyone has to be comfortable with.

Photo by _M_V_ on Unsplash

If you’re creating or building anything, the first thing everyone has to come to terms with is that nothing will go to plan. After that, it’s you, your team, and the clients’ ability to accept the uncertainty of not knowing how things will go and going forward anyway.

This element of uncertainty is what causes project management and product management to be misunderstood.

While similar — only differentiated by two letters — and often occurring at the same time, I can tell you managing projects and building products are not the same.

Projects focus on building something, while products focus on building something new.

Or, more directly.

Projects focus on output, while products focus on the outcome.

Which, either way, you end up with something. However, it’s the approach and mindset of what you hope to achieve that separates them. And if you’re trying to build something new everyone needs to be aware of how that will go from the start if you want to have any chance of achieving it.

How can you plan something months in advance based on assumptions and expect to be right?

Projects.

Projects are linear.

They start with defined expectations and requirements. The ultimate deliverable. How much time you have. And how much money you can spend to get there. Knowing these before you ever start means you often end up backing into the numbers to “make it work” given the constraints imposed by a tight timeline or lack of budget.

This means the driving metric of success is how efficient a team can be given what they have. How much can be done with the least amount of resources necessary?

For these types of projects to be successful, they have to be standardized. They have to be repeatable.

It doesn’t matter who does the work, so long as it gets done.

Projects can be complicated, but that doesn’t make them complex. If a team follows the outlined steps, they’ll be able to deliver the expected output consistently.

That said, while some of these same principles apply to building products as well, you fundamentally have to follow a different set of rules.

Products.

Products are undefined at the start.

They are based on merely a hypothesis.

You might know there is a problem to be solved, but you don’t know the solution. You don’t know if there are many possible solutions, or maybe none at all. And when there are many, you might be unsure which is the right one.

This is why building products focus on the outcome, on finding the right solution. The aim of a product is a solution that will benefit the most amount of people in the quickest time possible.

This means that teams have to test and learn. They might go down one path only to find out their assumption was wrong. They have to start over, maybe not from zero, but they have to start again.

As they do this, instead of making decisions based on loose beliefs, teams begin to make decisions based on facts and experience as they increase their foundational knowledge.

This is incremental progress. And over time, this incremental progress compounds into something worthwhile and valuable.

This is why unlike projects, products product complex.

Product teams are working through unknowns, simplifying variables, and locking in dependencies the further along they get.

Which brings us back to uncertainty.

Uncertainty.

Uncertainty is the key difference between project based and product based work.

There’s apparent security in believing we know what and when something will happen based on a timeline, or how much something will cost, or exactly what we’ll be getting.

This belief is why people like project-based work as it reduces the feeling of uncertainty and is often why product work is wrapped in a project-based approach.

Uncertainty makes people feel uncomfortable.

But in the beginning, it’s impossible to know the outcome.

For both a product and a product.

For a product as no one knows what the best solution will be. Part of the process then is to allow for unstructured research, exploration, and learning without an explicit goal. Otherwise, all the work will lead to confirming an assumption. But without that direction, it might be that the initial assumption was wrong from the beginning.

What’s worse? Coming to find out you need to change your direction or building something no one wants?

And when it comes to a project how can you plan something months in advance based on assumptions and expect to be right?

Markets changes. New information comes in to play. Timelines shift, etc. You have to be able to adapt no matter what you’re doing.

Sure, you can’t work on something forever. Resources are never truly unlimited. But if you actually want to see what’s possible when you’re building a product live with the uncertainty in the beginning. Things will ultimately fall into place as they should. It’ll be your best possible chance of creating something great.

And if you just need something done, run it as a project. Just don’t expect anything groundbreaking to come from it.

Wes Jones is a business strategist and product manager running a studio doing strategy, ux / ui design, and development for startups and established companies.

This story is published in The Startup, Medium’s largest entrepreneurship publication followed by +445,678 people.

Subscribe to receive our top stories here.