Products, Not Projects

Here’s a fun party trick: next time you have the occasion to introduce a product manager, refer to them as a project manager. Then run!

You’d better run because, for many product managers, these are fighting words. It’s not that they have anything particularly against this role. It’s just that, by confusing product and project, you’ve betrayed a fundamental misunderstanding of what product management is all about.

What’s the difference? It’s not a question most PMs give a lot of intentional thought to because, for most, the distinction remains at once obvious and ineffable, so patently obvious that it almost doesn’t bear conscious consideration. I see four primary differences:

Duration

Projects are temporary and episodic, a way to organize activity and focus efforts to achieve some target goal or outcome with teams that are formed and then disbanded as priorities dictate. Products, on the other hand, are durable and longer lasting, where teams are given an opportunity to live with, learn, and solve for a customer need for a much longer period of time. This longer duration allows PMs to deliver a product iteratively and continuously toward the goal of mastering the customer need and progressively refining the problem/solution fit.

Orientation

Projects often focus on well-defined goals and outcomes, mostly for internal stakeholders who are far removed from the external customer or even the broader business problem. Products, by contrast, are mono-focused on one key stakeholder: the end customer. This orientation to the customer need has a clarifying purpose in assigning resources and priority. It also forces a focus on the broader experience, where the product manager becomes accountable to — if not responsible for — dependent services that a product relies upon (e.g., cloud infrastructure, remote microservices), and even important parts of the customer experience like training and support that may be native to or closely adjacent to the product itself.

Constraints

The scope of a project is generally bounded by and accountable to the iron triangle of budget and time, where concessions must be made to accommodate these mutually interdependent triple constraints. While products are also beholden to similar forces, they’re given more discretionary freedom to better optimize for all three. Why? Because projects expire. Products, on the other hand, are (more or less) open-ended. This means that what doesn’t fit now can fit on a later horizon. Such is a key difference between a project plan and a roadmap.

Volatility

The requirements for a project are a snapshot of what is known at a given point in time. By contrast, the requirements of a product are a moving target based on what’s uncovered through iterative discovery and what dynamic markets telegraph over time. Product managers live in and work through this uncertainty in search of their own version of the truth. As my colleague Brian Crofts says, they fall in love with the problem, not the solution. This sort of ambiguity would give the average project manager either hives or a heart attack.

Empathy That Endures

A marketing colleague recently told me that she could no longer abide by agency work because she cared too much. It was an intriguing confession. Cared too much? What does that mean?

She said that the end of each client project felt like loss, something like the end of a consequential relationship. Where could it have gone? What would have come next? She wanted to see how the story ended. She wanted to improve on what her team delivered.

This struck a chord. Product managers have empathy that endures. Their interest and curiosity in fulfilling a customer need last longer than the project schedule. They want — no, need — to see how the story ends. To me, that’s the essential nature of the product manager. And perhaps a reasonable distinction between product and project.

Candidly, in 2018, few modern software companies still wrestle with this distinction. But the average enterprise is still trying to bridge the divide. Here, product management is something that sits on the business side and “product” often means something that you can drop on your foot. But even in matters of software, the project is the more common unit of work.

That’s bound to change. Witness the emergence of the “product owner” as a way to sort out the role confusion between business and IT. Frankly, that has done little to clarify, only begging more questions. Eventually, every company with a stake in delighting a customer (read: every company) will have to declare that it’s about products, not projects.

That’ll be a sign of certain progress.