Managing many user requests at once with Mail Pilot is an entire system in itself. This essay breaks down the organization and process I use to hande and make use of a high volume of requests.

Email is a very personal thing. Everyone has their own unique list of “must-have” features for an email client. Managing many user requests at once is a skill that I have become proficient at, but only after years of gracelessly fumbling through poor processes.

Here are the organization, process, and other details that have served me well for the last several years as I’ve handled support alone.

Organization

Let’s start with the organization that I use, so that I can share my process using this framework as the foundation.

In Things 3, I have an ongoing project in which I have multiple lists (separated with headings):

Inbox. This is where I put new requests as they arrive, which I organize later.

Tier 1: Showstoppers. This is where I categorize anything that will be a major disruption to many users. Crashes, confusing bugs, etc.

Tier 2: Solutions for current existential crisis. I reserve Tier 2 for the existential crisis which I presently fear will cause everyone to stop using my app. Earlier in development, it was “Tier 2: A thousand cuts” when the app had many remaining little things which were far from showstoppers, but experienced all together orchestrated a symphony of frustration for the user. Once those “thousand cuts” were largely resolved, I moved into “Tier 2: Feels incomplete without” as the app is still young, and lacks some features that would make it feel complete. Tier 2 will always be the thing that I fear is the current biggest cause for app abandonment.

Tier 3: Really good to have. These are the things which I believe to be important to the direction of the product and needed soon. Like the above two tiers, these items may or may not have originated directly from user requests. Instead, Tier 3 is often home to important things which people would not know to request.

Tier 4: Requested by multiple people. These are the requests I have received from more than one person.

Tier 5: Requested once. These are requests I have only received once. This tends to be a long list, but once something is requested by a second person, it moves up to tier 4. This helps me keep track of what is being requested more regularly, and move those things up.

Deferred requests. These are the requests which I know I will not or cannot build at the present time for technical, resource, or other reasons.

Wild Ideas. These are the things which might not be actionable right now, but represent really interesting ideas that could be big features or changes for future releases.

Process

When I receive a new request, here is the process I go through. I do this for every kind of request — whether it’s a bug report, feature request, confusion, or even a question (for example, when someone asks for a feature which already exists, it may mean that I need to ensure the feature is better communicated or presented).

1. Search for an existing copy of that request.
2. If it does not already exist, create it in Tier 5, with the requester’s name attached to it (more on that below).
3. If it does already exist, add the requester’s name to it. If it is in Tier 5, bump it to Tier 4.
4. If there is a compelling enough reason for it to go in Tier 3 or higher, move it up and expand on it (sometimes it requires a little research, sometimes it requires some thinking or designing and getting feedback from requesters, and it always requires adding some notes).

When moving features that solve user problems into Tier 1, Tier 2, or Tier 3, it often should not just be a raw request, but a meta-thing that might combine multiple requests, and turn into a fuller concept. Requests become refined into concepts as they move over the Tier 4 to Tier 3 threshold.

Choosing what to work on

As with anything in the product development world, there is a science and an art to choosing directions.

Knocking out crashes and showstoppers always comes first. From there, the art of product direction plays a bit more of a role.

Ultimately, Tier 4 starts to show some patterns. These patterns can be turned into concepts that land in Tier 3 or Tier 2. But how do you pick what to work on in any given week?

At the start of every week, I ask myself these questions:

1. Bolster the keys. Is there anything I need to work on this week to bolster the things people love about the app?
2. Expand the keys and remove barriers. Is there anything I need to work on this week to expand into the things people need in order to love the app? Is there anything I need to work on this week to remove barriers that prevent people from loving the app?
3. Directional development. Is there anything I need to work on this week to move the product in the direction I want to take it?

It’s up to your intuition as a product designer to know what directions your product should go in; which audiences it should seek to serve sooner, and which directions take the product closer to your vision, rather than further from it.

Trust your instinct here; you’re getting a lot of inputs in this requests list. Once informed by the list, step back from it and consider what your gut says — you’ll know when you feel good about the next step versus when you feel like you’re working on something for the wrong reasons. And if you realize you’ve started down the wrong direction, pause, seek to find out more information, and see where you are led.

Attach names to requests

