A New Approach to Feature Requests

A few months ago, I got this email from a customer:

It would be wonderful if there was a way to tag/assign forwarded emails to specific task lists within client projects. The “email forwards” section is really cumbersome on large scope client projects where we have lots of balls in the air at once.

It’s pretty straightforward. Our app doesn’t have this feature and they would like it to be added. It’s a feature request. Our support team sees a dozen or so feature requests every day.

Deciding how to handle feature requests like this one is tough. Do you track every single one? Are you only focused on some subset?

And most importantly — how do you turn a customer email into something usable for your product teams? That’s the end goal — something usable by others in the company.

Early in our days at Basecamp, we would literally “read them, throw them away, and forget them”.

“It sounds blasphemous but the ones that are important will keep bubbling up anyway. Those are the only ones you need to remember. Those are the truly essential ones. Don’t worry about tracking and saving each request that comes in. Let your customers be your memory. If it’s really worth remembering, they’ll remind you until you can’t forget. “ — Getting Real

When you’re a company with a few people in it, it works. Everyone is pitching in to answer customer emails so you’re bouncing into that support queue often. Once the company gets bigger though, that approach doesn’t work as well.

As Basecamp the company grew, and our support team grew, we tried tagging all of those feature request emails.

Idea for the calendar? Tag it. Feature request for the message board? Tag it.

But now what? You can go to the product team and say “We’ve seen a 5% increase in customers requesting a grid calendar. “ But how is that helpful information? Just the raw data doesn’t really help. And our support team couldn’t really put together a story from those tagged emails.

That means the product team has to dig through those tagged emails and hope to see any usable information from the customers in those tag emails. It slows things down at best and at worst, leaves the product team without anything to go on.

There’s got to be a better way, right?

That’s the version I want to share with you today. Here’s how we handle feature requests at Basecamp right now.

When a feature request comes in, we start with this question — where does it fit in Basecamp the product?

From that answer, there’s three general paths forward for that request:

  • We’re not going to do it — requests like translations, Gantt charts, time tracking.
  • We’d like to — ideas like Clientside improvements or Dropbox linking. These are ones we’ve built out in previous versions or have talked about a bit before.
  • We don’t know — ones like turn a message into a to-do, out-of-office setting, more keyboard shortcuts. Maybe we’ll explore them down the road. ¯\_(ツ)_/¯

Path One — We’re not going to do it.

If we’re not going to do it, we tell the customer so. This sets expectations up front and lets the customer know if they need to explore an integration, use a workaround, or consider switching to a different product.

For example, a customer might request the Basecamp UI in Spanish. That’s not one we have intentions of doing so there’s no need to track it, tag it, or anything else other than tell the customer we don’t have plans to do that.

Paths two and three — We might at some point.

For the other two paths, we want more information. As the support team, it’s our job to give the product team enough information to make decisions around building a new feature.

It’s kinda like being a detective. We go out and investigate the situation a customer is when they email us their feature request. We talk with people involved, detail the facts, and then bring all of this back to the product team. Once they know the facts, the product team can start thinking through our options.

I want to take you through an actual customer interview that started with “I need X” and ended with a new feature in Basecamp.

Basecamp 3 launched without a grid calendar. You know, the ones that look like Google Calendar, Outlook, etc. We had an agenda style list view of events in projects. And you could always subscribe to an iCalendar feed if you really wanted to see it in a grid calendar using Google Cal or such. But there wasn’t a grid calendar in Basecamp 3 itself.

Naturally, customers emailed us asking about it, especially ones that had used a prior version of Basecamp where a calendar was included. Each week, we’d see emails asking “Where’s the grid calendar in Basecamp 3?”.

From the product team’s view, a grid calendar is tough. It took us months to build one in the Basecamp 2. With Basecamp 3, it was looking like many months of work, which is way outside of our normal six to eight week work cycle. And customers expect your grid calendar to be as good as all the others out there — so you need color coding, week and day view, invites, integrations, repeating options, event length options, etc.

It’s a lot of work. But we have to build it because it feels like everyone’s asking for it, right?

So let’s investigate! It’s kinda like flipping the detective mode switch. I needed to find someone that needed a grid calendar right then and find out everything I could about what they were really trying to do.

The Interview

Meet Annie (name changed to protect the innocent). Annie is a psychologist that works with a team doing in-office client sessions as well as field work. She’s used Basecamp for about a month when she emails us.

