Saying No To Features

Alice Newton-Rex at UXDX Europe. Video: https://youtu.be/tGKKcy1iG3M

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

The quest for the perfect roadmap

[00:00:01] Good morning. I'm Alice Newton-Rex, and I'm chief product officer at WorldRemit, an international money transfer startup. We help our customers send money from 50 countries to over 150 countries. Our customers are mostly migrants sending money back to their family and friends in Africa, Asia and Latin America.

[00:00:17] I've made a lot of roadmaps in my time, and I've made a lot of different kinds of roadmaps. In fact, looking back on my first three years at WorldRemit, I counted that I had represented our company roadmap in no fewer than ten different ways. It almost seems like it was a bit of an obsessive hobby of mine. Some of these roadmaps were quite simple; others were a bit more complex. Most of them were digital, but we also had our fair share of physical ones put up on the walls around the office. Some of them were basically just fancy-looking Gantt charts, but others were nice and round. The vast majority of them represented time on the horizontal axis, but some of them even went vertical for time, like this one, which is shaped more like a funnel.

[00:01:05] Before deciding to seek professional help for this particular obsession, I decided to talk to a few friends in the industry, and I was relieved to discover that this is quite a common affliction. It's as though we're all on the quest for the perfect roadmap. And I think we agreed that a lot of the reason for this reformatting is an attempt to make our roadmap work harder: to make it bring more focus to the team, to make it communicate better with stakeholders, to make it help a growing team stay pointed in the same direction.

The problem with a list of features

[00:01:50] But all of these roadmaps have one big problem in common, and that is that they're essentially just lists of features arranged on a timeline, albeit a relatively vague timeline. The problem with a list of features is that the rest of your company and your clients view it as a commitment. That creates a lot of external pressure to keep building the things on the list, even if they don't solve a real problem, or they solve a problem that's no longer your most important one. It's as though this guy was like, oh, but the next thing on my roadmap was to descale my fish, when we know that really he should be taking some time to look around and see if anything in his environment has changed.

[00:02:30] Quite seriously, the default behavior of a team with a list of features is just to complete one feature and then start picking up the next one. But your users don't want features completed; they want their needs met. So you're starting to incentivize the wrong behavior. And as a product manager, it traps you in having the wrong conversations. In a big company, a top-down culture often ensures that senior executives or stakeholders just want to hand down features to the team to deliver. Even if you work in a startup, you'll probably find that the founders have a number of features in their minds, and if you create a list for those features, they'll just start filling it.

[00:03:12] That leaves you in the position of essentially just being the order taker, and the most that you can do is take these features from other people and try to shepherd them through to live in the best way possible, which almost definitely isn't why you went into product in the first place.

Winning the battle but losing the war

[00:03:23] The other problem is it can put you in a position where you win the battle but you lose the war. Picture this. It's the end of the year and you're standing in front of your executive team, explaining to them that you delivered every feature on your roadmap within the time estimate that you'd allocated for it. Now, leaving aside how completely implausible that is, even if that were the case, you might still find that your management team is shouting back at you that all the metrics they care about are going in the wrong direction. Perhaps the features you had committed to didn't deliver what you thought they would, but you carried on doggedly delivering them anyway. So we have to stop defining success in a way that can incorporate failure.

[00:03:58] One of my most frustrating professional experiences was galvanizing our whole product and engineering team to work together on one feature that was intended to save tens of thousands of pounds for the business every month. Sounds great, right? We started working on it, and as often happens, various unexpected things came up, and it ended up taking months more to deliver than we thought. By the time it was ready to launch, we found that our finance team had been able to make that same saving by creating a strategic partnership in the affected market. We never even turned that feature on. But if we'd been completely focused on the outcome from the beginning, rather than just shipping the feature, then we could have saved all that wasted engineering time, and, I need hardly say, the negative morale impact that came with not turning that feature on.

Commit to outcomes, not features

