Why did this topic come up?

Feature requests are a common part of product design. People ask for things, and you build them. Pretty simple, right? The thing is, by simply reacting to what comes up this way, it's easy to miss building something of real worth. I thought I'd show you a project I explored, back when I worked at Buffer.

Digging deeper

It's important to remember that when customers email in their requests, they're doing so from a narrow point of view. They want the current situation to be better for them so they can get on with what they're doing. They're focusing on their own solutions, rather than the core problem which may benefit many. They want a faster horse, as the old saying goes.

How I explored the Buffer calendar feature

I used to work for a company called Buffer, which helps people schedule social media posts. We had a calendar feature that gave customers a zoomed-out view of the posts they had scheduled. We were getting signals that the calendar view was important, due to the number of support tickets and feature requests we were receiving, so we decided to take a look at the feature.

Below is what the calendar view looked like, at the time.

An overview of the support tickets we were getting was:

• Reporting of bugs — especially around drag-and-drop and how many of the posts ended up in the wrong slots, resulting in much frustration.
• So much wasted space — the amount of white, empty space compared to cramp little posts that felt frustrating in itself.
• Inefficient to use — like only showing one network at a time or having to open up posts individually to see their full content.

The general tone of the requests coming in was for simply a bigger, better calendar experience. Nothing radical — just the same, but better.

The thing was, at the time, the calendar code was old and buggy. The tech was out of date and the interface felt alien to what we already had. Ideally, it needed a complete rewrite from the ground up. Were we ready for such an investment? Were we sure this was the right approach to take? It seemed apparent, based on the feature requests, but I felt it was worth taking the time to investigate further.

Deciding on the customer cohorts

It seemed clear that we needed to speak to our customers. The key thing here though was not just to speak to any customer. So we took some time to figure out the most useful cohorts:

• People who had contacted support about the calendar — why? Because they cared enough to take the time to put together a request and will likely be up for talking more about their needs
• People who had tried the calendar feature once or twice — why? Because they may have only used it a few times only because there was something wrong, so there could be a lot of learning from them
• People who used the feature consistently — why? Because these customers were likely to get the most value out of this feature and be the most useful when it comes to gauging a new solution

This spread of customers would give us a well-rounded view of the same feature but from slightly different angles.

Deciding on what kind of questions to ask

The most successful questions to ask are usually ones that give a clear prompt and then allow for an open-ended answer. It can be as simple as:

• Who — who are the customers and what do they use their Buffer account for when it comes to scheduling content
• What — what is the actual content they're scheduling, including the type like is it text, is it images, is it video
• How — how much content are they scheduling and how are they currently using the calendar to do their job
• Where — where in their user journey are they deciding a calendar is a right approach for scheduling
• Why — why is the current calendar important to them and why are they frustrated with the current solution

Basing questions around the who, what, how, where and why gave us an open-ended framework to get more specific needs.

Figuring out the needs of the customers

To get the needs we wanted to find we took note of the original support tickets and feature requests we had gotten, we then considered the different cohorts we had identified and then combined all of that with the targeted, yet open-ended questions we asked. The needs that rose up were as follows:

• How much content do I have going out? — they wanted to know if there were enough posts ready to go, so they could focus on other parts of their business
• Do I have a good spread of different types of content? — they didn't want too much of the same type going out one after the other to keep their content fresh
• Are all my posts good quality? — something as simple as checking their spelling or grammar or making sure their tone was right for what they wanted

This changes things quite a bit. These needs were not obvious from just the support tickets alone. There are many potential solutions here which are not just building a bigger, better calendar.

Exploring other possible solutions based on needs

I took in the needs, the cohorts, the interviews and the original support tickets and I settled my solutions around these three key areas:

• Customers want to see how many posts they have going out and when, so they can plan accordingly
• Customers want to see a spread of their posts and how they relate to each other, so they can make sure they don't have similar posts going out one after another
• Customers want to see posts clearly and in context, so they can check the tone and correct mistakes if need be

I should point out again that the old calendar we had in place really needed a complete rewrite. Was there a way to solve all of these needs, that didn't need such a big investment in time and money?

Possible solution — the mini calendar

The goal of this was to still provide a familiar calendar experience, but integrate it into the very popular queue feature so it was seamless to view and use. This could be shipped quickly, using newer tech, and yet still give the customer a way to see how many posts they had going and when.

Possible solution — post labelling

The goal of this was to provide a simple way to label posts so as to effectively group them by type or similar. This would give our customers a way to group their content visually and see their spread at a glance. Labelling is a simple concept which can be baked into all places posts are shown with the Buffer interface.

Possible solution — content planner

The goal of this was to give customers a way to see their posts over time but in a way where they could read their post titles and content more fully. It gave us a way to incorporate multiple networks, too.

Reflecting on these potential solutions

Though these were just potential solutions, I wanted to show you that if we had just collected the feature requests and taken them at face value, we would have missed out on other solutions that were easier and cheaper to build and yet potentially solved the needs of the customers better.

How to apply this in your work?

Getting support tickets and feature requests from your customers is fantastic because it means they care about your product! But opportunities can be missed if you simply follow them blindly. When it comes to the next feature you're building, take a step back. Collect and group those support tickets, identify cohorts that would be most valuable, and spend real time with those people to understand the who, what, how, where and why of it all. The needs should then naturally appear from this and it will give you more clarity on what you could design and build next.

What do you think?

Would love to know if this resonated with you. How do you approach support tickets and feature requests? Reach out to me on Twitter as I'd love to hear what you think. If you have liked what you read, please consider subscribing for more content.