I have every request organized in Things, with everyone who requested it listed in the title of the request itself. As I read down my list, I see a list of names. This is huge for my work for a number of reasons:

1. When something ships, I can let the people who requested it know, and find out if I’ve truly solved their problem. I doubt most people love reading long changelogs. I publish them, but you don’t have to read them to find out that I shipped something you wanted. I’ll let you know personally. The difference this makes for people is big – they aren’t a ticket number; they know I’m serving their needs, and they have the opportunity to check out the change / fix / addition, and to let me know if it didn’t fully get at what they needed.
2. I can track interest level. Not only can I see how many people requested something, I know who requested it. That means I can see if the only people who requested something don’t even use the app anymore, if their needs might have changed, etc.
3. I can reach out for more info or with test builds. I do this a ton. Often I might start considering how to approach a certain item, and I have a decision to make that leaves me needing more information. With people’s names attached, I can reach out and find out more, or offer a proposed solution for feedback. I also often send over a test build to these folks, particularly when dealing with a hard-to-reproduce bug.
4. I can consider what I already know about people’s use cases. I know who tends to have a clean inbox. I know who tends to have a full one. I know who tends to use lists a lot. I know who tends to have long threads. I know all of this from prior conversations with users. As I am approaching someone’s request or bug report, I know a lot of the context around the request already. This makes reproducing a bug significantly faster, or considering the ramifications of my decisions for the user much easier.
5. I find a higher motivation to work on the items. With a name attached, I find myself with far greater motivation to move into an item. Instead of a big list of chores I need to tend to, on each request I can see exactly who will be excited by the item shipping; whose day will be made a little bit easier. The motivation this provides is awesome.

Ultimately, with a large audience, tagging requests with the names of those who made the request helps me to remember people and their needs, and to keep more in touch with them. A few times, users have mentioned their surprise when I remember something from interacting with them months prior, given how many others I communicate with in our community. It sounds small, but it helps everyone treat everyone else as the human behind the computer screen we all are, rather than just a faceless Slack handle or email address.

Give every request a short half-life

Every request should have a short half-life. That is, they decay in importance the longer they go without being requested again. There are many reasons for this: some feature requests are only wanted during the initial transition phase to an app. Some feature requests lose their relevance over time. Some feature requests get supplanted by new things. Some feature requests are from niches of users who find themselves better served by other solutions.

Basically: if I haven’t heard a request in a while, I drop it. It might not be relevant anymore. If it is relevant, either it’ll keep coming up (moving into Tier 4 or Tier 2) or I’ll consider it important to the direction of the product (moving into Tier 3).

So every now and then, usually after a big release (every few weeks), I go through the list, clearing out things which have been served by an update, and clearing out things which I haven’t heard about in a while (into an archive for reference). It doesn’t mean the request is unimportant, it just means that a request with three votes from this week is more important than a request with six votes if the last vote was made many months ago. A system which enforces this half-life is necessary to progressing in directions flexibly informed by all the information you have today, rather than letting information relevant to some day many months ago put present information in the shadows.

Why the list exists

As I mentioned, the most important feature requests will keep coming up. Because of this, I used to not write down feature requests at all. I allowed the ones that kept coming up to be what I worked on.

But this drastic of an approach was problematic: I found that simply allowed the angriest or loudest requesters to dictate too much of our development, which isn’t a good way to go (angry and loud requesters are, individually, only around for a short time).

Having requests tracked keeps me focused on the things being genuinely requested a bunch. Though, as I mentioned, it does require that I let things drop off if they seem to have lost support.

Don’t publish your list

People regularly ask me to publish a development schedule so they don’t have to ‘bother’ me with their questions or requests.

Here’s why I don’t do this: besides the simple fact that I don’t know how long a certain fix or feature might take, when a list is published, requests for the things on that list disappear. People silently wait. I no longer know which of those things is most important. This is why I don’t publish a big development list of every item coming soon.

Instead, I get to hear directly from customers every day about the things most important to them. This allows me to make development decisions informed by the latest information every single day.

It also gives me the opportunity to connect with each person making a request, and often allows me to discover new details or nuances about various requests as people share their own take on the request.

‍

These are the things that make it possible for me to be effective with Mail Pilot’s volume of user requests.

Want new articles delivered straight to you? Subscribe here.