Below is an internal team post I wrote to help us at Close.io do a better job of capturing customer’s feature requests in a way that leads to better product development outcomes.

I’m sharing this publicly because I believe this advice can help other startups and SaaS product companies as well.

When a customer request for a new feature come in, it’s easy to not log it at all (“we’ve heard that one before”) or to log it in a suboptimal way. Here are a few details on how to best capture customer needs and why it matters.

The typical, but unhelpful, way

The most common way feature requests are logged is in a “light” format like this:

• “[email protected] wants feature FOO – [link to ticket]”

While this does provide a list of people to notify if we ever do launch a feature that we happen to call “FOO”, it falls short in many other ways.

This is typically very unhelpful for Product Development or for getting a customer’s needs solved because:

• Many people have different ideas about what this feature specifically could be.
• There are different ways a feature could work and this doesn’t give any insight into which way would be best.
• Frequently there’s a different, better way that their underlying need (use case) could be met instead.

Logging requests in this “light” format may seem at least like a good way to build a notification list, but in reality leads us to building and notifying people about something that turns out not to best solve their core problems.

Similarly, it may seem that this at least gives us a “votes” system to prioritize Product decisions, but in reality there isn’t enough detailed signal in the votes to design a feature we can be confident really helps most of them.

Caveat: Logging a feature request with “email address only” is still better than not logging any at all, because it at least does give us a list of people we can later contact for more information.

The better way

A feature request logging format that is 100 times more helpful is one that includes details of the use case. A use case should include:

• Who is the user and company, and what’s the user’s role within the company?
• What situation is causing the user to want this feature? (When did the need start?)
• In their own words, what do they mean by “feature FOO”?
• How, specifically, would they use this feature?
• Really, why do they want this feature? What is the specific use case?
• What is the business value they’re hoping to achieve because of this feature?

It all really boils down to asking “why?” and then logging in as much detail as possible, in the customer’s own words, the specifics about what they are actually trying to accomplish.

“In the customer’s own words” is really important because it’s easy for us to, in the moment, substitute our own current idea of a solution, when what’s important is logging their actual problem and goals. Having the customer’s own words helps us avoid bias.

How this helps

Demand based Product Development

Having concise but detailed use cases help direct us toward clarity when we try to validate whether a Product Proposal makes sense to move forward with. They help answer:

“Is there really a pattern of consistent use cases that are important enough AND that our specific idea of solution would be a GREAT solution to?”

When logging feature requests, it’s best to assume that, by default, no feature will get developed until there is a set of documented specific use cases with reasons/explanations on why it’s important to that customer and how they would use it.

From a Product Development perspective, it’s important that we pay most attention to the underlying need (demand) rather than customer’s ideas and requests for specific features (supply). (For more about this, there’s a great podcast on the subject).

Design Decisions

Even in times where there’s clear demand in a problem area and many requests for a particular feature, another factor is at play where detailed feature requests with use cases help tremendously.

Often, there are multiple very different ways a feature could work, but without understanding exactly what users are trying to achieve, it’s hard to know which way is better.

Most features which seem clear and straightforward on the surface can go in different directions once you really dig into the nitty gritty UI/UX or technical design. Being able to go back to the core use cases (specific real-world things our customers are trying to do) it helps us quickly and confidently choose a direction.

Who should do this

The Product team takes ultimate responsibility for fleshing out customer use cases and validating solutions with customers.

Anyone who talks with customers, however (especially Support, Success, and Sales), is in a unique position to already have many interactions where feature requests and customer problems come up. It is immensely helpful and valuable for moving the product forward in the right ways if these interactions result in feature requests logged with use cases. We love having the entire company championing customer needs and giving input into Product direction. This is the best way to do that.

At Close.io, the best place to log feature requests with uses cases is in our “Feature Requests & Customer Needs” Trello Board. If you’re ever inclined to write a Product Proposal, including a few curated use cases (in the customer’s own words) is useful to supporting the idea.

---

What do you think? Send me a tweet about how your team captures customer feature requests.