Westerly Consulting

Due DiligenceDue_Diligence.html
Management AdvisoryManagement_Advisory.html
Contact UsContact_Us.html

Feature Lists are not enough

Design Features to solve Problems

Fred Engel

Westerly Consulting


A key challenge in building software products is to provide the user with just the right solution.  Unfortunately, the road to product development is littered with the failure to match solutions and problems.  How many times have you heard someone say, “That product is a solution looking for a problem.”  Products are built to respond to a particular problem, not the other way around. 

A product provides features and functions that allow someone to do something in a better way than before the solution appeared. Therefore, one needs to look at the solution being developed and asked the question, “Is this a good solution to the problem?” Is the solution fit for the intended purpose

These questions can only be answered if there is a Problem Statement to compare with the solution.  A list of features is not sufficient because they do not define what they are supposed to do. They provide no guidance for how those features should be molded.   As an example consider a Product Manager working for an auto manufacturer.   He mentions that he wants to add a trailer hitch to the car he is specifying.  If you don’t know the vehicle involved, you cannot judge the feature.   A trailer hitch on a truck makes sense, but a trailer on a Corvette is not necessarily in harmony with the rest of the features in that product.  Features are in a context of a solution set and a problem being solved.

A list of features defines only one of potentially many solutions to the problem. By focusing on the problem being solved, the product builders can deliver a whole host of solution candidates.  The creativity of the entire team is enhanced if they have a good understanding of the problems and constraints of the desired solution.  Starting with a list of features creates artificial boundaries for what can be achieved.

Agile proponents have a strong tendency towards skipping both the Problem Statement and the Solution Statement steps. The folklore pushes the myth that just getting started, building something, putting it in front of customers, seeing if they like it, and iterating is all you need to do because the Minimal Marketable Product is defined iteratively and does not need any planning work in advance.   There is significant literature to debunk this mythology.

Iteration is an extremely valuable tool in getting to a solution.  To iterate you need to head in some direction, which is defined by the Problem Statement.   As Product Manager/Owner iterates, you discover what the problem is that the customer is receptive to, and you modify the problem definition to reflect that learning.  Features are added in a way that builds on the theme being addressed and having a Problem Statement informs that decision process, empowering the decision maker to know what to “leave in and what to leave out”.

Initial iterations do not have to be in the form of code. The iteration can be in the form of cheaper to build artifacts (e.g. mock-ups, power point, descriptions, and focus groups) that provide enough information that the more expensive iteration (e.g. software) will have a higher probability of success.  The goal of these iterations is to be able to have a Problem Statement that the customer will be able to do and a Solution Statement showing what the solution looks like.

An old boss mine used to say, “The primary audience for the specification you are writing is you.” Writing a clear and concise Problem Statement will force you to think about what you are doing in a broader and more complete way that is testable with your potential customer.  Far too often we have a “feel” for what needs to be done but we cannot really itemize or articulate. This feeling tends to be a false indicator and blinds us to what we are not looking at in our solution.  It is also hard to get a team to converge on the feeling of the leader.

Very few funders of projects will provide funds without understanding why this solution is a going to cause people to make use of it.  Even if you reached your conclusions about what the right capability should be by iterating features to the market place, when you go to ask for money or to decide how to enhance your product, knowing what problem you are solving is an essential need to both intelligently guide your product and cause people to provide funding. You have to understand why the customer is going to consume your solution.