The product-oriented organization (known also as a product organization or product oriented firm) is a company, where people create teams around products. This is just one of many approaches to business organization, but I believe the best one.
In this blog post, I am going to tell the story of an example company (but you can easily see this story in real life, over and over again).
Let’s imagine, that someone funded new startup… 🎉
When being small is an advantage
Our example company is a ubiquitous young IT firm. People there are working on a few products, mainly developed by the tiny group of developers or even by a single developer. They are familiar with the goals they are about to achieve.
Furthermore, they are doing well. Every product is giving revenue, and the organization has time and money to develop new products. The firm rapidly extends its portfolio and at some point, they ask themselves a question: “How should we organize our structure to maintain all these products?”. Right now they distinguish projects based on repositories existence. That means one developer is regularly working on a single project.
Natural and probably easiest approach is to create many teams (or as someone will say – guilds). But how?
As already mentioned, ordinarily, companies tend to build a wider and wider portfolio, yet not so big development team. They seek some kind of reorganization to remain their ability to maintain all products and still develop new ones. Another thing that bothers authorities with money is the Bus Factor. Simple idea is to create Teams inside the IT department and make them responsible for the set of projects matching their skills. In other words, the easiest way is to identify Teams with technology.
At first glance, it looks like a decent idea but problems start to pop up like mushrooms.
Firstly communication will become the bottleneck. Developing things in one technology usually requires at least information about solutions used in related projects.
Secondly, if the department is using some tools like JIRA, they tend to mirror repositories into projects. It is a simple and easy approach from the development point of view, but completely useless one from the business point of view. Imagine that requests from the business need to be torn into pieces and addressed to different JIRA projects. Ultimately the company will need to hire multiple project managers to cover that.
Last but not least, overall development tends to slow down and looks like the Waterfall process when for instance Team Java willing to add new functionality needs to first address requests to Team SQL and not start before their results are deployed to production.
At some point authorities with money will ask themselves another question: “How can we optimize work and improve focus on our company goals inside the IT department instead of burning money”?
Return of the Product-oriented organization
Answer here is simple, but not everyone would like to hear it. Go back to Product-oriented organization approach.
However, there is a fundamental question they need to answer before doing so. How to define our Products? It is crucial since, you can’t have a Product Owner, Product Backlog, and team dedicated to Product… without defining what this Product really is. I don’t want to rewrite what has been already written, so I recommend reading What is a Product? For the purpose of this article, let’s quote the most important part.
I define a product as something (physical or not) that is created through a process and that provides benefits to a market.Mike Cohn
I believe that after reading only the definition you will easily identify products from previous image (with four technical teams). We can identify products slightly differently, and it is still fine. This is how I defined them.
Such defined product-teams (if you use Scrum, they consist, Developers, Scrum Master, and Product Owner or Proxy Product Owner) will work more effectively because of many reasons.
Why this approach work better?
There are mny reasons, just to mention a few.
When a team is focused on a goal, which is to deliver a genuine quality product and satisfy business values, they tend to work better and invent solutions (just like in the first Stage). The reason they do that is that they feel responsible for the product, and previously they were only responsible for completing tasks.
With improved communication comes higher development speed. When the communication was improved you might ask? That moment when the product team was created, because of team of cross-skilled individuals, who have all the required skills to deliver the product, don’t need to communicate with another team so often as they had to in the previous Stage.
Summary you should remember about Product-oriented organization
Organize people around products. Feed them with product-vision and empower them to make decision regarding their product and you see great growth. You will win.
Put people in their technical silos, remove accountability from their shoulders and they won’t achieve anything. You will lose.
I hope this article might help companies avoid doing some very popular mistakes. Leave a comment if my blog post helped you, it really matters for me 🙌