In Networked, Scaled, and Agile: a design strategy for complex organizations, by Kates, Kesler & Dimartino, there’s an insightful concept of the vertical organization with a few layers of leadership work (see picture below).
Regarding the three layers of leadership, I think most companies have already adapted to this structure: C-level, Product Management (with some naming variations), and the (tactical) Product Owner. While this is a good idea, I’ve noticed that companies tend to implement it too rigidly. The problem with such strict layering—especially at the operational level—is that the role often gets minimized and excluded from strategic decision-making. This, in turn, might create decision blockers and ultimately breaks the company's agility (contrary to what the authors intended).
I’ve encountered the same kind of confusion in practice, as you mentioned—where software released to production is seen as the product release. This is one of the reasons why ideas have emerged to make sprint lengths more flexible (treat the symptom, not the cause).
Beyond this, I’ve noticed another important point in the corporate world that adds context. Releasing something into production that isn’t a fully working feature (or product) is often seen as an additional risk by product teams. When we try to mitigate these risks with specific measures—such as feature flags, hidden links, or silent releases—it can introduce additional development costs that may not make sense from a business perspective. On top of that, since we still have a lot to learn about properly sizing and defining PBIs, the distinction between software and product releases becomes even blurrier.
In the end, the solution is to find the right balance and avoid drawing rigid lines of accountability. This is one of the best aspects of Scrum—the team decides, and within that team, both product and development work together.
Of course, some changes happen under the hood, with no visible or meaningful impact on end users. These typically fall into a different category, where there’s little debate about whether they should be released as often as possible.
Just my perspective—from the eyes of a product person—so it might be a little biased. 🙂
Thanks for adding your experience and perspective. Good point on the perceived risk by releasing something that is not expected to work yet. I do believe though is largely just a misconception -- and often don't even need to fancy things like feature flags, etc. I believe there are ways to do well-engineered transition that starts merging code that is completely disconnected, thus won't do anything, but at least you're testing and making sure the added code doesn't break anything else, until the very last change that makes the code now operational. At least I have heard from code wizards out there this is possible...
I agree there's less of a debate on deploying more often for other nature of work, the way sometimes that's done I believe has the potential to cause ore risk then having a practice of trunk-based development across the board... Like when new features are done in a branch, while the trunk kept being changed hear and there, and the further complications that may emerge. I in fact have been in the tail-end of stuff like that in my practice, having to explain to stakeholders why a behavior that had been hot-fixed came back with a new more structural release (coming from the "product layer").
It's a fascinating topic that ultimately, at least in my mind, speaks about "craft"...
As you said, having the "code wizards" on your side (as a product person) always brings more confidence and helps reduce the perceived risk. I really miss the dev teams I worked with, those for whom 'craftsmanship' was embedded in all their work.
This post does highlight an apparent conflict between "significant" release (what Product people advocate for), and "practical" release (what tech people advocate for).
The conflict is only apparent, in my opinion. We must decouple the "significant" from the "practical" as SW needs to (even must) be released in working condition as often as technically feasible.
The "significant" part however (6 weeks for "meaningful" features ) is a fake problem. One that is driven by inability to figure out how to test features before the code is written.
I've been advocating for several years that testing features must be decoupled from software code being written. The reason is simple, you don't want to write code that isn't necessary. Code is a liability, we want to maximize value while minimizing code delivered. I'll write more on that at a later point, but this article is worth a read. Well done Rodrigo!
Regarding the three layers of leadership, I think most companies have already adapted to this structure: C-level, Product Management (with some naming variations), and the (tactical) Product Owner. While this is a good idea, I’ve noticed that companies tend to implement it too rigidly. The problem with such strict layering—especially at the operational level—is that the role often gets minimized and excluded from strategic decision-making. This, in turn, might create decision blockers and ultimately breaks the company's agility (contrary to what the authors intended).
I’ve encountered the same kind of confusion in practice, as you mentioned—where software released to production is seen as the product release. This is one of the reasons why ideas have emerged to make sprint lengths more flexible (treat the symptom, not the cause).
Beyond this, I’ve noticed another important point in the corporate world that adds context. Releasing something into production that isn’t a fully working feature (or product) is often seen as an additional risk by product teams. When we try to mitigate these risks with specific measures—such as feature flags, hidden links, or silent releases—it can introduce additional development costs that may not make sense from a business perspective. On top of that, since we still have a lot to learn about properly sizing and defining PBIs, the distinction between software and product releases becomes even blurrier.
In the end, the solution is to find the right balance and avoid drawing rigid lines of accountability. This is one of the best aspects of Scrum—the team decides, and within that team, both product and development work together.
Of course, some changes happen under the hood, with no visible or meaningful impact on end users. These typically fall into a different category, where there’s little debate about whether they should be released as often as possible.
Just my perspective—from the eyes of a product person—so it might be a little biased. 🙂
Thanks for adding your experience and perspective. Good point on the perceived risk by releasing something that is not expected to work yet. I do believe though is largely just a misconception -- and often don't even need to fancy things like feature flags, etc. I believe there are ways to do well-engineered transition that starts merging code that is completely disconnected, thus won't do anything, but at least you're testing and making sure the added code doesn't break anything else, until the very last change that makes the code now operational. At least I have heard from code wizards out there this is possible...
I agree there's less of a debate on deploying more often for other nature of work, the way sometimes that's done I believe has the potential to cause ore risk then having a practice of trunk-based development across the board... Like when new features are done in a branch, while the trunk kept being changed hear and there, and the further complications that may emerge. I in fact have been in the tail-end of stuff like that in my practice, having to explain to stakeholders why a behavior that had been hot-fixed came back with a new more structural release (coming from the "product layer").
It's a fascinating topic that ultimately, at least in my mind, speaks about "craft"...
As you said, having the "code wizards" on your side (as a product person) always brings more confidence and helps reduce the perceived risk. I really miss the dev teams I worked with, those for whom 'craftsmanship' was embedded in all their work.
This post does highlight an apparent conflict between "significant" release (what Product people advocate for), and "practical" release (what tech people advocate for).
The conflict is only apparent, in my opinion. We must decouple the "significant" from the "practical" as SW needs to (even must) be released in working condition as often as technically feasible.
The "significant" part however (6 weeks for "meaningful" features ) is a fake problem. One that is driven by inability to figure out how to test features before the code is written.
I've been advocating for several years that testing features must be decoupled from software code being written. The reason is simple, you don't want to write code that isn't necessary. Code is a liability, we want to maximize value while minimizing code delivered. I'll write more on that at a later point, but this article is worth a read. Well done Rodrigo!
Thanks for the great addendum, Vasco!