Outcomes, not features

  • by
  • 2 min read

Take a look at your product backlog. What does it look like? Is it a prioritised list of features that your client or PO have asked for? Most are. If you’re lucky it might be a list of features that are based on needs which you’ve gleaned from real users.

But is this how you should be approaching your work? Why are you focusing on delivering features? What are you really trying to achieve?

The outcome most teams are aiming for is a change in behaviour. The outcome you want will depend on your business or organisation: it might be selling more dog food, getting people to sign up to a monthly donation to your charity, or opting for mediation over court in their separation. Whatever it is, chances are that success shouldn’t be measured by whether a certain feature is released or not; it should be measured on the change in behaviour.


Let’s admit it, we don’t know whether a certain feature will result in the outcome that we are trying to achieve. Therefore, we should focus on the outcome as our goal.

Now I know that this is easy for me to say, but difficult to apply. It needs the whole business / organisation to think differently. It encourages organisations to favour a scientific method. But if you can achieve this change in thinking, your teams will be testing more ideas (see MVP), getting assumptions on the table early and should result in teams pivoting to create solutions that achieve the desired outcome, rather than being wedded to particular features that won’t.

Outcomes, not features.

(I feel the urge to print some bumper stickers and t-shirts)


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.