In the pre-internet era, technology projects were defined up-front with a huge specification document, a formal business case and maybe a Prince 2 Project Initiation Document. In the internet era, technology projects got smaller as teams were able to release more regularly and deliver iterative value, and governance got lighter. Today, a team is more likely to have a roadmap than a Gantt Chart.

But perhaps we haven’t made as much progress as we thought. Most roadmaps are just lists of features, arranged on a rough timeline. The default behaviour of a team with a list of features is to complete one and then immediately pick up the next one, even if it doesn’t solve a real problem, or it solves a problem that’s no longer the most important one.

A feature roadmap puts you in a position where you can win the battle, but lose the war. Next year, all your teams could deliver every feature on their roadmap within the time estimate they’d originally given, but all the metrics that you care about could still be going in the wrong direction. That’s completely possible when you’re working through a feature-list roadmap: perhaps your features didn’t deliver what you’d thought, but you carried on doggedly delivering them anyway.

That’s why I’ve thrown away my roadmap, and asked my teams to focus on outcomes instead. Over a given time period, each team should commit to a particular outcome, rather than to a roadmap of features. Like all good goals, the outcomes they set should be measurable, and also something that the user and the organisation would recognise as valuable. For example, an outcome like ‘the user sees more marketing messaging’ is not valuable to the user and it doesn’t directly move a metric important to the organisation.

A good outcome might be something like: “Users should be able to sign up in half the time.” That way, instead of the product manager committing up front to features they think will deliver the outcome, the whole team can own the problem. That’s a big benefit of this approach: it places autonomy within teams, letting each member bring to bear their expert knowledge and creativity. The team will know it’s done when users can sign up in half the time, not when the features are shipped.

If I were leading an expedition, and I told my group I wanted them to build a bridge, they might spend a lot of time trying to find the right materials, or they might end up building a bridge that wasn’t strong enough to support the whole group. But if I told them I wanted to get the whole group across the river, they could solve that problem in lots of different ways — building a raft, finding a narrower point to cross — and they’d know they weren’t done until they had all got across the river.

It’s not always easy to get buy-in for this approach across the organisation: senior managers are used to the reassurance of knowing exactly what each team is planning to build, and when.

The hardest group to persuade will be your finance department. This is not how traditional budgeting works. Submit your business case for a project; secure your ‘resources’ and funds; report on progress against your plan. It’s not unreasonable for your finance team to want this kind of information: they’re responsible for distributing the organisation’s funds in a way that will help it fulfil its purpose, maximising ROI and then monitoring that things are going as expected.

So persuade them to fund outcomes rather than projects. Perhaps next year one of your goals is to reduce the number of calls to your call centre by 50%. You’ll need to fund a multidisciplinary, agile team to achieve that goal. But there’s no point in having a committee of senior executives and finance people arguing over what features or products they’ll need to work on to get there. Discovering what to build will take user research, prototyping, experimentation, and a great working knowledge of available technologies. That stuff is a full-time job; it’s the job of the team.

Help finance teams know that the activity they think they’re doing to mitigate risk (pinning down what the year’s projects are, and estimating how much benefit they’ll bring) is actually increasing risk (by forcing a team to commit up-front to what they’ll build, rather than allowing them to learn, iterate and course-correct towards an outcome).

The finance people should be happy with this: it’s actually a very commercial way of thinking. It makes teams focus ruthlessly on the value they’re delivering, rather than the features they’re shipping. It makes leaders be strategic instead of being fixated on the detail, by asking them to articulate the most important outcomes the organization wants to achieve next year, and how much they are willing to fund each outcome.

Perhaps you’re sold on the idea, but you’re not sure how to convince people outside your own team. Here are some practical steps for making the change:

1. Find an ally in your finance team. Identify someone who’s sympathetic to budgeting in a new way (perhaps someone who’s experienced the problems of the old method) and explain the arguments for why this is more effective.
2. Start early. By the time the formal process for the next cycle kicks off and you’re asked to submit business cases and annual budgets, it’s too late.
3. Lead with one team. If you can’t secure agreement for moving the entire organisation to funding outcomes, volunteer to prove it out with just one team.
4. Give evidence from other organisations. Show them this article, or others from Public Digital, to demonstrate that others – from the UK’s Government Digital Service to the Financial Times – have changed how they organise their work and their money.

If your organization doesn’t change the way it approaches funding, no amount of ‘agile transformation’ will stick. So it’s time to throw away the roadmap and the project-by-project business cases, and focus on outcomes.