The Tree of Up

In expressing Up’s public product roadmap visually – as a tree of features with branches linking groups of functionality – Anson began a new kind of dialog with both customers as well as co-workers. He’ll take you through the experience and impart some of the lessons learned.

Starting with a digression into cars… BMW rationalised the way it named its models, using a mostly-but-not-always numbers system to indicate rough size and price. This works with hardware.

Software is different. It changes and pivots, it’s less predictable. To encompass any new item of scope, you can either expand your scope to envelop that from where you are; or you can pivot and move to that point with similarly sized scope.

Products have a trajectory and how fast you move from where you are along that trajectory is your velocity.

Up is a digital bank, built by engineers rather than bankers (there is a bank backing Up of course). Their mission is to connect people with their spending more. They look at everything through the software lens, which is why they have such a different approach to simple things like the design of their debit cards.

They added ‘chat’ to their app rather than ‘support’ because all customer dialogue goes through it. They can do surveys with customers very quickly. They have about 500 conversations every day and a lot of them are in the ‘ideas’ category. Which is really cool that customers are excited enough to think about this stuff.

They were finding they were saying “it’s coming soon” a lot; and they also tag conversations so they could notify them when the feature shipped.

While a public roadmap isn’t going to be right for all companies, it works for Up. For those companies that do provide one it’s often a lot like a Trello board – now/next/done kind of stuff. But they miss the dimension of how things are connected. Things have dependencies. Some things have to go first.

So Anson thought a diagram would do a good job of articulating that. He had some inspiration from a game he had on his phone, with a technology tree. It was a cool way to visualise interconnection of features. Quite a few games have them.

Started with a brief coding experiment before realising he had to see if it worked at all; so he mocked it up in Illustrator. People liked the mockup and it went from there, and it became known as The Tree Of Up.

The diagram shows groupings and links between related features; and indicates their status. It makes it easy for lay people to understand things like the need to support multiple accounts before you can support shared savings.

Technically this is kept very simple, it’s an SVG exported from Illustrator, some JS mapped to JSON and put on the website. While it would be cool to automate it, the time hasn’t really been worth spending yet.

The most common question is why share this? Doesn’t this give your competitors a blueprint? Not really – it’s the ability to execute that’s important. Most of the ideas will have been considered, plenty of other banks would want to do them, but haven’t done so yet. There are lots of things that are tricky to build in banking.

Screenshot of a detail in the Spring Up Tree

The next step in the roadmap was the Spring Up Tree – a renewal of the tree, adding new feature ideas. It was a bit of a test to see whether the tree would scale; and so far it does.

One learning is that it’s not really useful to put dates on there, they change too much and it annoys people when you don’t meet them. Better to just show the shape.

Two rules of banking: keep people’s money safe; and give people access to their money. But curiously lots of people ask to have their savings hidden away from them! So you have to be careful building something like that.

The tree does a great job internally as well, to show people the bigger picture. The visual approach really helps people understand where they are and where they are going.