My last 2 work experiences were on 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 constantly evolve it.
And it that same spirit, you want team members to stay on the same product for long periods of time, to 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 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 output.
(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” where 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 yet is. For example, if we are geographically expanding a product like Uber for the next quarter I may see “Start operation in Sao Paulo, Brasil”, 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 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 in the outcome, so we will change the roadmap as many times 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, it is quite easy that if we fail to realize the value, the sponsor blames the team execution and the team blames the sponsor’s definition. 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. On the other side, if you make a definition based on your intuition you will probably be wrong and if the team is focusing on delivering agreed tasks it would be quite hard to learn along the way and change scope during execution.
The Product Manager role cames to the rescue. The job is not focused on getting the team to execute on time. 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.