How to handle Internal Feature Requests.
Don’t… Well, rather have the requesters frame them as “Problems to be Solved”:
One of the flip sides of working with a passionate experienced team is an abundance of ideas for the direction of a product. Sometimes this manifests as the HIPPO (HIghest Paid Person’s Opinion) and sometimes as a long list of internal feature requests. Feature requests are often just that, a suggested feature, which sometimes has some reasoning behind it, but often comes as a naked “add button X that does Y” chucked in a trello card, in a board that quickly becomes bloated with other similar requests.
Such lists of requests pose three main issues:
1 — What is the underlying problem of each request? It’s unclear if there is actually a problem that the feature is solving, or if the requested feature would actually solve it.
2 — Prioritization. When you have a list of solutions, prioritization is difficult and unobjective.
3 — Stakeholder Frustration. From an individual requestees perspective, there isn’t any clarity of what is going on, why one feature request is going to the dev team, while their own request is just sitting there.
This is a problem that we were facing, and about a year ago, we made a change which has made all the difference. We reframed our feature request template as a ‘Problem to be Solved’ template. It has 4 parts:
1 — What’s the problem
2 — What’s the impact
3 — Suggested Feature
4 — Relevant Client Details
WHAT’S THE PROBLEM
Reframing the question as a problem rather than a solution is Product 101, but it’s good to do this in the template as it puts the initial onus back on the requester, saves a lot of follow up effort, and allows us to eyeball if the suggested solution would actually solve the problem. Sometimes a less product minded requester will put in this section: “I can't do [insert solution]”, to which, a comment in the card can prompt some more relevant info about the problem.
BUSINESS VALUE
Product 102 is outcomes over outputs/features. In the end, we want to solve the problem and know that it's solved by measuring an affected metric: the outcome. Having this in the request helps the requester to think about the impact, and points us in directions we may not have looked at when it comes to diving deeper into the problem.
DESCRIPTION OF SUGGESTED FEATURE
We’re a growing startup, a lot of people making requests have a lot of experience and valuable intuition, this space allows them to put in how they think the solution would best be solved. I encourage colleagues to report problems even if they can’t think of a solution, however, people are hesitant to do this. I think because they see it as just complaining without offering an answer…
CLIENT INFOS
Some product evangelists/dogmatists might like to think that their product strategy is independent of key clients desires, or the wishes of the sales teams. I’ve never seen this actually happen, and we try to be realistic and would prefer to know sooner rather than later. (We are also a low client number, B2B company, putting more emphasis on key clients is part of the business model)
Once we have the request there is usually a fair bit of triage required, the problem explored a bit more, and the impact dug into. But in the end, we have a list of clear prioritised problems to be solved, and the impact of these problems. This solves the second two problems identified with the ‘feature request’ model: Prioritisation is clear, and stakeholders are happy, because they can see why their request is being addressed, and if not, can objectively compare the impact of their request to the ones we are working on.
To solve the first problem with the ‘feature request’ model (Does the feature actually solve the problem?), I forget the suggested solution for the time being and take this list of prioritised problems to our developer team or design team depending on the problem area. I show them the problem and impact and give a little brief, which is intentionally high level and objective. It usually sounds like this: “I have a problem, blah, blah, learnings, metrics, what do you think?”. The dev/designer usually looks at me while I can see the wheels ticking behind their eyes and then proposes a few solutions. Only at this stage do I show them the suggested solution and we discuss it. Even though often the suggested solution is obvious, I try to let the developers or designers have a think about it with a fresh mind; you can't unsee a solution.
In the end, we have a rough rough idea of a solution, or a set of possible solutions that would actually solve the problem identified in the initial request.
All of the above doesn’t mean that we just go and build the solutions that come out of this small meeting. This initial triage is just to get an idea of the effort required, we have a whole other process for solution prioritisation, which takes all of the above info plus far, far more. But that’s for another blog post.
Reframing our ‘Feature Request’ template into a ‘Problem to be Solved’ template has cleaned up our initial triage process immensely, very quickly we’re able to get to a prioritised list of issues affecting the whole business, which is clear to all stakeholders, and provides the best stepping off point for building great products to ultimately solve these problems
