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?

  • 2
    These aren't "products." They're components of a unified value stream (or should be). This is definitely an anti-pattern.
    – Todd A. Jacobs
    Commented Jan 28, 2018 at 19:40
  • @ToddA.Jacobs That's how I understand it, too, but I lack arguments (or precognition powers) to explain why that wouldn't be such a great idea. Right now the attitude is "Who'd be worse off if we do this? If nobody, let's do it." If you have an answer or a real-life example, please post it.
    – I.M.
    Commented Jan 29, 2018 at 10:14
  • Downvoter, care to explain?
    – I.M.
    Commented Jan 29, 2018 at 11:14

2 Answers 2


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?

  • Thanks! This is actually quite close to my own understanding (I'm the PO on one of the 'usual,' dev products). One problem with answering the question you suggest may be that M&M have their own priorities (company priorities, if you will). They don't 'support' dev products, they 'bring as much business value as the devs'. So their priorities can't be set by the dev POs, unless we are talking about a significant power battle.
    – I.M.
    Commented Jan 29, 2018 at 10:08
  • Also, when I tried to argue that the supporting product could not be its own product, we ran into a debate over this article. If spellchecker in a text editor is a product, then why not travel booking? If the website of an airline is a product, then why not our presentation webpage? There must be a core issue that we are missing, I wish I knew how to define it...
    – I.M.
    Commented Jan 29, 2018 at 10:22
  • On a company level, I would say that a product is something that brings revenue for the company and if it doesn't, then that product should be discontinued. Commented Jan 29, 2018 at 11:34
  • This is a very broad discussion and different people look at it different ways. Mike Cohn's article definitely has a more open view of what a product is, but also warns against sub-optimizing as you break down products. So, if a website is considered its own product, how does it measure value added to the market? Same with the management tasks. And note that he still looks at these products in the context of the broader product.
    – Daniel
    Commented Jan 29, 2018 at 18:09

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.

  • That doesn't really answer the question.
    – I.M.
    Commented Jan 29, 2018 at 10:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.