What is the real difference between Project and Product Organizations?
My last 2 work experiences were with companies that were trying to move from a project-based organization to a product-based organization.
Being a “product person” I love this challenge. But I found out that there were many myths about what the Project vs Product difference really is about.
For instance, I heard the myth that in project organizations, you have a Project Gantt for the year, but in a product organization, you don’t have annual plans. Yet, many product organizations do work with yearly roadmaps.
With examples like this one, I’ve found that many things can be done almost the same in both types of organizations, and the difference lies more in mindset, principles, and execution than in tools or structures.
So let’s break down those things that sound similar but are quite different in practice.
What may look similar
Team formation
In a project organization, almost by definition, you form teams to tackle projects. This is not that different from product organizations, where you form teams around products to execute requirements. In both, you probably have periodic project/initiative reviews where you verify resource allocation and assign according to priorities.
What makes all the difference is that in product organizations -unless you want to “kill” a product- you always have a team assigned to a product. You accept that a product is a source of value, and for that value to perdure and increase, you need to evolve it constantly.
And in that same spirit, you want team members to stay on the same product for long periods of time, increase their domain knowledge, and have a full sense of ownership of the results their products achieve. In project organizations, once a project is done, and team members are assigned to new endeavors, all the knowledge they gathered about the product they just built is mostly lost…
Decision making
In project organizations, teams are gathered to deliver work. Most decisions have already been made. The focus of the team is the output.
To achieve success at scale with a product structure, teams should be responsible for achieving goals and should be empowered to decide what is the best way to achieve them. The focus is the outcome.
(That being said, there still are many Product organizations where teams are not autonomous and empowered and are just requested to build what top management decided)
Team structure and reporting
Another element that usually differs is how teams are organized. In project organizations, the focus is on “efficiency”, so teams are organized according to “work type” (development, QA, design, etc). So when development is done with item A, the QA team starts working on it while development moves to item B.
This again puts the focus on output and skews towards a waterfall methodology.
In lean product organizations, we strive to form multidisciplinary teams. We want to empower teams to achieve the expected results, and for that, they need to have resources of all the necessary types at any moment. Furthermore, there usually are no hierarchies. Teams have business goals to achieve, and all team members are expected to contribute and decide as equals.
Plan, Roadmap, and iterations
Product organizations do have yearly roadmaps.
How does that differ from yearly Gantt projects? How we view change and the difference between problem vs solution focus.
Good product organizations create roadmaps based on the problems they want to resolve. Instead of having specific solutions listed in a timeline (Gantt), they use high-level problem titles that give room to solution discovery. For example, a Project Gantt would list “Cook a cheesecake” whereas a product roadmap may say, “Need to eat something sweet for dessert,” and we can later explore and discover what type of cake people prefer or if they just rather have ice cream.
Furthermore, good roadmaps tend to be more abstract the further away in time a particular item is, demonstrating to the viewer how “uncertain” or unexplored it is yet. For example, if we are geographically expanding a product like Uber, for the next quarter, I may see “Start operation in Sao Paulo, Brazil”, for next semester, I may see “Start operations in Peru”, and for next year I may see “Start operations in Europe”. The further away in time, the less precise the item is.
Finally, Gantts are used as tools to measure effective delivery. Teams are committed to achieving the listed tasks on time (yes, output focus again). Changing the plan is painful both for the team and the sponsors.
Roadmaps, on the other hand, are just guidelines. We expect to change roadmaps as we learn what is more valuable for the user and the business. The focus is on the outcome, so we will change the roadmap as often as needed to achieve it.
What truly is radically different
The Results Owner
In a project organization, you typically have a sponsor who wishes to get a result after the product is executed. On the other side, you have a project manager and a team who wants to finish the request on time with the agreed scope.
In this scenario, if we fail to realize the value, the sponsor blames the team's execution, and the team blames the sponsor’s requirement. And the truth is: they are probably both right!
If you execute towards a deadline and a specified requirement, you are not focusing on whether the end value is achieved or not. Your goal is on time and on budget, not the result. On the other side, sponsors making requests based on intuition will probably be wrong many times. And if the team only focuses on delivering agreed tasks, they would put no effort in “checking” if the request is any good, nor in learning while they execute, to adapt accordingly.
The Product Manager role comes to the rescue. The job is not focused on getting the team to execute on time. It is to make sure we achieve the expected value and results.
In the end, the Product Organization’s focus on the outcome makes all the difference.
That’s it! There are many more important differences to consider, like how funding radically changes or the need for technical excellence. But I would love to hear your thoughts about these particular differences.
If you enjoyed it and want to receive more tools & tips to improve your product, you can subscribe here and join hundreds of readers of my Lean Experimentation blog!
