Host Intro (Gene Kim)

So I think what's super interesting is that I've always thought of option value as being somewhat obscure, and I don't claim to be an expert at it, but I'm just so interested that it's increasingly becoming more mainstream.

Which leads us to the next talk, which is Dr. Mik Kersten, CTO of Planview. I met him in 2016, and for most of that period, we've been talking almost every week or two because I learned from him what great software architectures look like, which create genuine economic value through option value.

So many of you know him for the fantastic book Project to Product that he wrote seven years ago, which so many organizations used to change how they think about their software efforts. His next book, Output to Outcome, is coming out next year. For years, he's reinforced how architecture dictates the performance of the system. It creates independence of action. It allows them to create value.

For the last two days, we've heard so many hints on how AI may reshape organizations. Team sizes may be shrinking. They may act more decentrally. They may operate with less coordination. Who knows? So Mik will present why these things are even more important than ever to how we must revise our management systems and methods, and why probably architecture will become even more important than ever. Here's Mik.

Mik Kersten

Thank you, Gene. Thank you, Gene. It's great to be here. This is always my favorite conference of the year. The last two days, I think, have been pretty mind-blowing in terms of what we've learned around the power and the productivity that will come from vibe coding and agentic software.

I spent personally basically all of 2023 and 2024 building Planview's agents for product management, portfolio management, and value stream management. I often get asked: is this shift to product sufficient to thrive in the age of AI? I think it's necessary, but it's not sufficient.

So I've spent pretty much all of this year writing the follow-on book to Project to Product called Output to Outcome, about how I think we have to change our entire organizational model to leverage these massive capacity gains that are coming with AI. I'll give you a preview of that today and just start with a really quick history dive on these last 250 years of technological revolutions.

I think what's so interesting about each of these is that in each one of them, there's been some new means of production that have made building things much, much cheaper, much more scalable, and made the marginal cost go basically down to zero.

In the Industrial Revolution, we had water that was powering really that revolution and automating manual labor. All of a sudden, there became this new constraint around how much we could power, and we had to come up with new management methods such as division of labor to handle that.

Fast-forward, we had steam, electricity, combustion, and in the age of oil and mass production, there was line throughput. How many cars could you build? How much waste could you eliminate from production lines? So the management systems really became lean, all around eliminating that kind of waste.

Now, in the age of software and digital, things were powered by compute. Knowledge work and developer productivity became the constraint. So I spent two decades working on developer productivity. A lot of us are really passionate about it. What we're seeing right now is transforming completely.

It feels like the marginal cost of building software, of agentic software, is going to bring the outputs that we can create through development teams, and combinations of teams and agents, down to zero. These marginal costs will go to zero. All of a sudden, those outputs will no longer be the constraint.

I think in this age of AI, which feels like it is kicking off right around now, it will be powered by cognition, the ability to automate not manual work, but knowledge work. I think in every age there's going to be another constraint. The constraint just moves somewhere else. Theory of Constraints tells us that every complex system has a constraint.

So I think the constraint is now going to be organizational productivity and how organizations can leverage the fact that a developer can now produce 10 times the output, or they can have teams of agents cooperating with people. I think it's time for a new way of looking at the new management discipline, where we're not so obsessed with managing apps and features and defects and tech debt, but where we're actually focused on just managing outcomes as outputs become effectively free and scalable.

So this slide, I'm amazed I'm still using this. John Smart is sitting in the front of the audience here. This actually came initially from a slide that he had, but this is backed with real data. In 2023 and 2024, Planview released the State of the Project to Product industry report, where we took 36 organizations, nearly 4,000 value streams, where we connected data from all the tools, the Jira, ServiceNow, GitHub, GitLab, and so on. We saw how data flowed end to end.

What we saw is that in the end-to-end delivery time, only 8% of that time is spent by agile teams building software. Keep in mind, these are almost entirely enterprise organizations. If you look at some of the elite organizations, of course, you'll see much more green in tech giants, unicorns, and so on, where you'll see like 50%, 60%, 70% is green. But this is the reality for the organizations that I work with.

You've got DevOps, but not at a sufficient scale. So still a lot of friction after the teams, in security reviews, compliance, and so on. The problem is that development teams are not the constraint. If you invest in something that's not the constraint in the system, you're actually not going to get more throughput. So you could 10x the productivity of developers and get no more outputs.

This is the challenge: most organizations' operating model today is not ready for these massive capacity gains from AI. I actually think this is turning into an existential threat because we now already have organizations who are able to leverage this. If your competitor is able to deliver 10 times more value than you can, how can you possibly compete or last in the market?

This is exactly where organizations now have to look and examine whether they are ready and whether they are structured to leverage these massive capacity gains. Again, Theory of Constraints means that chances are their bottlenecks are elsewhere. They're not in development. They're not in the production of outputs.

I think we need to move the entire operating model of organizations from managing outputs, which is frankly what we've been doing in our career. It's fun to manage output, and it's fun to build things, but we need to shift the operating model to managing outcomes.

At the core of Output to Outcome is this notion of the outcome loop. The entire book is a series of actually 10 different mental models, I hope, to make it easier for organizations to apply outcome management. I'll take you through this first one, the outcome loop.

You've got your inputs. We understand those very well: the strategy, budget, and so on. Outputs: the things that we've gotten so good at building are all the activities that we do, so all the coding and vibe coding and working with agents and so on that produce artifacts like applications and features and so on. The key thing is that these need to drive business outcomes. Those are customer outcomes as well as employee outcomes.

We're used to planning. That can be roadmapping, agile plans, and so on. Flow: connecting how outputs actually get shipped and delivered. Objectives, such as OKRs: how we connect the strategy in terms of the outcomes we want to see, revenue, profit, customer satisfaction, market penetration, and so on. Then, of course, the feedback: are we getting those, and the feedback back into our plans?

Now, when you look at this outcome loop and think about this as your whole organization, the key thing is those outputs, again, they're going to get multiplied by two and then by four and then by 10 and so on. You're going to be able to do a lot more output. We've heard in the last session you can actually parallelize some of this. With AI and agents, you can imagine spinning up a hundred agents to do one version of the application and another batch of agents to do another version and test out 10 different versions of the application, all in parallel.

The key thing is the outputs that we've been so accustomed to being the main constraint will no longer be the constraint. The question is: where is the constraint in your organization's outcome loop? Are you planning fast enough? Are you able to actually get those feedback cycles in days instead of weeks? Are you able to scale your value streams to support these outcome loops across the entire organization?

Of course, many organizations are more complex than this. This actually could be what the first single-person unicorn looks like, where you've got agents producing all those outputs and someone creating a billion-dollar company that way. But for most of us, our organizations are more complex than that. So the second model in the book is the outcome tree.

These outcome loops are your value streams. This is how you deliver value to the customers. Value streams need autonomy. Value streams need independence of action. And as you'll see shortly, value streams need modularity.

Value streams are the main unit that you compose your company into rather than functions, rather than this weird matrix of teams and HR structures. Basically, you've got this cascade of value streams. At the bottom of that cascade, you've got your teams. Those teams are combinations of humans and agents. Of course, we'll have teams of just agents.

Those inputs cascade down in a mutually exclusive and collectively exhaustive way. There should be no duplication. Each of these things should be independent, should be modular. Just the way your budgets cascade down through your HR structure, your HR structure just becomes replaced by value streams. The HR structure actually becomes the value streams. Of course, the outcomes cascade up. You've got multiple products, living value streams, and platform services. All of that cascades back up.

The whole goal is to make it easier to shift to these structures. I'm going to go through three of the shifts in this presentation. The shifts are functions to flow, vanity to value, chaos to cadence, matrix to modularity, Gene's favorite, objectives to ownership, silos to segments, and then managers to makers.

I'll start with functions to flow. In functional org designs, again, the starting point for most of those organizations that had those big red bars getting in the way of their productivity, we've actually got completely the wrong structure to leverage these massive output gains. It's even the wrong structure to focus sufficiently on developer productivity in the traditional sense, because the org chart is more connected to organizational functions and not connected to customer centricity and flow.

The shift from functions to flow really involves creating this value stream organizational design, which is this self-similar and scalable nested tree of value streams. Each of those value streams needs to have autonomy, needs to function independently, and needs to have its own outcome loop. That outcome loop needs to be able to iterate as quickly as possible for that particular domain, with its functions.

If this is an incubation set of value streams, it had better have an outcome loop that's able to turn in days and spin up many agents and support many teams in parallel. This outcome tree needs to take over the traditional HR structure. So the objectives and key results, if you're using those, need to cascade down this. But the incentive structure needs to match this.

You might use a single-threaded leadership model. You might use a two-in-the-box or a three-in-the-box leadership model. But the incentive structure for all those leaders needs to match the outcome tree so that we, again, have ownership of objectives and that we have something called this dedicated leadership model, where every one of those nodes in the outcome tree has a team, has dedicated one-in-the-box, two-in-the-box, three-in-the-box if needed leadership, and is able to independently deliver those outcomes and cascade them up to the organization.

The next model is the chaos to cadence. I think what's happened with a lot of organizations is that they've brought in engineering practices, platform engineering, agile, DevOps, and so on, but not really changed their operating model. The quarterly business reviews, the annual planning, are a separate set of processes. None of these things move fast enough to really leverage feedback loops that need to move at the speed they need to move at to really thrive in AI.

We've got these separate cadences, and again the shift is to throw away all of that to create a unified planning process across the entire organization. That's the only way those outcome loops can move quickly enough and you can get feedback quickly enough back into the budget, unlock more budget if you're seeing more productivity with this team leveraging these new kinds of agents that came onto the market two days ago, or whatever the case may be.

The key thing is to move to a single cadence model, and still weekly, monthly, quarterly, and annual, but a single cadence model across that whole outcome tree cascade for your entire organization.

The next one is to move away from the way that most organizations track objectives to this mutually exclusive and collectively exhaustive ownership in the outcome tree. So that you go away from these complex dependencies where multiple leaders own multiple things, which do tend to be an artifact of these functionally structured organizations, where you've got an engineering leader, a product leader, and a business leader, and someone in operations all owning things that don't quite overlap. You end up with diluted and shared ownership.

Whereas in the outcome tree, again, you have to have clear separable ownership so that each value stream can have its autonomy and its incentives aligned to delivering those outcomes. Of course, at some point, some of these value streams will be purely delivered by agents as well. Those agents need a scope. Of course, that scope needs to align to what your software architecture is as well. Otherwise, you won't have that kind of benefit of modularity where what happens is a change over here can break dependencies elsewhere or can break other parts of the system.

This is the outcome ownership model, where again, there's ownership and you've got the ability for each value stream to be loosely coupled to the other value streams.

Which brings us to this next shift: from matrix to modularity. I think one of the biggest problems I've seen, by the way, from the data, because we've done a lot of data analysis and visualization on the data that you saw on the red and green chart earlier, is just how tangled organizations are and how many dependencies they have.

We all understand, and I'll dig into this in a moment, the benefits of modularity. But the way that communication architectures work today, it's just not like that. You'll see this in the meeting structures for your organization. There's massive coordination costs in making changes, in getting new budget for something that's promising, and so on, and this complex decision-making.

I've actually come to realize that a lot of the tech debt that we have comes from that. It's just a simple extrapolation of Conway's Law: if you've got a complex matrix of your organization, you're going to have complex dependencies in the software that you produce because you both are a tangled, messy matrix.

The idea is that you need to shift to organizational modularity, which matches your software architecture modularity: these scalable and composable value streams. This is really straight from Gene Kim and Steve Spear's Winning Organizations, the independent action model. Each value stream needs to be able to act independently. This, by the way, means you'll have some duplication. But duplication, of course, is much easier to manage when you've got agents who can build and rebuild things and maybe later extract new value streams for something that should be a platform service because three or four different value streams are using the same data pipeline or something similar.

I'll dig into this one just a little bit more because I think it's so core to what's needed to create these outcome trees, which really become the primary structure for organizations as you shift away from traditional org charts to this new operating model.

For outcome, in terms of modularity, I'm very excited, by the way, as Gene mentioned, that Carliss Baldwin speaks after me. She's been my hero for the past 25 years now, I guess since I first saw her speak and have been following her closely.

Modularity gives us option value. The way modularity works is we want something called high cohesion in software. That means that common functionality is encapsulated. This functionality over here is all related to some kind of function, and it's loosely coupled to other functionality. We've got low coupling, which means we have fewer dependencies between modules.

When you do this, you've got option value. You can basically reconfigure your platforms, your portfolios, your applications to do all sorts of different things. You can let agents loose within a single module to evolve that, create 10 versions of it, and so on. It's this beautiful Lego-like feeling that we all get.

We need the same thing for our organizations as well. We need value streams to have modularity. That means each value stream needs to encapsulate expertise and ownership and complexity domains. Really, that needs to be the structure for your organization as these agents will be able to build all of it. You need people who understand this aspect of customer behavior the best, these kinds of outcomes that they're after, and how to structure those roadmaps and really the objective key results and the outcomes that will now be so much easier to build, and of course, how those nest and cascade across your whole organization with the various products and platforms that you have.

Then, of course, we need to decrease dependencies between those value streams. The whole point of this outcome tree is that it's a hierarchy, and you're minimizing the number of dotted lines, matrix lines, across that hierarchy. You've got as much optionality as now shifting around in it, again, to pull this thing out, promote it to be a first-class platform and service, something you invest further in, and so on.

The whole point is that these concepts of modularity become, again, a primary part of how you think about your organizational design and matching up your organizational design to your software architecture, to your value stream architecture. That customer centricity, this is the concept of sociotechnical congruence. This is really at the core of how to approach these outcome trees. Then, of course, with that, be able to let loose these agents on building outputs much faster to really deliver on those outcomes, do parallel hypothesis testing and all of that.

I think over the past decade or so, as we've watched organizations transform both into the product model, apply DevOps and agile practices, there's been this concept that came from Kotter's book called Accelerate, where he really challenged organizations to take their organizational chart and overlay a second operating system, a second operating model over it.

I think outcome management, you can think of it as your second operating model, but I think the key thing is to throw away your existing operating model, which is, again, the functional hierarchy. The organization is based on functions and all these matrix lines that connect things up. Then actually make the outcome tree your primary operating model, because that's exactly how you can be able to leverage these massive output gains that come from the age of AI.

So in terms of help I'm looking for, the book is, I don't know, it's like 80% done or so. I have about two months of writing left. That also means that it's a great time for me to get any of your feedback on these models, how they will work for your organization, things you like and don't like about them.

I'd love to get input on these 10 mental models, the models that are meant for consumption by you and to make it easier for you to apply outcome management, as well as to have agents leverage these models and how they can scale the delivery of outputs as well.

If you got a copy of the book at the book signing, that's great. If you would like an electronic copy, just send an email to that email address and I'll collect all the feedback that you send there as well. So with that, thank you very much.