The Feature Funnel: Qualifying the Wishlist

In my last post I introduced the Feature Funnel and discussed ways of managing a wishlist of product features. In this and later posts, I will introduce a series of questions that can be used to refine and filter the wishlist.

Is the requested feature popular? It is obvious that frequently requested features should grab the attention of product developers. Tools for managing user wishlists such as User Echo allow users to vote for wishlist items (for a good example of this in use see the Cinta Notes product roadmap).

The App Store and Android Market both allow users to review and rate products but don’t permit users to add wishlist items. As a result, it is quite common to see users requesting features in their review or even qualify their rating with something like “…would give it five stars if it had…”.

While it is true that there is strength in numbers, we should not forget the tyranny of the majority. It can be dangerous to simply ignore what appear to be unpopular features. Further investigation might reveal a small group of users with special needs such as the need for enhanced accessibility. Ignoring unpopular features also increases the risk of missing a highly creative approach that few have thought of.

When it comes to filtering unpopular features, it is sometimes more effective to ask users to vote items off the wishlist (in the style of reality TV shows). Casting a vote to remove an item from the wishlist encourages users to think about the consequences of removing a feature rather than focussing on their wishes and desires.

Is the requested feature ambiguous? Most features on a wishlist are described using natural language which is highly ambiguous (even before the jargon of software systems is introduced). It is quite common for users to request that products are “user-friendly”, “easy to use”, “easy to change” or “have a fast response time”.

Acceptance Criteria In the absence of any quantifiable measures, request such as these are pretty meaningless as they simply describe subjective desires. Even if they were taken seriously, it would also be impossible to confirm that the user’s wish had indeed been fulfilled. Insisting on clear acceptance criteria for each feature on the wish list is a very effective way of reducing ambiguity.

Another benefit of acceptance criteria is that they help to counter balance the rather abstract nature of features by providing concrete examples. Imagine a wish list item that requested the following function “calculate accommodation charge”. In the absence of acceptance criteria, this feature is very abstract. Asking the user to identify acceptance criteria goes a long way to clarifying their intent.

Acceptance criteria are very similar to test cases which means that we can apply some testing philosophies such as describing the required behaviour on boundaries and how to handle exceptions.

In the acceptance criteria above it is clear that a guest that checks in and out on the same day is still charged for one night and that leap years must be correctly handled.

IKIWISI Another source of ambiguity is the IKIWIS (I’ll Know It When I See It) problem. Although to be fair, it should only be considered a problem in certain situations. Often the IKIWISI approach can be very effective. For example, I may know that I need a new shirt but have no idea what sort of shirt to buy. I set out shopping confident that “I will know the right shirt when I see it”.

Shopping as a technique for clarifying what we need works well for clothes but is more difficult to apply to software. The App Store and Android Market usually offer free and paid versions of an app which allow users to try out several competing products before deciding on the exact features they need.

However, when software products are developed for a specific target group of users, it is not really practical to create a market place of alternative solutions and use a shopping-driven approach to clarify the user’s wishlist.  In this situation, the development of prototype solutions can be a cost-effective way to provide users with an IKIWISI experience.

Unfortunately, it is all too common for organisations that develop software products to ignore the IKIWISI problem. The classic development approach usually mandates that all the required product features are gathered from somewhat bemused users and documented in a lengthy specification. The users must then “sign off” the specification which is “frozen” before any work on developing the product can commence. Many weeks, months (or heaven forbid years) later the users are asked to review and accept the product.  It is hardly surprising that the most frequent comment heard from the users is “this doesn’t do what I want”.

In contrast to the classic approach, Agile methodologies such as Scrum, employ iteration as a means to provide the users with frequent opportunities to see a working product and decide if it is what they want or not.

UML Although not popular with agile teams, UML models can be a great way of clarifying ambiguous statements. The UML helps to remove ambiguity because of its underlying “visual grammar” (meta model). However, beware of ad-hoc “box and arrow diagrams” which can appear quite impressive but lacking a visual grammar, can often serve to muddy the water rather than clarify.

Visual Thinking There is growing interest in a loosely defined set of techniques known as visual thinking that are often proposed as an alternative to natural language. Visual thinking techniques include sketching on flip charts and whiteboards, working with sticky notes, mind mapping, story boarding and producing eye-catching infographics.

As well as enhancing creativity, visual thinking can also help to reduce ambiguity in certain circumstances echoing the old proverb “a picture is worth a thousand words”. However, visual thinking can suffer from the same lack of substance as “box and arrow diagrams”.  It has been pointed out that in the currency of words vs. pictures “a thousand and one words is worth more than a picture”!

Natural Language In spite of all the techniques that can be used to clarify wishlist items, it is likely product features will ultimately be described using natural language and that language is quite likely to be English. Like it or not English is the global language and so if your features are intended for a global audience, you may find “The Global English Style Guide” useful.

A good glossary is an essential tool for ensuring consistency across features and removing the ambiguity that inevitably results from the inconsistent use of language. Can you be certain what the author intends by “enter guest reservation”, “amend room held for guest” and “cancel accommodation booking”?

I will leave the final word on ambiguity to two computer scientists, Daniel Berry and Erik Kamsties and one lawyer-computer scientist Mickey Kriege who together wrote the Handbook of Ambiguities in Requirements Specifications and Legal Contracts.