Hi. I’m wondering if besides the scheduler is there a way to look at a whole calendar that has everything on it at a glance? Like a week at a glance or a month at a glance or even a day at a glance. Otherwise I have to look at each schedule. And I don’t want to have to constantly open my calendar or have to sync each event created by others to my calendar. Help. Much needed feature.

Perfect — I’ve got my first witness in the “I need a grid calendar” case. I set up a call with her to find out more.

Now with the call, it’s structured around the idea of a Jobs-to-be-Done interview. I’m not looking for the feature she’s seeing in her mind. Instead, I want to know everything I can about the situation that led up to her emailing us. I want to know what “job” she needed that grid calendar for. And I want to put all of this on a timeline as best as I can. That way I can say this happened, then this, which made this happen, and that’s when she emailed us.

So we’re on the call.

First question — “what was going on an hour ago when you decided to send us that email with your calendar idea in it?”

Annie said she had just added an event in Basecamp to book a meeting room for a client session. She had to drive into the office to do that.

On our timeline — I’ve added a new piece of information.

Second question — “Why did you drive to the office to do that?”

Annie said she needed to look at the wall calendar to see what rooms were open for that client session. There’s eight rooms. That’s eight open spots a day for clients.

Third question — “Wait, wall calendar? What’s that?”

Annie said they used to have a company secretary that handled client appointments. But for cash flow reasons, they had to let her go. In her place, they tried using Basecamp for client sessions but couldn’t easily see what dates/times/rooms were open. So they painted a 12ft x 6ft wall with whiteboard paint, drew out a grid, and now use it as a calendar for scheduling. They still add the events to Basecamp for the reminders.

Fourth question — “Have you had to do this before — driving into the office to look for an open spot? If you have, what made this time different than the others?”

Annie said she’s done this before but this day was supposed to be her off day. Plus, she was frustrated because she got to the office, looked at the wall calendar, and saw all eight spots were booked so the client would have to wait until next week.

Whew — what a timeline!

Think about that — even though her client meetings were in Basecamp, she had to drive into the office, on her day off, and physically look at this giant 12ft by 6ft whiteboard wall only to find out it was a wasted trip since the rooms were all booked.

I’d probably drop an email to the support team then too.

The Results

From Annie’s interview, we found out the feature request for a grid calendar isn’t all about this massive calendar tool. It doesn’t have integrations. It can’t do recurring events. It doesn’t sync with your phone or another computer.

But notice what it does really well — it shows space. It’s all about seeing open spots and how busy things are on a given day. That’s something our agenda list view in Basecamp can’t show you.

But is Annie alone in how she uses this? Or does this happen with other customers too?

Back to the queue to find more witnesses for the case!

When I interviewed more customers, the same pattern kept appearing. Jeff needed to see open spots to decide if his team could fit in new client work that week. Shirley needed to see which designers were available and which were spread too thin.

Through these interviews, we found the job customers had. In their language, it was all about a grid calendar. But once you dig in, it was all about seeing space on the calendar. It wasn’t the need for a full blown calendar app. Just something to see the space.

With those details, we could write up a pitch for a new feature. It was picked up for one of our cycles. A team of three people built out the new schedule in about seven weeks. And it fit what our customers were really needing.

It’s Ongoing Research

For us, these interviews happen each week. Usually 2–3 a day if we can. A feature request email comes in and we try to schedule a call with that customer for the same day. With it fresh in their memory, they can really provide details about the situation and put us in their shoes at that moment.

So that’s how we approach feature requests. Find a customer with a feature request, interview them, repeat those interviews until you can see patterns. With that information, a pitch can be written and then the feature created.


For more on this approach, make sure to check out Ryan Singer and Chris Spiek’s Demand Thinking episodes.

How We Work — Tracking the Bugs

An inside look at how we handle bug tracking with Basecamp 3.

Ksenija had a great question from my last “How We Work” post.

One thing that interests me the most is do you have some kind of automatic integration between Help Scout and Basecamp or do you manually write important things in BC?

Why I’m interested in that is because I would like to know how do you associate BC to-do for engineer (if engineer support is needed and if you resolve support issues over to-dos) with concrete customer issue in Help Scout!