[00:04:49] So how do we get there? How do we start having the right conversations? Well, we need to say no to features, and we need to start talking about problems. We need to start talking about outcomes. If your team is successful, what will the world look like next year? How will your users feel? What will your users be able to do? In practice, this means that each team needs to commit to an outcome, not to a roadmap of features, over a given time period.

[00:05:19] Like all good goals, that outcome should be something that's measurable, and it has to be something that the user and the business recognize as valuable. It can't be so small or partial as to be meaningless. A bad goal would be something like "the user sees more marketing messaging," because that doesn't deliver any value to the users themselves, and it doesn't even directly move a business metric. A much better goal would be something like "users should be able to sign up in half the time that they can now."

[00:05:44] In the old world, perhaps your product manager with this kind of goal would have committed upfront to a roadmap of features that they thought might deliver this. In this case, maybe it would be social sign-on, Touch ID, UX improvements to the signup form. But when you really focus on the outcome, the whole team can own that problem, and they can start coming up with ideas and hypotheses to test. And the team will know that they're done only when users can sign up in half the time, not when they've delivered some particular set of features.

[00:06:22] That's one big benefit of the outcome-focused approach: it drives autonomy back down into the team, and it enables a multifunctional team to each bring to bear their creativity and their own specialist expertise in solving a particular problem. Now, it's become very popular to conduct a discovery phase at the beginning of an initiative. But I think that if you're conducting discovery on a particular feature, then you've already narrowed the problem space too much, and you have to start conducting your discovery on the outcome that you're trying to achieve.

More ways to solve the problem

[00:06:50] An outcome-focused approach will also open up the range of ways that you can solve any given problem. Edward de Bono gives a great example of this in his book Lateral Thinking, when he tells the story of a number of senior executives of a big company who've just moved into a skyscraper, and to their dismay they discover that the builders didn't put in enough elevators. Their staff are incredibly unhappy, because they find themselves having to wait for the elevators, particularly at the beginning and the end of the working day, when there's a big rush.

[00:07:27] So the company starts trying to think of ways to solve this problem, and at first they're thinking, how do we speed up the elevators? They speak to the engineers and try to come up with some solutions. They even consider driving a new lift shaft through the building. But instead they do something different: they install mirrors around the entrance to the elevators. And it works. People are so preoccupied with looking at themselves, or surreptitiously looking at others, that they cease to notice the wait for the elevators, and in fact they don't mind at all. So it turns out that the outcome the company needed to solve for was the happiness of their employees, not the speed of the elevators. And once you're focusing on that, there are many more ways, and cheaper ways, to solve your problem.

[00:08:07] Another benefit of this approach is that it will probably lead to you loading up your product with fewer features that your users may or may not want. Many teams start spending more time improving existing features, because you want to get the maximum impact from them on a particular outcome, rather than just moving on to the next one. It might lead to the team delivering more things that you don't think of as features, like performance improvements.

[00:08:35] I was speaking to a woman who leads product at a big ecommerce company. As a company, they're obsessed with conversion rate. That's the metric that's most important to them as a business. But when they were conducting a retro over the last year, they found that the things they'd delivered which had had the biggest impact on conversion rate, their most important metric, were not actually any of the features which had been designed to do that, but two technical enhancements they had made: namely, their migration to the cloud, and image optimization, which sped up the loading time on the site. These are the things that had really moved that outcome.

[00:09:11] Teams can also start solving more problems in non-technical ways. Sometimes the answer really is just better copy, or it might be a strategic partnership, as in my example from earlier. And lastly, teams can start retiring features that get in users' way. I was speaking to another product manager who works on a major content site, who told me that he'd spent the last month retiring a secondary navigation structure. They had felt it solved a real need, but only for a very small number of customers, and in reality it was stopping the majority of customers from being able to find the content they needed as quickly as possible, and so it had to go.

Pitfalls: strategy and validating ideas

