Create excellent roadmaps

This article first appeared in issue 235 of .net magazine – the world's best-selling magazine for web designers and developers.

You’ve convinced your client that they shouldn’t be shipping a product loaded with features their customers will probably never use. But how do you then get the right features on the roadmap? How do you ensure that these features will add to the usefulness of the product, and that they aren’t just added on a whim?

A product crammed with features that don’t provide a tangible benefit for the business and its customers is not really a very good product. Lots of features bundled together just equates to … a bundle of features. To make a good product, you need to ‘glue’ all the features together with something that means something to those who will use the product, and also provides value for the people producing it. This glue, in my opinion, should be the benefit the product provides for these two very different groups of people.

Benefits, not features

Ask any half-decent salesman what they sell, and they will most likely recite verbatim, “Sell benefits, not features!” So why, when we are building products for the web, do we constantly fall into the trap of prioritising features and forgetting about the benefits these features provide for our customers? Because a feature is a lot easier to estimate and build than a benefit. Benefits take time to clarify, and to communicate to people. Sometimes the benefit only becomes clear when a few different features are grouped together.

Take Basecamp, the popular project collaboration tool from 37signals as an example. If you list its features, you’d get something like this: a to-do list, messaging, calendar, file storage with optional group chat and writing. Take away any one of the first four of those features and you lose the benefit – collaboration. Some of them are not mutually exclusive; for example, the to-do list (Ta-da List) is a standalone product. But the benefit is different, and so are the users.

If the benefit is not intrinsically linked to the feature or group of features, it’s all too easy for them to be prioritised upwards or downwards according to the most important – or loudest – person’s viewpoint. That doesn’t matter too much if you have a small, consistent team of people who all own the vision, but this isn’t scalable on a large project with multiple stakeholders. Helping people make the right decision for the product, by providing a clear decision-making framework, can be very helpful.

So we need to start ensuring that all of the features we design and build are intrinsically linked to the benefits they provide. But how can we do that? There are two key things we should think about: alignment and mapping.

Alignment means that everything you’re doing should be directly aligned to the vision for the product. If it’s not, then why are you doing it? Either your vision is wrong or you’re wasting resources on something that won’t give you or your customers the benefits you set out. You must continually check your ideas against the insights you’ve gathered – it’s not enough to know what you’re doing; you need to know why you are doing it as well. What’s more, everyone in the team should know why you are doing it. If people know the why, the what becomes a lot easier. You can stop having ‘what if?’ conversations, and start talking about the realities of what you know to be true.

If you don’t know something to be true then you have two choices: do some research to test your idea, or park it. You can always revisit something later in the life cycle of a product. I’m personally in favour of parking as much as possible: the less work you take on, the more chance you have of getting something out the door, and that should be your primary focus. The benefit of building something digitally is that it’s relatively trivial to build and ship something. Change is easy and instant! It’s unlike other industries, where change is something to be wary of.

It may seem that I’m talking about a ‘lean approach’ without actually mentioning it; I’m not. What I’m talking about is good design. I do think about minimum viable product (MVP) and other practices associated with the lean approach when I’m working, but not at the expense of the experience. Minimum viable experience, perhaps? It’s just common sense: do less, better, rather than everything all at once to a mediocre standard. None of what I’m talking about here suggests that you should be shipping a half-finished product, it’s about shipping a product that hits the sweet spot. And yes, this is not a new idea.

Park and ride

Let’s pretend you’ve parked everything you think may work, and are going to design and build things that you know will hit that sweet spot. You can start to map these features against the benefits they will provide, either to you or your customers. But that still doesn’t really give you a complete product.

You need to start mapping all of this so that you get a few key journeys, and then you can start designing those journeys. (You’ve actually been designing for a long time already – design is not just about quietly sketching wireframes any more.) You’ll then be able to assess which of these journeys provides the most benefit, and prioritise your work.

Grouping features in this way means that you can assign value to them. You also get complete tasks or journeys that can be designed end-to-end.

I worked on an agile project a few years ago and we didn’t do this. We were designing to user stories that had been prioritised against the amount of effort they would take to complete, both from a development and design perspective. Towards the end of the project, we started to notice ‘cracks’ appearing in the gaps between sprints. We went back and filled in these cracks, and everything worked fine.

Looking back now, it wasn’t as big a drama as it felt at the time. But there were two valuable lessons: sketching out wireframes is not where the design starts or ends; and when it seems as if your world is falling apart, the problem is probably not as big as you think. The design starts well before this, in the initial stages of the project, and the tools of choice are experience maps and user journeys. If you’re not involved in the initial stages of the project plan – which, as I said, is design – and the roadmap for the product, you’re not doing your job as a designer.

Aligning and mapping features and benefits in this way means that you can decide where you should be spending your budget for the highest possible return. How you quantify that return is up to you.

As designers, we have valuable skills that we can use to help facilitate this planning/design process. But we would be foolish to think that we can do this in complete isolation. Unless you are a polymathic unicorn, spending your own money and defining your own success, then collaboration and facilitation are the keys to success.

Discover the 20 best wireframing tools for designers at Creative Bloq.