With our setup, we don’t have any automatic integrations between Help Scout (the customer support app we use) and Basecamp. Through a few nifty Zapier integrations, you could absolutely set something up like that. But we’ve chosen to keep things a bit more simple for us.

Here’s how we handle interactions between our support team and programmers when it comes to bugs.

Isolated Bugs

Most of the situations we see on a daily basis are one-off problems. Maybe a Doc is acting weird because of some HTML that was pasted into it. Or a file isn’t downloading because something went wrong with uploading it.

For these customer emails, we assign it to an “on call” folder in Help Scout itself. We’ll also leave a note with any info that might be helpful for our support programmers working. From there, they’ll take a look, fix up whatever the problem was, and assign it back. That’s when we let the customer know it’s fixed up.

Bigger Bugs

Sometimes we’ll find bugs and issues that are out-of-scope for the on-call developer team. Those are usually something that’s affecting all of our customers rather than just an isolated person. When that happens, it’s added as a to-do inside Basecamp.

We have a project called “BC3: Bugs” to keep track of them. That project only has one tool enabled — the To-dos list.

The first stop for every new bug is the “Awaiting Triage” list. This allows us to have an easy place to quickly add in new bugs as to-dos.

The to-do name is kept short for easy reference. The notes field contains any details, screenshots, links back to a Help Scout case, or anything else that might be helpful.

From the “Awaiting Triage” list, the bug is then either assigned out or taken by someone that sees one they want to fix. Here’s a full thread where the bug was added as a to-do, discussed, and then fixed.

From the support side, I was notified throughout the process and could keep our customer in the loop. Once Scott fixed things up, he checked off the to-do as complete. Then I emailed the customer with the good news.

It’s in Basecamp!

Keeping it in Basecamp this way means everything is in one place. I don’t have to add a bug to some other app and then link it back to Basecamp. Our programmers and designers only have one place to check for new bugs. Everything’s kept right there in Basecamp for everyone to see.

If you found this article helpful, click that 💙 button below. Thanks!

Finding it tough to keep your support team (or any other team) on the same page? Give Basecamp 3 a shot. It’s a free 30-day trial. Teams simply run better on Basecamp.

How We Work — The Support Team

Meet our customer support team!

An inside look at how our support team uses Basecamp 3.

The Basecamp support team is a fully remote team that spans seven time zones and helps our customers 24 hours a day, seven days a week. It’s tough to get everyone on a team on the same page. It can be even harder to keep them there.

That’s why our team uses Basecamp 3 to stay organized. The tools inside our team space ensures that everyone has answers to questions like “Who’s taking care of Twitter replies right now?”, “What are the common cases we’ve seen this week?” or “Where’s the outline for our online classes?”

We’ve talked before about how we use Basecamp 3 to organize our meetups and run our podcast. This time, let’s dive into how our customer support team works.

Let’s all chat.

With our team entirely remote, it helps to have a place to chat in real time. A virtual water-cooler if you will. Enter Campfire.

Campfire gives us a place to talk instantly about anything that we need to. It’s where we go to ask others about a particularly interesting customer email. Or share the latest Taylor Swift music video. We’ve even had some fun GIF battles there. As shifts come online and then leave at the end of the day, you’ll also see lots of hello’s and goodbye’s said. It’s a powerful tool for making sure that your team feels connected, even if they are on the other side of the planet.

Chatting around the Campfire.

Default away from the never-ending conveyor belt.

While Campfire is great for those real time chats, it’s not designed to be an all-day meeting. For updates and other messages that the entire team need to see, we use the Message Board. We also use it for conversations that need some time to happen, like this one.

Much easier than a messy email thread or losing it in a chat.

Instead of that message being lost in the never-ending conveyor belt of a chat, it’s right there on the Message Board. The conversation happens through comments with plenty of time for each person to think about their answer.

Create space with the Schedule.

For any events related to the team, those go on our Schedule. It can be things like customer trainings or calls, our regular 1:1s, and times that we’ll be out for vacations or other days off.

We also schedule in time to work on side projects or anything else that takes us out of our email queue. By putting it on the Schedule, we create space for each of us. Without that space, your team will end up as queue monkeys trying to get through just one more email.

Create space with a schedule.

One less status meeting to attend.

Status meetings are the worst. Thankfully we don’t have them with our team because of check-ins.

With the Automatic Check-in tool, we ask everyone on the team a few things on a regular schedule. The check-in allows us to talk about questions like “What was a common issue that you saw this week?” without needing to hold a weekly team meeting.

