Feature Risk

Feature Risks are types of risks to do with functionality that you need to have in the software you're building.

Feature Risk is very fundamental: if your project has no Feature Risk it would be perfect! And we all know that can't happen.

As a rule of thumb, Feature Risk exists in the gaps between what users want, and what they are given.

Not considering Feature Risk means that you might be building the wrong functionality, for the wrong audience or at the wrong time. Eventually, this will come down to lost money, business, acclaim, or whatever you are doing your project for. So let's unpack this concept into some of its variations.

As shown in the diagram above, Feature Risks are a family of risks you face any time you start trying to build functionality to serve a client. In this article, we will:

• Break down and talk about the different Feature Risks shown in the diagram above.
• Discuss how they occur and what action you can take to address them.
• Analyse the family of feature risks along three axes of fit, audience and change.

Feature Fit Risk

This is the risk that the feature that clients want to use in the software isn't there.

• This might manifest itself as complete absence of something you need, e.g "Why is there no word count in this editor?"
• It could be that the implementation isn't complete enough, e.g "why can't I add really long numbers in this calculator?"

Feature Fit Risks are mitigated by talking to clients, product development and delivery (as shown in the above diagram). But that leads on to...

Implementation Risk

The Feature Risk family also includes things that don't work as expected, that is to say, bugs. Although the distinction between "a missing feature" and "a broken feature" might be worth making in the development team, we can consider these both the same kind of risk: the software doesn't do what the user expects. We call these Implementation Risks.

As shown in the above diagram, we can mitigate this risk with feedback from users, as well as further development and testing.

It's worth pointing out that sometimes, the user expects the wrong thing. This is a different but related risk, which could be down to training, documentation or simply a poor user interface (and we'll look at that more in Communication Risk.)

Regression Risk

Delivering new features can delight your customers, but breaking existing ones will annoy them!

Regression Risk is the risk of breaking existing features in your software when you add new ones. As with other feature risks, the eventual result is the same: customers don't have the features they expect.

Regression Risks increase as your code-base gains Complexity. That's because it becomes impossible to keep a complete Internal Model of the whole thing in your head, and also your software gains "corner cases" or "edge conditions" which don't get tested very often.

As shown in the above diagram, you can address Regression Risk with specification (defining clearly what the expected behaviour is) and testing (both manual and automated), but this takes time and will add extra complexity to your project (either in the form of code for automated tests, written specifications or a more elaborate process for releases).

Regression Risk is something we'll come back to in Operational Risk.

Conceptual Integrity Risk

Conceptual Integrity Risk is the risk that chasing after features leaves the product making no sense, and therefore pleasing no-one.

Sometimes users swear blind that they need some feature or other, but it runs at odds with the design of the system, and plain doesn't make sense. Sometimes the development team can spot this kind of conceptual failure as soon as the suggestion is made, but usually it's in coding that this becomes apparent.

Sometimes it can go for a lot longer. Here's an example: I once worked on some software that was built as a score-board within a chat application. However, after we'd added much-asked-for commenting and reply features to our score-board, we realised we'd implemented a chat application within a chat application, and had wasted our time enormously.

Feature Phones are another example: although it seemed like the market wanted more and more features added to their phones, Apple's iPhone was able to steal huge market share by presenting a much more enjoyable, more coherent user experience, despite being more expensive and having fewer features. Feature Phones had been drowning in increasing Conceptual Integrity Risk without realising it.

Conceptual Integrity Risk is a particularly pernicious kind of Feature Risk which can only be mitigated by good design and feedback. Human needs are fractal in nature: the more you examine them, the more complexity you can find. The aim of a product is to capture some needs at a general level: you can't hope to anticipate everything. As with the other risks, there is an inherent Schedule Risk as addressing these risks takes time.

Feature Access Risk

Feature Access Risks are risks due to some clients not having access to some or all of the features in your product.

Sometimes features can work for some people and not others: this could be down to Accessibility issues, language barriers, localisation or security.

You could argue that the choice of platform is also going to limit access: writing code for XBox-only leaves PlayStation owners out in the cold. This is largely Feature Access Risk, though Dependency Risk is related here.

In marketing terms, minimising Feature Access Risk is all about Segmentation: trying to work out who your product is for and tailoring it to that particular market. As shown in the diagram above, mitigating Feature Access Risk means increasing complexity: you have to deliver the software on more platforms, localised in more languages, with different configurations of features. It also means increased development effort.

Market Risk

Market Risk is a term from finance:

"Market risk is the risk of losses in positions arising from movements in market prices." - Market Risk, Wikipedia

I face market risk when I own (i.e. have a position in) some Apple stock. Apple's stock price will decline if a competitor brings out an amazing product, or if fashions change and people don't want their products any more.

This risk applies equally well when building a software product, as the software you're building is effectively your stock and its value is whatever the market places on it (i.e. what people are willing to pay).