[00:09:48] But I know you may have heard this idea before. Perhaps you read about it in a blog post last year. And like most ideas, it sounds good until you try it. So I want to spend the rest of this talk concentrating on what can go wrong when you adopt an outcome-focused approach, and how you can avoid those pitfalls.

[00:10:03] The first problem arises if you don't have a clear company strategy. This is absolutely essential for having an outcome-driven approach. The way we think about these goals at WorldRemit is that we start with the company goals. We have six battles that we're trying to fight as a company in a given year. From that, each product team can derive their own mission, what it is that they're really heading towards, their North Star. And only then do they come up with their quarterly objectives, and the key results that will tell them what they're working towards in a given quarter and measure that they're moving in the right direction. I've seen too many teams come unstuck by trying to start at the bottom of this without doing the hard work to make sure that there's an agreed company strategy that everybody buys into.

[00:10:55] A second problem that can arise is when your team doesn't know how to validate ideas. This is particularly likely if you're moving from a scenario in which teams are generally just given a set of features that they try to deliver, because they haven't had that autonomy before, they haven't had that opportunity to validate ideas. The way I like to think about it is this. Each team, given the outcome that they're trying to achieve, looks at the quantitative data to see what the critical areas and the big opportunities are. If we were in e-commerce, this might be the funnel of customers moving through: what are the biggest areas of drop-off?

[00:11:31] You can then augment this quantitative data, which has told you what's happening, with some of the how from user interviews or other kinds of qualitative research. That should give you enough information to design your feature and validate it with some real users, hopefully, from which point you can build and launch the feature, measure the impact and iterate, which takes you right back round to finding the next biggest opportunity for you to target. Clearly this is just one model of many. I think this one's particularly good when you're trying to optimize an existing product with lots of users. If you're building something completely new, you might have less quantitative data to rely on in the first place, but then you can put more emphasis on the qualitative side of research.

Pitfalls: business buy-in

[00:12:18] A third problem arises if you haven't got business buy-in. Perhaps as a product team you want to move to this outcome-focused approach, but the rest of the business is still used to the old ways of doing things. Firstly, I can't emphasize enough how much value you'll get if you just explain yourself. I think sometimes we can be guilty in the UX, engineering and product world of being a little bit arrogant about our methods. Maybe we think, well, look, lots of other good companies build things this way, why should I have to explain myself to my company? But good things will happen if you take the time to explain your methodology from first principles.

[00:12:57] A good way of doing this is often coming up with an analogy from a world that's less technical, so it's not intimidating to people who sit outside of the technology part of your organization. My favorite analogy for this approach is crossing a river. Imagine I'm leading an expedition and I need to get my whole group over the river. I could tell them to build a bridge. Then they would probably start looking around for materials with which to build the bridge. It might end up being a time-consuming process, and the bridge that they come up with might not even be fit for purpose. Perhaps the whole group wouldn't be able to cross it. But if instead I give them the outcome, I tell them that we're trying to cross the river, they can solve that problem in lots of different ways. Perhaps they'll build a raft, or walk further downstream to a point where we can ford the river on foot. And they'll also know that we've only achieved what we set out to do once the whole group has crossed the river.

[00:13:43] A second thing I think is important is to get input on the causes of problems, not the solutions. We all know that frustrating feeling. Perhaps you go to your stakeholders and say something like, I'm working on my roadmap for next quarter, is there anything that you need me to put on it? And somebody's going to start coming up with ideas and say, yeah, actually, what we need on the homepage is a blue widget that has an animated video telling users how the service works. This almost definitely wasn't the kind of input that you were looking for.

[00:14:10] So reframe your question. Instead, you have to be asking: what we're doing this quarter is focusing on how we can improve conversion from the landing pages; do you have any ideas about what's causing drop-off? And then hopefully you'll get a response that's more like, yeah, we're worried that users are dropping off because they don't know how the service works. That will enable you to take that information and bring it back into the team to solve the problem.

