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.
| Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Project Work vs Product Work Opinions expressed by Java Code Geeks contributors are their own. |
