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.

The Why before the Why

Before “Why They Buy” there’s “Why They Shop”

Every company is interested in why people buy their products, but rewind time a bit further and you’ll find even more fundamental insights.

Before someone goes buying, there’s a reason they go shopping.

There are usually a few events that lead to the desire — or demand — to shop. Something happens that trips the initial thought. There’s a spark. This is often when passive looking begins. You aren’t feeling the internal pressure to buy yet, but you’re starting to get curious. Then a second event happens. It could be soon after the first, or months later, but this one’s more serious. It lights a fire. You need to make progress. Now you’re actively shopping.

We discovered four things

Over the past few months, we’ve been interviewing customers to understand what led up to their need to begin shopping for — and ultimately buying — Basecamp. Across the interviews, it turns out there were four common situations that triggered people to actively shop for Basecamp.

#1 “We can’t keep working like this.”

This is what what “We can’t keep working like this” looks like. (Illustration by Jason Zimdars)

We heard stories about inefficient communication. Growth was causing older, earlier, “it used to work fine” processes to break down. There was a bottleneck — too much stuff was flowing back to one person (the owner, usually) prior to it flowing back out to everyone else. A general sense of “we can’t be the business we want to be tomorrow if we keep working the same way we are today”. Growth was on the way, but they knew the way they were working couldn’t support it. Growth was making things worse, not better. There was too much load, hence a desire to streamline. A general sense of hurriedness, hair-on-fire rushing around to put out other fires. Scattered thoughts and ideas. Fear that something’s going to break at the worst possible time.

#2 “We can’t mess up like that again.”

This is what what “We can’t mess up like that again” looks like. (Illustration by Jason Zimdars)

Unlike the first example above (“we can’t keep working like this”) which mostly anticipated problems up ahead, this situation gets right to the heart of it: Something bad actually happened. They messed up big-time, and that kind of mess up simply can’t happen again. A ball was dropped, a critical deadline was missed, someone forgot something important, something slipped through the cracks. It felt like professional negligence, even though they thought they were being diligent. It often happened because people weren’t coordinated. Lots of talking, not enough coordination. One person though the other person would take care of it, but it never happened and no one found out until it was too late. The client chewed them out. A professional embarrassment. Never again. Time to get our shit organized and together.

#3 “This project isn’t getting off the ground.”

This is what what “This project isn’t getting off the ground” looks like. (Illustration by Jason Zimdars)

Common tale here. Lots of talking, not enough action. Teams may have turned to chat tools, but they’re finding they’re just running on a never-ending treadmill. They can’t get traction through conversation alone. Or people have enthusiastic “let’s do this!” meetings in person (or via video), but then nothing happens. The desire is there, but the means to gain traction, plan, and organize steps are absent. People may be on different schedules in different locations, so continued real-time meetings or communication isn’t possible. Nothing ends up getting done because they can’t coordinate once they stop talking. They need something that not only brings people together, but something that helps them organize, delegate, communicate at different speeds, and make progress together on everyone’s own schedule.

#4 “How am I going to pull this off?”

This is what what “How am I going to pull this off?” looks like. (Illustration by Jason Zimdars)

This one is all about someone being given greater responsibility. They’re leading people now. It’s big and important, and it’s on them to run the team and get it done right. They’ll need to track work that needs to get done, who’s working on what, what they asked people to do, and the overall status of the project. There’s a lot of coordination and communication required to pull it off. They need to have a clear handle of things so they can report up when their boss asks for an update. Such a responsibility comes with a feeling that what’s coming is going to be overwhelming without a proper process and tool that keeps everyone up to date, informed, and organized. Talk ain’t enough, “I’m going to need a system”.

What this all means

There’s lots you can do with this information. It can inform product development, it can change the way you market the product, it can influence the language you use to describe your product to your customers, it can change where you advertise, how you sell, etc.

But for me, what’s most interesting is feeling the moments, the situations people find themselves in before they’re our customers. It’s all situational. It’s not about this industry or that one. It’s not about demographics, either. It’s not even about the competitive set, yet. It’s all about the situation they’re in, the reality they’re trying to wrangle, and the progress they’re trying to make.

And it’s really satisfying that they turn to Basecamp to help them through such important moments in their business. Basecamp is often second — they’ve tried something else before, or cobbled together a series of tools they stumbled into but fumbled around with. Basecamp’s a graduation moment for them — something that helps them steer their business away from random chaos and towards intentional control. They’re now able to grab the wheel and point their business in the direction they’ve always wanted.

What are you competing with?

You may think you’re competing with competitors, but you’re often competing with something, not someone.

One dollar bid, now two, now two, will ya’ give me two? Two dollar bid, now three, now three, will ya’ give me three?

I was recently talking to a guy who’s in the business of helping car dealers move used cars off their lot.

Turns out, over ten million of the cars dealers take in on trade aren’t actually resold directly to customers. They’re often sold wholesale at auction.

Sometimes a car sits on a lot because it’s in the wrong place. Not in the wrong place on the lot, but in the wrong region of the country. A Subaru may sell better in Colorado than in Georgia, for example. Or a Honda Accord may do better in Milwaukee than San Diego.

