You’re the PM? I thought I was the PM!
Written by Jason Scherschligt
This is the latest in our series of posts on The Product Mindset. See the first post in the series here: The Product Mindset.
Recently, I heard a smart and talented project manager say “the team is just killing it! Last sprint they delivered 60 story points.” I waited for him to say more, but then I realized: that’s it. That’s what he meant by the team “killing it,” or performing well. They had “delivered” a bunch of story points.
Friends, I have to tell you: I have never once heard customers say they needed story points.
Now, the project manager who said this was a strong and smart leader of an effective team. And his comment about story points spurred a healthy conversation about impact, value, and outcomes. But in this definition of “killing it,” I heard the temptation of too many technology teams to primarily define their success in the context of a project.
When I say this, I’m not diminishing project managers or demeaning the discipline of project management. Project management is an incredibly valuable set of skills, and I’ve personally benefitted from working with some great project managers throughout my career.
But modern businesses often stumble when distinguishing between two distinct professional disciplines: project management and product management. Sometimes they use the language and tools of one, when they should be concerned about the other.
What does your company mean by “PM”?
On the surface, it’s easy to understand the confusion. Project Managers and Product Managers are both somewhat vague roles sometimes performed by people on a tech team who are not developers or engineers. The job titles sound nearly identical, and they even fight over an abbreviation, PM (thankfully, most tech teams don’t also include that other job with a PM abbreviation, “Prime Minister.”) In fact, one way to understand your organization’s dominant mindset is to simply ask: what do we mean by the abbreviation “PM”?
This distinction between project and product management is more than a quibble over a couple letters. Project management and product management are two dramatically different concerns. This distinction has been complicated — or perhaps simplified? — by modern agile development practices, which, if done effectively, look more like a product model than like classic “waterfall” project management. We could even categorize modern technology work on a continuum between the classic project management model and a product model. This continuum might look something like this.
| Classic Project Management Model | Product Model (used by effective Agile project teams) |
| Outputs. “How much stuff did we make?” | Outcomes. “What are we doing for our customers and business?” |
| Design as an aesthetic stage. | Design as identifying and solving problems. |
| Accountable to technical requirements. | Accountable to business goals. |
| Satisfies our project plans. | Satisfies our customers’ needs. |
| Project metrics. “Look how on time and on budget we were!” | Market and business metrics. “Look what we did for the customer and business!” |
| Big increments of delivery. “The cutover” or “The launch.” | Relentless delivery of value, while respecting market cycles. “Frequent iterations.” |
| Teams charged to produce features. | Teams empowered to solve problems. |
| Celebrate releases. “Product is launched! There’s cake in the breakroom!” | Celebrate impact. “Let’s eat cake when we achieve this goal!” |
| Requirements changed? “Hmm…we must have done something wrong.” | Requirements changed? “Yay! We must have learned more about our market.” |
In this kind of binary framework, product management is the inverse of classic project management. I’ve made these kinds of pleas myself — heck, that table above has been part of my standard patter on product strategy for well over a decade, accompanied by advice to “shift to product thinking!” and “move from projects to products!” But even while I make these pleas, I know that this is a false binary. Because these are dials, not switches. And sometimes we need to operate in both models at once. Can we reconcile these two important disciplines?
Reconciling the product and project models
I think we can. While we shouldn’t confuse project management and product management for each other, we also don’t need to choose between them. We just need to use the right model in the right context.
Consider the Project Management Institute (PMI)’s definition of a project: a temporary endeavor undertaken to create a unique product, service, or result.
Notice that a product is among the things the PMI says a project creates. That’s a great clue to a healthy relationship between projects and products. A project creates a product. In other words, projects are in service of the product. I sometimes think of project management as a set of the tasks to get seedlings in the ground by a certain date and in a certain configuration, while product management is the job of caring for the garden so that it keeps producing bountiful fruit to satisfy our needs.
Or think of it this way. Project management is a great way to organize resources or manage and sequence labor. And certainly, it’s often worthwhile for your resources to be organized and your labor to be sequenced.
But customers don’t really care about the way you organize resources or sequence labor, just as they don’t care if you’re killing it with your story point delivery. They are not delighted or satisfied when you manage your sprints to fit your budget. And your business isn’t built if your customers aren’t delighted or their needs aren’t satisfied.
Product management, on the other hand, is how you satisfy customers, understand and respond to user needs, win markets, surpass competitors, and build a business. It is concerned with figuring out — discovering! — that which will deliver value to your customers and therefore value to your business. Inherent in that verb, to discover, are some important concepts: Uncertainty. Experimentation. Ambiguity. Learning. Measurement. Continuous improvement. If your model for prioritzing, evaluating, and communicating the success of your technology work avoids these product concepts in favor of executing projects well, you run the risk of failing to satisfy the needs of your business and your customers. In fact, a successful project could have built the wrong thing well.
If that sounds like a risk you face, focus on your product management practices. Develop and align a team on a strong vision. Articulate a strategy based on customer needs and business goals. Discover user needs. Measure, respond, and adapt. And rather than mandating features that you once thought were required, empower your teams to uncover solutions to customer problems. And then: keep doing it.
Because you manage a project to end.
But you manage a product to endure.