[00:14:38] Similarly, if the first time you show something to your core stakeholders is when it's already a high-fidelity prototype, then you'll probably start getting feedback about specific design things that they want you to change. You won't be having the conversation that you want to be having. But if you come to them much earlier, and again explain the outcome, before you've even come up with any possible solution, then you'll be bringing them on the journey with you.

[00:15:13] You can always provide evidence from other companies that less is more. One of my favorite examples is from Microsoft. When they launched their experimentation platform, they found that fully one-third of the features they were releasing actually produced a negative effect on the product, and a further third had no impact at all. If that's what's happening at Microsoft, with all the resources they have available to them, you can feel quite sure that it's probably also happening in your company.

[00:15:38] Lastly, propose a test. If you can't get a stakeholder to budge on a particular solution that they're really focused on, then try to formulate that solution as a test relative to the outcome that you're trying to achieve. So again, you're bringing them back to having the right conversation. There is almost always a cheap way to test something and validate whether it's really a good idea.

Pitfalls: overlapping work and other work

[00:16:07] Even if you've got your business buy-in, you might find this problem: teams' work seems to overlap. If you are creating a feature-based roadmap, it's pretty easy to make sure that teams aren't working on the same areas. It's quite discrete. Perhaps you've even targeted, in the past, having people work on areas that are collectively exhaustive but mutually exclusive. That gets a bit harder when you're talking about outcomes. It might be that two teams want to deliver the same feature, because they both think it's going to affect their outcome. The way I like to think about this is that the first person to the problem gets to own it. The first team for whom that's the next piece of work to get them further towards their outcome should pick it up and run with it.

[00:16:43] Of course, it's even harder if teams are working on things that are actually in conflict. It might be that a feature that's designed to reduce fraud on your platform is also going to bring down the conversion rate. Those are the times when you need to have strong relationships within your product team, so that you can come together, negotiate and see the bigger picture for the product overall.

[00:17:06] And lastly, perhaps there still seems to be other work: bugs, tech debt or unforeseen work. A pretty common solution to this issue is to reserve some portion of each sprint to focus on these different things, maybe 20%. But my experience of the outcome-focused approach is actually that once you start thinking about what you're trying to achieve, these things don't feel like impositions that are thrust into a roadmap you otherwise had lined up. In fact, they're probably something that will help you get towards that outcome. If a bug is stopping your users from achieving what you want them to, then of course you want to fix that. If something unforeseen comes up that's really going to advance the outcome, then you'll be able to pick that up much more easily. And even tech debt.

You can only draw a roadmap for a place that has roads

[00:17:49] Which brings me back to that roadmap. Now that I've spoken to you about some of the benefits of adopting this outcome-driven approach, and how to avoid some of the common pitfalls, it's probably time to admit that you might still need a roadmap, especially for things that are going to be delivered in the short term. There are probably other teams who are dependent on you and need to know roughly when things will land. Perhaps your PR team is hoping to do a big launch for a feature that you're working on. And an indicative roadmap is just reassuring to people that you have an idea of where you're going. But you need to change the mindset which views it as a commitment, and which makes shipping features more important than delivering outcomes.

[00:18:39] So I think it helps to remind people that our metaphors are broken. I know it sounds obvious, but you can only draw a roadmap for a place that has roads. This is Google Maps. It's showing me how to get between Bromley and Victoria. It's telling me every road and every turn that I'll need to take. It's even giving me what is hopefully a pretty good estimate of how long it's going to take, an hour and four minutes in this case. But most of the work that technology companies are doing at the moment doesn't look like this. You're exploring unknown lands. You probably know where you are now, and you know where you want to get to, perhaps your outcome, but there's no established route to get from one place to the next.

[00:19:20] So you just have to set out. And if you've got the right metrics in place and you're measuring yourself, then hopefully you'll find out if you're going off in the wrong direction, and you'll be able to course-correct, and quite quickly you might be able to iterate towards that outcome. But you could only draw the roadmap of how you did it in hindsight. And that's why we need to change the conversation. We need to say no to features, and we need to focus on those outcomes. Thank you very much.