So they send them to auction. And different dealers/buyers from all over the country bid, buy, and redistribute cars.

When you think about it, the entire used car sales market is highly inefficient. Where a car gets traded in is totally random. It has nothing to do with demand in that specific location. A customer wants a different car that’s local, so they trade in their old one, and, to make the sale, the dealer takes it in even if there isn’t that much demand for it.

So these guys started a company to offer dealers an alternative to sending cars to auction: they’d sidestep the auctions, buy them direct off the lot, and do the trading and redistribution themselves. Sure bets rather than roll-the-dice auction prices, and a whole lot less hassle. Bottom line: They can save dealers time, headache, and money. Seems like a win.

But they’re running into resistance.

The main resistance comes from the sales managers at the dealerships. And in most cases, the sales managers would be the ones making the decision.

Turns out, saving time, headache, and money isn’t a top priority of the sales managers. You’d think it would be — especially since they always seem to hardball you when selling you a car. Seems like every dollars counts to them, right? Well, sometimes.

What’s more important to a sales manager than a dollar? A day away from the office. A break from the monotony of selling cars off the lot. A road trip to the auction. Hanging with their other sales manager buddies in a hotel somewhere far from home. A little vacay, even if it’s a working vacation.

The company that’s trying to sell the anti-auction product and service isn’t competing with the auction, they are competing with the auction experience. And that experience involves all the stuff outside the auction. Camaraderie with their buddies, time away from home, the minor adventure of hitting the road and rolling the dice.

Sales managers aren’t really incentivized to make the dealership the most possible money. They care about doing well enough to show progress and keep their jobs, but they care a lot more about the “perks” that come with getting out of the office for a day. And anything that challenges that is met with significant resistance.

After all, the sales manager doesn’t see the savings in their pocket — those dollars end up with the owner or shareholders. But the hang with their buddies? That’s for them. That’s their gain. And to hell with someone if they’re going to take that away from them.

So while this company may compete with other companies offering similar non-auction services, they’re really competing with something else entirely.

If you dig this sort of lens on competition, be sure to read Clayton Christensen’s latest book on Jobs to Be Done called Competing Against Luck. The story above is not in the book, but the ideas above are represented in serial detail in the book. Highly recommended read.

Foggy thinking in design (and how to cut through it)

As designers we’ve all used foggy sentences like these:

“I felt it was getting a little too heavy for the casual nature of the feature.”

“The screen was a little confusing so we moved the layout around.”

“We really need this flow to be easy and clear.”

They sound meaningful but they don’t point to specific trade-offs or product attributes. They’re dressed up ways of saying “I like this better.” What actually makes it easier, or what specifically is confusing about it? Here are some examples of the questions you can use to cut through the fog.

What do ‘easy’ and ‘clear’ really mean?

  • It’s possible to implement in a short time window? (I’m under deadline and if I can’t send this email blast today I’ll have to come in on Sunday.)
  • It requires less domain knowledge? (I don’t know anything about taxes but I just answered some questions and it e-filed my return.)
  • It sets expectations about the future? (I spent all day setting it up but I felt confident that the transfer would go through.)
  • It leverages skills they already have? (I can never remember what app to plug in to the scanner, but taking a picture with my phone is easy.)

What does ‘confusing’ mean?

  • It uses unfamiliar language? (I’m trying to set up an appointment window but it asks me to “create an activity” first.)
  • It offers choices that are too similar to each other? (How’s the Message Board different from sending messages in the chat?)
  • It doesn’t explain what’s happening behind the scenes? (I sent the invitation but I can’t tell if they got it or what happens next.)
  • It goes against muscle memory? (That Discard button is right where the Post button normally is on the other tools. I keep clicking it accidentally.)

What does ‘heavy’ mean?

  • It takes too long to load? (I tried pulling up the website to get the address but it was loading so slow I just searched Maps instead.)
  • It takes too much time to do given the user’s situation? (I need to enter this follow-up before I get off the phone or I’m going to lose track of it.)
  • It takes too much effort given the user’s goal? (My clients are willing to sign the doc, but they don’t want to set up an account. They end up asking me to email it to them instead.)
  • It sends the wrong social signal? (This invitation makes the party look extremely formal and I’m worried those people won’t want to come.)
  • It triggers the wrong emotion for the time? (We rented this movie to unwind and now it’s killing the mood.)

How to defog your design

First, amp up your BS detector. Ask “what does that really mean?”

Second, if you don’t know the answer, it’s probably time to bone up on your domain expertise. Talk to customers, go on site, do some interviews, whatever it takes to get in touch with the reality.

Lastly, include time in your thinking. A great way to put a foggy statement into context is to stop asking “why” and ask “when” instead. Discussions about “why” devolve into personal opinions without a specific moment in time to anchor and contextualize them.

Tell a story about the problem. Stories require you to define the situation where somebody had a specific window of time, a specific circumstance, and a specific level of warm-blooded interest in the outcome.

This is a cultural thing in our field. Unclear thinking doesn’t have to be ok. We can fight it back and make a bigger impact in our teams by insisting on more real-world context, more clear thinking, and more concrete answers.