Skip to main content

Feature Fit Risk

Risk that the needs of the client don't coincide with services provided by the supplier.

Part Of

Reduced By Practices

  • Analysis: Analysis can help ensure technical solutions fit the problems they're designed for.
  • Coding: Build or improve some features which our clients will find useful.
  • Demo: Showcases the product to ensure it meets client expectations and needs.
  • Fundraising: Enables the startup to fund product development and innovation.
  • Measurement: Helps in understanding the use of the system.
  • Performance Testing: Identifies performance bottlenecks that could affect usefulness.
  • Prototyping: Allows early validation of features and design with stakeholders.
  • Release: Putting new features in the hands of users can make your product fit their needs better.
  • Requirements Capture: Ensures that features align with client needs and expectations.
  • Standardisation: Ensures that the features conform to predefined standards, reducing variability and potentially widening accessibility.
  • User Acceptance Testing: Ensures that the software meets the client's requirements and expectations.

Attendant To Practices

  • Automation: The automated process might not capture the variability of requirements of the original approach
  • Dependency Adoption: Creates dependencies on the adopted standards and libraries.
  • Design: Too much design up-front can create problems meeting feature requirements.

This is the risk that the feature that clients want to use in the software isn't there or isn't quite what you need.

  • 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?"
  • It might be that the software isn't designed with your client's use case in mind, e.g. "I really needed this to handle UK taxes but it only works for the US."

Worked Example​

Using analysis to ensure feature fit

In the above diagram, we can see Feature Fit Risk being addressed by Analysis. One should be careful about the attendant risks of analysis - it can go on for too long, or get bogged down in debate (so called Analysis Paralysis) which can lead to Schedule Risk or Funding Risk.

Example Threats​

1. Misunderstanding of Client Needs​

Threat: Lack of clarity around client requirements could lead to delivering features that don't quite solve the client's problem.

2. Ignoring Edge Cases​

Threat: Assuming all users will use the software in the same way may result in ignoring the outlier cases.

3. Lack of Iterative Feedback​

Threat:: Not gathering feedback during development phases could result in delivering features that are not fully aligned with client needs.

4. Evolving Requirements​

Threat: Not reassessing the design when new requirements emerge can lead to delivering features that no longer align with the client’s current needs.

5. Accessibility Concerns​

Threat: It's easy to ignore edge cases around types of user, failing to consider the full breadth of platforms the software will need to run on, ease-of-use, visual accessibility, auditory accessibility and cognitive accessibility.

6. Over-Complication​

Threat: In an effort to provide as much as many features as possible, software can become over-complicated and hard to use. Trying to mitigate Feature Fit Risk can lead to Complexity Risk.

Anecdote Corner

The excessive menu-diving in Feature Phones of the late 1990s are an example of trying to account for too much Feature Risk: 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, coherent user experience, despite being more expensive and initially having far fewer features.

Feature Phones had been drowning in increasing numbers of box-ticking features while ignoring the feature that users really wanted: a clear, responsive user interface and ease-of-use.