Quit Putting Your Solution In My Feature Request!

A timeless process anti-pattern is when customers create a feature request and completely neglect to frame it in the phrase of a problem, rather they fill in what they perceive to be the solution. I simply call these – solution requests.

So what does the anatomy of a solution request really look like? Let’s first look what a good user story might look like:

As a paid customer, I can export my daily budget numbers to a spreadsheet.

Simple and small little user story. It doesn’t exactly explain why the problem exists, but some user stories are only meant to facilitate communication so the developer can understand the problem better.

Now here is a “solution” request:

As a paid customer, I can export my daily budget numbers to a spreadsheet. This will be accomplished by putting a button on the accounts page. This spreadsheet will be in CSV format with column A being the Total number, and D32 being the sum of all numbers.

This user story sucks, and rightfully so for a number of reasons:

Implementation Expectations

Who is it that makes feature requests? CEOs, paying customers, managers…in short, people from the top.

Solution requests are a Usability Engineers nightmare. Expectations to accomplish the feature (with the proposed solution) leaves very little maneuvering room if you are not willing to fight for it. Who knows usability habits better – a designer or the secretary?

Lack of Problem Understanding

Most user stories and feature requests are purposefully left vague as to engage the developer in conversation about the problem domain and possible solutions. When a feature request already has a solution, developers never have the chance to learn the problem domain that they are developing for.

It is necessary for quality solutions that the developer eventually becomes a domain expert in the problems that the software is trying to solve.

Solution, Party of 1

Assuming you have ignored my last two bullet points and have implemented the solution request. Probability is you have a solution that only solves one persons needs.

Without understanding the true problem, nor giving thought to how other people might benefit from the feature, you have created a feature that will probably be consumed by only one person (if that).

Allowing your clients and customers to create solution requests is just another weak link in the process chain that will allow for them to overrun and manipulate your design, process, and sometimes success of a project. Nip this anti-pattern in the butt by almost sounding Alex Trebek-ish,

Can you please phrase that in a problem?