Alice Newton-Rex, Chief Product Officer of WorldRemit, explains how she reached to the conclusion that learning how to say no to features is the secret to successfully growing a product.

Alice jokes that a few years back she was obsessed with creating different types of roadmaps - she was constantly trying to improve and make her roadmaps work better for everyone. She discovered that most of her industry colleagues were the same - all product managers are on a quest for the perfect roadmap.

What’s wrong with looking for the perfect roadmap?

In reality, all product roadmaps are a list of features on a timeline. And the problem with the list of features is that the rest of the company and your stakeholders see them as a commitment. This created 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 the problem that’s no longer your most important one.

Your users don’t want features completed, they want their needs met. Click to tweet.

Why is the perfect roadmap a problem for product managers?

Traditional product roadmaps approach makes you incentivising the wrong behaviour and it traps you in having the wrong conversations. Ad a product manager, you’re often given a list of features and you're left with the task to make them work the best you can.

The other risk is “everything is going well”. Imagine at the end of the year you’re presenting in front of the company executives and you’re reporting that all requested features have been delivered within the estimated time. That’s great - but why are all metrics the company cares about going down?

The negative moral and wasted resources that come from working on the wrong features is a massive problem in the industry.

How do we make change happen?

We need to stop talking about features and start talking about problems and outcomes. If your team is successful, how would your users feel next year and what would they be able to do?

Teams need to commit to an outcome, not to a roadmap of features. Click to tweet.

The outcome should be measurable, and the user and the business should recognise it as valuable. For example, a bad goal would be “the user sees more marketing messaging”, while a good metric of the same project could be “the user should be able able to sign up in half of the time they do now”.

When you’re really focused on the outcome the whole team can own that problem. They can start coming up with ideas and hypothesis to test. The team will know they’re done only when they’ve delivered the outcome, not when they’ve built the set of features.

What are the benefits of the outcome-driven approach?

You focus on the right metric and you usually find cheaper ways to solve the problem. Some of the results you’ll see when you start focusing on outcomes, rather than project delivery are:

• Fewer features
• Improved existing features
• Deliver things you don’t think of as features (e.g. performance improvements)
• Solve problems in a non-technical way (e.g. better copy, strategic partnerships)
• Retire features that get in users’ way

What can go wrong when you adopt an outcome-focused approach?

• Problem 1
  If you don’t have a clear company strategy, then the outcome-focused approach will most probably not work. The whole company should be aligned with the new vision.
• Problem 2
  Another potential pitfall is when your team doesn’t know how to validate ideas. To overcome this, teams should be given the authority to decide and access to qualitative and quantitative data to discover the next opportunity to tackle.
• Problem 3
  Another problem is when you haven’t got the business buy-in. In this case, you just need to explain yourself. Don’t be arrogant, take the time to explain your methodology to the rest of the company. Don’t be intimidating to people who’re not as technical as you.
  
  Get input on the causes of problems, not just the solutions.  For example, don’t ask stakeholders what they want to see improved, but phrase your question like “this is the problem we’re trying to solve, do you know what might be causing it from your area of expertise?”
• Problem 4
  Teams’ work can overlap. This could get exhausting and frustrating. The way you could solve this easily: the first people/team to the problem gets to own it.
• Problem 5
  There’s always more work, like bugs, tech debt, unforeseen work. Once you start thinking within the outcome-focused approach, these things will easily fall into the right places. Some of them might even help you to advance the outcome you’re focusing on.

Going back to the roadmap, the conclusion is that we actually need a roadmap. We just need to change our approach. Imagine a Google maps road journey - you have a starting point and an end destination. Your outcomes are your destination. The things on the way don’t need to be just featured, it could be anything that will help you achieve your outcome.

We need to change the conversation and say no to features, so we can say yes to outcomes. Click to tweet.