Goals Versus Features and the Minimum Desirable Product

I was debating with a technical colleague yesterday about the best way to divide up the design and development effort for a website. It’s a guy I trust, like and respect and up until this point we’ve been fairly well aligned in our thinking and approach. Something was niggling me about the debate. I was sure that we were talking about same thing. but it was in the language that described our separate points of view where we seemed to differ. I jumped across the table (literally) to get to the white board to draw a picture and there was a moment of epiphany when we realised that we were talking about the same thing but using different words to describe it. It emphasised a few things for me:
Visual thinking is essential method of communicating. It’s only of the only ways to get a shared understanding across teams of difficult concepts. You need a thousand words to describe a picture, but a quick stick figure or shapes and we solved the problem in a tenth of the time that we had spent wrangling with words.

The need for common language when working on a team. Visual communication can facilitate shared understanding and once you have this it’s the next essential step is to establish a common language so that we know when we have the discussion in the future that we are talking about the same thing. This doesn’t need to be anything more robust that having a sheet of flip-chart paper which lists frequently confused terms or domain-specific language and calling out the definition. It will save a lot of people from feeling dumb or ignorant, especially those who don’t like to assume but don’t want to ask.
So in this instance the terms that were causing the confusion was Epics, Goals and Features. Each of these can be described as the high level units of business or user value that can comprise of lots of lower level detail (aka user stories/requirements). What we were violently agreeing about was that design is difficult at the micro level without first considering the macro level and the context of use.  However he was talking about features and I was talking about goals (and goal-driven design and development). They did boil down to the same abstract concept but the difference lies in the perceived value that each delivers and therefore the ability to prioritise what gets delivered in what order. The business could probably prioritise ‘features’ based on the level of return on their investment multiplied by time and effort to develop. However we need to ask what value do users attach to features because there’s little point in building features that are not going to be used by the end customer no matter how much the business thinks it might be used. There’s a statistic which came from a report produced by the Standish group which says ‘45% of features built are never used’ – which is an awful lot of time and effort wasted. So we want to make sure that we are building the right thing for the right people.
The way we solve this is not by thinking about features per se, but by thinking about goals. A mobile phone has features: it has a camera feature, a text feature, a web connectivity feature etc.

Customers/users however have goals that they want to achieve using the device or application. Customers want to take a picture to capture the moment and share it with family and friends. If we focus purely on the feature we can get hung up on making that feature great and foget the context of use, we can also limit our design thinking. Do we really need infinite mega pixels, a Carl Zeiss lens and photo-retouching that compares with industry heavyweight applications like Adobe Photoshop when actually we’re on a phone contract with a limited data package and we’re sending the image to Great Aunty Beris who has the most basic handset with a small and poor resolution display? Probably not.
By focussing on the goals that the user wants to achieve we can feel much more confident that we are building the right thing. It also means that we are in a much better position to consider the ‘minimum viable product’ and get it out quickly to market. To do this we take the user goal and ask ‘what is the minimum that we could deliver in the shortest period that would allow the user to achieve their goal?’ Granted not everyone is a fan of the minimum viable product but once we have this as a baseline we can then ask, is this enough to engage and delight our customers? If it is, great! We can get down to the business of development and get it out there quickly. If however the minimum viable product is not quite enough then we simply ask ‘what is the minimum that we could deliver in the shortest period that would allow the user to achieve their goal and engage and delight them?’ and we build delight into our minimum viable product.