Saying goodbye to the feature request

No matter how beautiful the UX, how elegant the code or how innovative the underlying idea, you can still produce a product that no one wants.

Feature requests are supposed to help you deliver something that the market willwant. Whether you’re passively collecting ideas or actively soliciting them, a feature request is born when a customer (internal or external) responds to an invitation to give feedback on what they want to see in the product. The frequency, feasibility and investment needed for those ideas to become part of the product are considered when engineering work is planned and roadmaps are drawn up.

I went into product management at a start up after spending a couple of years building up the client services team. Before I made the move, I loved that we could make feature requests on behalf of our clients, or for things my team needed to work more efficiently, but was disappointed when those requests weren’t implemented or fully adopted. When I moved to product management, I was confronted with a lot of pieces of different story, but no coherent narrative or way forward.

Although they are an almost ubiquitous tool for software companies, feature requests collect exactly the wrong information to start solving a problem: a solution.

Think of it like walking into your doctor’s office with a pain in your leg and asking for a prescription for vicodin. Without knowing if your pain is from a sprained knee or a shattered bone, the doctor can’t determine if that’s the right treatment to give, or if it will make something else worse.

Because a solution is the starting point of a feature request, it encourages the requestor and everyone involved to own their solutions and invites conflict when that solution is modified, critiqued or rejected. Imagine you went to the doctor’s office with your friend, also a doctor, and he’s absolutely convinced physical therapy relieve your pain. While he is arguing with your doctor when she starts advocating a different treatment, all you can think of is how your solution would fix the pain now. And no one is really talking about the actual problem: the pain in your leg.

Coming up with a better way to understand stakeholders’ pain will help you build better products. Here’s how product managers, engineers, UX designers and execs can turn the feature request around to make better decisions.

Collect problem statements, not feature requests

When I moved to product management, I inherited a spreadsheet of feature requests. They had been assigned levels of priority by the requestor (almost always high) and the engineering team (almost always low), and there were a lot of them. Many repeated similar themes, but it was unclear if they were really related, or why exactly they were being asked for. Even my own requests from months before were a bit incomplete; when I pieced together a use case from memory, sometimes I agreed that the feature request was the right one, and other times, in hindsight, there were better solutions I hadn’t thought out. Things that “would be cool” were often cool features, but sometimes didn’t really address the problem they were designed to solve.

If you inherit a giant spreadsheet of feature requests, require that anyone who wants to make a feature request can walk you through the problem that prompted it step by step, or commit to finding someone who will. If you’re lucky enough to build a mechanism to gather this preliminary data from scratch, or you’re overhauling an existing one, ask people to tell you about problems that they have encountered using your product, not a proposed solution.

It might feel like you’re creating a complaints department rather than a funnel for a lot of awesome ideas, but problems are raw material for much better ideas and much better relationships with stakeholders.

“This isn’t what I ordered”

Ensuring a deep understanding the problem also serves a very important role in calibrating expectations that the problem will be solved, not that an idea will be accepted or rejected.

Why is this important? People really like their own ideas, and that’s normal and natural. Solution ownership is a big problem that becomes apparent when discussing feasibility and merit of ideas with names attached to them; owners are often personally invested and decision makers’ bias might lead to poor decision making about what problems to address.

To paraphrase a popular quote, you want everyone to be engaged with fixing the problem, not defending their solution.

You might be thinking that isn’t true in your organization and sticking with feature requests is fine, but there’s another big pitfall: even if an idea is adopted, buy-in from its initial champion is not guaranteed. If someone thinks that their solution is getting traction, and what you deliver doesn’t look exactly what they asked for, at best they’ll be disappointed, at worst, they will reject it. Worse still, if it turns out the solution they suggested doesn’t actually address the problem, implementation of the solution, and all of the resources it took to accomplish it, count for very little.

Manage expectations with requestors that the solutions implemented may not look like their original idea, and, if they’re willing, talk on a regular basis. This is where client facing experience is incredibly useful for the people building a product. The most engaged stakeholders I’ve worked with were people with whom I shared specs, mockups and ideas on a regular basis for feedback. The features we created to address their issues were used frequently and the relationship with those stakeholders became more of a partnership where we had both made an investment, not just a transaction.

Making the diagnosis

It’s not easy to sit down and really dig into issues in a fast-paced environment, but a few well placed questions will get you the information you need. Here are a few suggestions to get at a good diagnosis of what you’re solving for while engaging your stakeholder.

  • What prompted the ask — This is really the problem statement, the situation that put the wheels in motion. Make sure to get a step by step account about what was done, why, and where the problems came up. Don’t assume you know or you can guess based on other information.
  • Who is asking — Different constituencies will have different perceptions of what’s important and use the product in different ways: salespeople may need something that is straightforward and looks cool for a quick demo, but a mid-level employee of a major client may be more focused on functionality of a very specific part of the product.
  • Impact of the problem — This is very important to assess the urgency of the situation, who the stakeholders are, and if there might be related components of the product you should look at as you work towards a solution.
  • Workarounds — If the user came up with a way to get around the problem, what was it, where is it falling short, and does it solve the whole problem? Knowing this helps pinpoint the most useful fixes, especially if time or resources are a factor.

Building a product that people want that can move with the market is possible if you can support it with a process that responds to feedback effectively by focusing on solving problems, not defending solutions.