# The Scaling Paradox: Why Your Success is Now Killing Your Speed (aka why the heck would you need to shift from managing projects to products? ) : transcript

Automatic transcript of the published podcast audio. Recognition errors are possible. Speakers are unlabeled; do not attribute a passage to Yuval or a guest without checking the audio.

Episode: https://yuvalyeret.com/scaling-ai-podcast/the-scaling-paradox-why-your-success-is-now-killing-your-speed-aka-why-the-heck-would-you-need-to-shift-from-managing-projects-to-products/
Source RSS GUID: substack:post:161734821
Source: published Riverside RSS audio enclosure
Transcription: faster-whisper base.en, English

## Transcript

[00:00:00] Why do we need a product operating model?

[00:00:03] How does it help us get out of a stole product organization towards a healthy product organization?

[00:00:12] At the beginning of its life, the typical product is managed and delivered by one team.

[00:00:18] And when it's one team, there are fewer dependencies, it's easier to connect to our goals,

[00:00:23] and especially if we're developing a new product,

[00:00:27] it's very clear that what we're trying to do hopefully achieve product market fit.

[00:00:32] If we're successful, we'll start to grow.

[00:00:38] We'll start to see demand for more functionality for this product.

[00:00:44] It becomes harder and harder to be aligned to exactly what is it that the product needs to be,

[00:00:52] and there's demand for more and more features.

[00:00:54] And the organization typically grows in a specialized fashion.

[00:00:59] And what happens is two main things.

[00:01:02] One is more and more of a work is structured as features.

[00:01:07] You can see it's almost impossible to see what is the goal, what is the compass,

[00:01:12] what are the outcomes that we're trying to achieve.

[00:01:14] More and more of the conversation is around scope and timelines.

[00:01:18] And it's also harder and harder to deliver these features,

[00:01:21] because more and more of the features require collaboration across teams.

[00:01:27] So as we add more and more teams and work with bigger teams on these products,

[00:01:36] it becomes harder and harder to actually maintain traction and deliver value.

[00:01:42] This becomes even harder when we start to manage multiple products

[00:01:47] or start to work on initiatives that require collaboration across the company.

[00:01:52] At that point, the dependencies are even wider,

[00:01:55] and even though we created separate product groups,

[00:01:59] a lot of the work actually cuts across them.

[00:02:02] Maybe because of how we created these groups,

[00:02:04] maybe because we're trying to do interesting things across those products.

[00:02:09] But often, everything becomes a project.

[00:02:12] Most of the work will span most of the organization,

[00:02:16] and it's very tempting to start to use traditional project and program management

[00:02:21] or other management techniques.

[00:02:24] Overall, if we look at the sort of work that we manage in a scale-up product organization

[00:02:31] or any technology organization,

[00:02:34] there's very real work that is managed by empowered product teams.

[00:02:40] Those become the sort of unicorns within this organization.

[00:02:43] Much of the work is managed in a feature factory inside product groups.

[00:02:49] And a lot of the work is actually managed more and more as projects.

[00:02:55] So even though we might be an agile organization with a lot of the agile retools,

[00:03:02] a lot of the work is actually managed in a traditional way oriented around features

[00:03:07] cutting across the organization with classic program management practices,

[00:03:11] even if they're masquerading behind agile names and techniques.

[00:03:16] So what do we do about that?

[00:03:19] What we want to create is we want to flip this pyramid.

[00:03:24] We want to create an environment where most of the work is actually managed

[00:03:29] in empowered product teams that focus on outcomes,

[00:03:34] that serve the strategic goals that our organization is focused on,

[00:03:40] that would require us to align on what are those strategic goals,

[00:03:43] what we want to focus on and what doesn't make sense at the moment

[00:03:47] from a prioritization perspective we cannot afford to focus on.

[00:03:52] Creating these empowered teams that can run on their own might require us

[00:03:57] to create platforms and enabling teams, internal products,

[00:04:02] where the goal is to actually serve empowered product teams.

[00:04:08] Some of the work will still be managed by product groups.

[00:04:12] It will probably be hard to create an environment where everything can be managed

[00:04:18] in single teams, but we need to carefully manage this relationship

[00:04:23] between how much work is managed in empowered groups and in empowered teams.

[00:04:29] We'll still be strategic initiatives that require collaboration across

[00:04:34] the organization or attention from leadership of the organization.

[00:04:39] Those would be strategic cross product organizational bets,

[00:04:43] but even these small set of projects we want to manage using flow.

[00:04:52] So limiting the amount of these projects that we manage and trying to close feedback

[00:04:58] looks faster and orient them around outcomes and steer them using evidence.

[00:05:03] So essentially use product thinking even for these initiatives.

[00:05:08] Overall, what we're talking about here is the healthier pyramid

[00:05:13] where most of the work is managing empowered in aligned product teams.

[00:05:18] They are aligned to our strategic goals, but we don't manage them or we don't micro manage them.

[00:05:26] They're informed by where we want to go.

[00:05:29] Some of the work that we cannot manage this way is managed in empowered product groups.

[00:05:35] And a smaller set of initiatives is managed as product oriented portfolio initiatives.

[00:05:44] This is obviously not an overnight change for an organization.

[00:05:48] It requires architecture.

[00:05:50] It requires different techniques.

[00:05:52] It might require different structures, different pillars and aspects that navigate this journey.