Checking in each week.

All of your resources in one place.

Our Docs and Files tool sees a lot of use. It’s our go-to place for our files, the online class resources, our customer ideas, and anything else our team might need. Everything’s organized by topics using the folder option. And a few of those folders even have Readme docs in it to give a person the gist of what that folder is for.

Files and docs all in one place.

One of my favorite folders in here is the Happy File, an idea we stole from the team over at Automattic. It’s a place to share the love that customers have for Basecamp — the team and the product. Here’s Jeremey Duvall on how it works:

Every Happiness Engineer is encouraged to create a happy file just for them. In that file, they keep amazing [customer] interactions… When they feel down during the day, looking through the file is a quick way to pick themselves back up.

Instead of it being an individual file, we’re trying it out as a team file. Whenever someone has something to share, they start a new doc and put the comment, email, Tweet, or whatever it is there.

#support #awesome

It’s in Basecamp.

Remember those questions where we started? It’s a simple answer now — it’s in Basecamp! One place to check who’s handling Twitter replies, what common cases we’ve seen this week, and where that class outline is. It’s our central source of truth for everyone on the team.

If you have any questions about how our team works or want more details on anything above, leave a comment and I’ll do my best to answer!

If you found this article helpful, click that 💙 button below. Thanks!

Finding it tough to keep your support team (or any other team) on the same page? Give Basecamp 3 a shot. It’s a free 30-day trial. Teams simply run better on Basecamp.

The Lost Coffee Order

A great experience even when things went wrong.

Last month, I sent a surprise gift to one of our customers. In an unfortunate series of events, the gift package never made it to her.

Here’s the email I received from the coffee company I bought the gift from:

I spoke with your customer and she says that they did not receive the package and has spoken with her neighbors to be sure that the box was not delivered to one of them by accident. On the day of delivery, there was terrible weather all across the area, including tornados. Many businesses and all of the schools closed that day, but she says that their office did not close. It is possible that either the postal delivery person was in too big of a hurry that day because of the weather and chose not to deliver the box or there was a substitute delivery person who did not know where to leave the package.

I am very frustrated that this has happened. I am going to re-flavor the coffee (Hazelnut) today (it has to sit overnight) and deliver the coffee/ tea order to her myself tomorrow. I’ll let you know if I get any more information.

Thanks, again, for the order.

Clarke, Highland Coffees

They really did a great job turning this potentially negative situation into a great one. Instead of blaming the post office or leaving me to figure out where the package went, Clark sent out a brand new order. Clarke even shared in my frustration that the experience wasn’t perfect.

Explanation? Check.

Empathy? Check.

Promise to follow-up? Check.

Even though this order might take an extra little bit to get to the customer, I’d still order with Highland Coffees again in the future. It turned out to be a great experience even when things went wrong.

We work hard to provide the same stellar experience with our customers. If you haven’t yet, go check out Basecamp 3!

No Reply Addresses

Go check your inbox right now. I guarantee you’ve got a few emails from a “[email protected]”. A quick search through mine yielded 28 different no-reply emails from 28 different companies. It’s not limited to only big companies either. Tiny startups use them to send out their newsletters, invites, notifications, etc.

When I get an email from a no-reply address, I know that company doesn’t want to hear from me. They’re telling me that while I need to read this email, they won’t be reading any replies that I want to send them about it. They can consume my time but they won’t spare any of their time for me.

In short, they don’t care.

Sometimes it’s unintentional. A new startup sees that other businesses are doing it so they do. Sometimes it’s intentional because a company doesn’t want to get bombarded by auto-responders about being out of the office. And sometimes it’s justifiable. If your app sends out email notifications for certain actions, like checking off a to-do or sending a message, then I can understand the use of a no-reply email address.

But overall, stay far, far away from them.

You want your customers to be talking to you. You want them sharing ideas and experiences with you. Instead of a no-reply, set it to your support email address. Make sure someone will see any replies that a customer sends. Sure, you’re going to get lots of auto-responders. That’s why your email app has filter and rules you can set up.

Embrace the idea of a yes-reply email address. It’ll keep that communication lane open between you and your customer. It’ll make customers realize that you do value their time and will give them some of yours if they want it.

Your goal should be to talk more with your customers. Switching your no-reply addresses over will be a great first step towards it.