Project Work vs Product Work

We hear a lot these days about project-based organizations vs. product-based organizations. Much of what we do in software is in service of products. Products tend to evolve over time.

When we work on projects, we learn from the experience. However, once we finish this release, the “product” (the output of the project) doesn't change and incorporate our learning for the future.  Here are some examples of projects where we learn, but the product doesn't change:

  • Events, such as weddings or conferences.  We might learn and carry those learnings from one event to the next. However, we don't change the past event based on what we learned.
  • Job search. We might learn how to look for a job. We might learn how to work differently. However, we don't change the project—to find the next job.
  • Physical products that don't incorporate software. For example, if we write or knit or somehow create a physical product, we learn from that experience. We don't change the product once we're done.

All of these projects help us learn what we might do next. However, we don't change the product after we release it.

That's what's different about software products (and sometimes hardware, firmware, mechanical products that incorporate software). We change the product after we release it.

That's why, especially in product-based work, we benefit from long-lived product-based feature teams. We learn how to work together, as project teams do. We learn about the product as we create it, as project teams might. We learn for the future and can leave ourselves documentation and can plan for the future, ready to change the product after this release.

This image is how we hope a product can change over time, increasing its capabilities with each project.

What about our capabilities as skilled people? I like to think about my capabilities increasing over time, just as products do. (No, I'm a human, not a product!) However, I learn and change so I can adapt to what's next.

That's why I like to work with the same people on my book projects. I can find other editors, book cover designers, layout person, etc. And, these people already know me. They know how I like to work. I know how they like to work. We have learned to work as a team.

Much of what we do, whether is software-based or not, is knowledge work. The more we create long-lived teams who have already learned how to work together, the easier it is to work together. Even if that work is project-based work.

Too many people, especially managers, think we can provide knowledge work as services. It doesn't matter if we are working on project-based work or product-based work. Thinking of anyone as a “service” to the rest of the work is an example of resource-efficiency, not flow-efficiency thinking.

We all learn as we proceed through our work. We might learn for ourselves, what might we do the next time? We might also learn for the product: what do we want to consider not just for ourselves, but for our product the next time?

Here's the big takeaway: If people will need to work together again, how do we keep them together? How can we use (in the best possible sense of use) great teams who have learned how to learn together and deliver together?

For me, it's not so much the idea of a project-based organization or a product-based organization. It's flowing work through teams who have learned how to work together successfully.

Your organization might benefit from thinking in products to define the strategy, manage the project portfolio, and organize the people. You might well have a project-based organization and that works for you. Keep people together who have learned how to work together.

All the posts in this series:

6 thoughts on “Project Work vs Product Work”

  1. Well done! Complex products that achieve significant market penetration evolve in order to expand that penetration, and a permanent team that understands the product makes that successful expansion more likely.

    Projects produce products but the goal is more about revolution: introducing change. Whether the product is new software or a new bridge, the project team needs a broader range of skills than that required to merely create the product, from communications to contract law to all kinds of niche knowledge. Many of those skills are only needed temporarily, so specialists come and go. Thus, you shouldn’t try to staff or manage a product team like a project team.

    1. Dave, thanks! I have often seen experts drop in/visit a project team and it works for that specific project. As you said, a product team needs to develop its expertise. Yes, the product team can benefit from the experts explaining/teaching/coaching etc. And, the product team needs to integrate that knowledge.

  2. Pingback: New PM Articles for the Week of September 17 – 23 - The Practicing IT Project ManagerThe Practicing IT Project Manager

  3. Pingback: Designing an Organization for a Product Approach, Part 1 – 1

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: