Don’t Fund Projects. Fund the Teams That Create Value.

Most organizations are stuck funding projects — but the best product companies fund teams. In this video, we break down how to shift from a project-based model to a product-led approach using value streams, durable teams, and continuous funding so your business can adapt faster, reduce waste, and deliver better outcomes for customers.

If you’re a CEO, COO, or senior leader trying to modernize how your organization delivers value, this video gives you a practical framework for making the shift — covering everything from mapping your product landscape and organizing around customer jobs, to placing small bets, building feedback loops, and staying aligned to business goals.

Video Transcript

And so currently in a lot of organizations, what happens is we wrap up all those goals and those objectives and the desired outcomes and the timeline into a project. We say, “We’ve got a project, these are what we’re hoping the project’s going to achieve. We’re going to end up building these things. It’s going to cost X amount. It’s going to take Y amount of time to do it. ” And then we set up a bunch of teams around that project and aim to get going with the project as soon as possible. If we’re working a little bit of awards full thing, we might do a lot of discovery, spend a lot of time and design, really understand the requirements, and then we get from discovery into actually starting to build up our first MVP. And then we might think about how to scale from the MVP and start adding all sorts of features in there.

And we go through the whole product life cycle. The challenge with all this is that that project is now in place with a bunch of teams around it and it’s been funded and we get stuck having to follow that maybe for two, three years, five years, even as we’re learning things that might make us want to change. We might want to make trade-offs. We might want to increase the number of teams in it. We might want to split it up or decompose it into two smaller projects, but a lot of the structures that we set up and the way we’ve incentivized people in the system means that we follow down a path that isn’t really open to changing some of the fundamental decisions when we first scoped the project.

And so another way to do this is to think about having … Well, first we need to understand our product landscape and the current sets of products and services that we offer. So I spoke before about that work to understand our customer jobs and the pains and gains. And what we find is you have very distinct areas where it’s these sets of customer jobs that we’re trying to support, and it’s these sets of product services that are going to support those customer jobs. And we might call that this little vertical slice, this little encapsulated value stream where we are going to work and build these sets of product services and they’re going to help these sets of customer jobs. And as much as possible, we want that to be encapsulated away from, say, another vertical slice set around a very different, distinct set of customer jobs that they’re enabling.

And you can have that depending on the scale, huge number of value streams. And this is where you can get a lot of overlap with looking at business architecture and capabilities and how you might look at the landscape of products and services across a whole company. Or if you’re more technically minded, you might look at domain-driven design and do the same thing. But ultimately, we’re trying to encapsulate a particular value proposition here, and we’re trying to say that we want these sets of teams, this set of skillsets, oriented towards resolving these pain points and gains for these users and their particular jobs. Now, it’s not distinct users. It might be the users who want to do X and Y. That’s what these teams are oriented towards. That same set of users might want to do Z over here, and you might have another set of teams helping them with that.

So it’s not customers and distinct customers to every single vertical slice. It’s the actual distinct jobs for a set of customers. Now, having got that landscape and that picture, the way you can approach this is to say, “We are going to fund those sets of teams.” It might be a group of AT people, it might be a portfolio team and two product teams, and then there’s four, five, six, maybe delivery teams in a particular area. That’s the sort of scale we’re looking at often when we’re trying to encapsulate because it’s the right number of people to be able to have the communications, to be able to get really good at solving for that particular set of problems that their users and their jobs they’re trying to achieve what they have. And so we fund that set of teams and they’re durable. They exist, they collaborate, they get really good at understanding their customers there.

We try as much as possible to minimize dependencies of that group of teams with teams working to resolve pain points and create gains for another set of customer jobs. And when we allocate like that, what you do is you try and empower and give agency to that portfolio team to go, “Look, you know what the broad business goals are that we’re trying to achieve. You know what our targets are. You might have some North Star metrics, you might have certain top level revenue that you’re trying to achieve, you might have certain growth you’re trying to achieve or sort of minimal attrition you’re trying to avoid. You’re trying to avoid beyond a certain amount of attrition, et cetera.” But that team, that portfolio team for this slice of the organization knows how many people it has and knows what capacity they have and what they can get done.

And so when they think about the problems that they can solve, they can think about those problems in the right sort of scale of box that they can actually come up with the right sized opportunities and the right bets to invest in. And as much as possible, we’re trying to make those bets really small. For a lot of product organizations, it’s really important that we get to a point of seeing the amount of implicit assumptions. Loads of people have to, every time you join an organization and park on boarding, have to do your unconscious bias type of training and make sure that you don’t have unconscious bias. And one of the important bits there is everybody has unconscious bias. Well, in every organization, we have assumptions. It’s what we have to do to understand the world around us is we have to accept that we are going to make some assumptions because of the sheer complexity of it.

It’s the only way to be effective and move forward. So there are always going to be implicit assumptions, but accepting the risks and accepting that we’ve done sufficient amount of discovery to understand our market and customers, we can select opportunities and think about the experiments and the small bets we can place that we can try and meet quickly, release something, test it with our customers, get something in their hands and see if it actually solved the problems they had or created gains for them and decide, should we do more of that? Did we solve that particular job they were trying to do or at least enough of that and now solve another type of job that they have to get done? Or should we actually make it even more powerful what our product does for them so they can go even more quickly or make even more money from the products and services that we have provided to them?

And so you’re trying to flow these small bets through a portfolio and you’re learning and you’re creating these feedback loops. And now, because you’re funded and you’re funded for this capacity, you can choose to shift where your capacity is oriented. You still are accountable to business outcomes. You still have to make money for the company. So that feedback is all about, are we improving outcomes for our customers and improving outcomes for the business? And within those two big measures of success, you’re making decisions about, are the current thing problems we’re looking to solve going to continue us in the right trajectory? Are we going to keep on making more money and creating the right business outcomes?

This content comes from our product and strategy practice, which specializes in structuring product organizations for clarity, flow, and customer alignment, while linking delivery decisions to enterprise strategy.