Even projects that are internal to a company are not immune: they still need to have a value to the company and therefore suffer Market Risk.

Since the market decides what it is prepared to pay, Market Risk tends to be outside your control. Although, as shown in the diagram, you can use tools like marketing to try and engage with your market and get them to see the value in what you are doing.

Feature Drift Risk

Feature Drift is the tendency that the features people need change over time.

For example, at one point in time, supporting IE6 was right up there for website developers, but it's not really relevant anymore. The continual improvements we see in processor speeds and storage capacity of our computers is another example: the Wii was hugely popular in the early 2000's, but expectations have moved on now.

The point is: what users want today might not make it to tomorrow. This is especially true in the fast-paced world of IT. Over time, the market evolves and becomes more discerning. This happens in several ways:

• Features present in competitors' versions of the software become the baseline, and they're expected to be available in your version.
• Certain ways of interacting become the norm (e.g. querty keyboards, or the control layout in cars: these don't change with time).
• Features decline in usefulness: Printing is less important now than it was, for example.

As shown in the diagram, saving your project from Feature Drift Risk means further design and development. But trying to keep up with users' changing demands can re-introduce Conceptual Integrity Risk back into your project.

Sometimes, the only way to go is to start again with a clean sheet by some distruptive innovation.

Feature Drift Risk is not the same thing as Requirements Drift, which is the tendency projects have to expand in scope as they go along. There are lots of reasons they do that, a key one being the Hidden Risks uncovered on the project as it progresses.

Fashion

Fashion plays a big part in IT. By being fashionable, web-sites are communicating: this is a new thing, this is relevant, this is not terrible. All of which is mitigating a Communication Risk. Users are all-too-aware that the Internet is awash with terrible, abandon-ware sites that are going to waste their time.

How can you communicate that you're not one of them to your users?

Delight

If this breakdown of Feature Risk seems reductive, then try not to think of it that way: the aim of course should be to delight users, and turn them into fans.

Consider Feature Risk from both the down-side and the up-side:

• What are we missing?
• How can we be even better?

Analysis

So far in this section, we've simply seen a bunch of different types of Feature Risk. But we're going to be relying heavily on Feature Risk as we go on in order to build our understanding of other risks, so it's probably worth spending a bit of time up front to classify what we've found.

The Feature Risks identified here basically exist in a space with at least 3 dimensions:

• Fit: how well the features fit for a particular client.
• Audience: the range of clients (the market) that may be able to use this feature.
• Change: the way the fit and the audience changes and evolves as time goes by.

Let's examine each in turn.

Fit

"This preservation, during the battle for life, of varieties which possess any advantage in structure, constitution, or instinct, I have called Natural Selection; and Mr. Herbert Spencer has well expressed the same idea by the Survival of the Fittest" - Charles Darwin (Survival of the Fittest), Wikipedia.

Darwin's conception of fitness was not one of athletic prowess, but how well an organism worked within the landscape, with the goal of reproducing itself.

Feature Fit Risk, Conceptual Integrity Risk and Implementation Risk all hint at different aspects of this "fitness". We can conceive of them as the gaps between the following entities:

• Perceived Need, what the developers think the users want.
• Expectation, what the user expects.
• Reality, what they actually get.

For further reading, you can check out The Service Quality Model which the diagram above is derived from. This model analyses the types of quality gaps in services and how consumer expectations and perceptions of a service arise.

In the Staging And Classifying section we'll come back and build on this model further.

Fit and Audience

Two risks, Feature Access Risk and Market Risk, consider fit for a whole audience of users. They are different: just as it's possible to have a small audience, but a large revenue, it's possible to have a product which has low Feature Access Risk (i.e lots of users can access it without difficulty) but high Market Risk (i.e. the market is highly volatile or capricious in it's demands). Online services often suffer from this Market Risk roller-coaster, being one moment highly valued and the next irrelevant.

• Market Risk is therefore risk to income from the market changing.
• Feature Access Risk is risk to audience changing.

Fit, Audience and Change

Two risks further consider how the fit and audience change: Regression Risk and Feature Drift Risk. We call this Change in the sense that:

• Our product's features evolve with time and the changes made by the development team.
• Our audience changes and evolves as it is exposed to our product and competing products.
• The world as a whole is an evolving system within which our product exists.

Applying Feature Risk

Next time you are grooming the backlog, why not apply this:

• Can you judge which tasks mitigate the most Feature Risk?
• Are you delivering features that are valuable across a large audience? Or of less value across a wider audience?
• How does writing a specification mitigate Fit Risk? For what other reasons are you writing specifications?
• Does the audience know that the features exist? How do you communicate feature availability to them?

In the next section, we are going to unpack this last point further. Somewhere between "what the customer wants" and "what you give them" is a dialogue. In using a software product, users are engaging in a dialogue with its features. If the features don't exist, hopefully they will engage in a dialogue with the development team to get them added.

These dialogues are prone to risk and this is the subject of the next section, Communication Risk.