How would company management work as a set of products?

Question

Background: A small tech company has just grown from a flat startup team of 8 developers with no real structure to ca. 40 people (roughly 20 devs + 20 various business and management positions), who need to work in teams and have clearly defined resources and priorities. The company uses agile terms (like a Product Owner and Backlog), but few people have read more about it than the Agile Manifesto. A position of Agile Coach is open, but nobody is hired for it yet.

Situation: The CTO pushes forward a product-oriented structure for the whole company. While the devs had no problem defining what their 3 Products are and how to deliver them, the management used a literal approach: "If a Product is anything with a backlog and features, and a backlog is a list of my tasks, then my tasks are my Product."
As a result, the marketing team has a product "Company webpage" and a product "Brand development", while the office manager has 3 products: "Office management in City A", "Office management in City B", and "Travel Booking."

Question: Are there any dangers or side effects of defining company management as a set of products?
If no, how to organize this work in the most effective way? And if yes, how to define what could and could not be a product?

Answer 1

Your company may be watering down the idea of products to its own detriment. A product should be able to be successful in its own right. Marketing material for another product or organizational overhead that supports the creation of a product cannot, by definition, be its own product, as it can only succeed if the product it supports succeeds.

There are too many possible solutions to enumerate here, but a question that might lead you to some good answers is: how would it change your approach if management and marketing specifically worked on things prioritized by the PO for one of the products that your dev teams support?

Answer 2

Actually what you're describing is very similar to SAFe (Scaled Agile Framework) or LeSS (Large-Scale Scrum) but with its own flavor.

I recommend that the management team or the CTO go through the structure of SAFe and LeSS, then decide how they want to structure the company.

Here is a comparison between both of them, it may help them identify the needs of the company and what's the best process to follow to meet those needs.

As for the risks, there will always be risks, you just need to know how & when to define them to be able to set a plan to mitigate or accept them.

And since this way of working will be new addition, it's better to have a community of practice or a team (not necessarily new hires) who'll be responsible of monitoring, coaching the other teams and improving the process until it's stabilized. The community of practice can dedicate to rolling out the process 30% of their time for example, and meet on weekly or Biweekly basis to track the progress of the implementation and anticipate risks before they happen.