Greg asks:
When your product just launched and the user base is starting to grow, you’re happy about any positive feedback you receive from your first users. But just as soon, you start receiving feature requests from the same users. While it’s easy to say “No” to a feature as a team internally, I found it less easy to tell a customer that their suggestion won’t see the light of day anytime soon (for any number of reasons). How do you respond to such requests — especially when the feature “makes sense” as an extension but might be too much of a niche (a power-user feature) or not a top priority right now. The answer might be to just say it, but I thought I’d ask anyway to see what your experience has been and how users responded.
We say no to a lot of ideas — including most of our own ideas. But it’s important to remember that no can be temporary. No now may be yes later. Or it may be no forever. The trick is to figure out which camp a certain no falls into and then respond appropriately.
For example, if someone asks you to add something to your product that you absolutely know you won’t be adding (Gantt charts to Basecamp, for example), you can be clear. “We appreciate the suggestion, but we will not be adding Gantt charts to Basecamp. We’ve taken an entirely different approach to project management with Basecamp…” And so on. If you are going to give an absolute no, it’s nice to briefly explain the thinking behind that decision. It helps people understand that you’ve thought about the no.
However, if the idea sounds reasonable and interesting, but you just don’t have plans for it right now, you can turn that no into a thank you. “Thanks for sending the suggestion over. While we can’t guarantee we’ll be adding this feature, we can promise you we’ll review it and possibly consider it for a future version.” Even though we say no to just about everything by default, we do read and consider every suggestion. Some make it in, some don’t. Some show up in weeks, some may take years. Plans change, markets change, products change.
But most of all, being clear, direct, and honest is the best policy. Don’t string a potential customer along. Don’t make promises you can’t keep. Just be clear and set realistic expectations. Telling someone yes when you really mean no is a recipe for a bad experience down the road.
GeeIWonder
on 27 May 08Thanks for sending the suggestion over. While we can’t guarantee we’ll be adding this feature, we can promise you we’ll review it and possibly consider it for a future version.
Yeah, I disagree here. This sounds more to me like a polite version of ‘[b]u[g] off’ and probably even more insulting than just saying no, or not yet. It’s all very call-center ‘your call is important to us’-y.
I’ve said similar things in different ways - usually putting emphasis on what IS coming . This is usually surprisingly mollifying/encouraging - I think sometimes this is just a ‘are you still moving forward? questions. But I try and adhere to a ‘clear, direct, and honest policy’ that keeps away from condescenscion.
In a FOSS strategy, it’s as often as not a perfect opportunity to spur some new development/developers.
JF
on 27 May 08Geel, if it’s a lie then you’re right. If it’s true, then I think it’s entirely appropriate to thank someone and tell them we’ll consider it for a future version.
9 out of 10 things we add to our products start out as customer requests. We don’t always know what we’re going to add, but we do review every suggestion. But when we know something isn’t going to make it (Gantt charts, for example), we say so.
GeeIWonder
on 27 May 08Great point. I guess mine is that since communication is about both the speaker and the audience, if you send a pseudo-generic ‘we care’ message then your sincerity matters (relatively) little in how it will be interpreted. It’s all very Marshall McLuhan-y.
It’s especially true of course, when speaking of ‘potential’ customers. bWhen you’ve established buy-in, and more importantly trust (as you, and I, and hopefully many more endeavour to do), that certainly alters the message.
Matt
on 27 May 08I agree that the response really depends on the feature request and honesty is the best approach. If you read your response and it sounds canned, people will know.
Feature requests are a good window into starting a dialog about the problems that a user faces and ultimately building better solutions than the original request.
Another area to be careful of is the person that pulls the “I’d join if you had X…” line. If X is not something you plan on doing in the short term, don’t waste your time trying to scope it out when you’re real response is going to be “no”.
JF
on 27 May 08Another area to be careful of is the person that pulls the “I’d join if you had X…” line.
Absolutely. Don’t chase customers who make specific demands like this. “I’d sign up if you only had this that or the other.” Dangerous ground.
mkb
on 27 May 08This doesn’t cause problems with who owns a suggested feature? I assumed that was why many companies simply don’t accept unsolicited requests.
Matt Radel
on 27 May 08I’d be interested (if it hasn’t been touched upon in another post) to hear if/how 37signals tracks enhancement requests. Do you just eventually say, “wow, we’ve gotten a TON of requests for this, mayhaps we should look into adding it”? Or do you have a more specific approach? Just curious.
JF
on 27 May 08Matt: Forget Feature Requests from Getting Real.
Matt Radel
on 27 May 08@ JF: Haha, der. I guess I need to read Getting Real again. ;)
some guy
on 27 May 08I guess my general feeling about feature requests is that you can get most of the utility from that feature you want by adopting a consistent usage convention – hacks for your program.
For instance, if the product you’re using doesn’t support tags but does support fulltext search, make up your own tag naming convention and tag notes/pages/etc appropriately and then search for those (unique) tag strings.
The wiki product you use doesn’t support page templates? Keep a copy of the template(s) stored on a folder in your hard drive and copy and paste into a new page when you need one.
And if you work for a pointy haired boss who absolutely demands Gantt charts (say there’s some regulatory requirement for it), you can always make one in a third-party program, export as PDF/PNG/JPG, and include it as a file attachment/photo gallery/whatever.
This suggests that the best features to add are ones that are generic and plug-and-play with the rest of the world: add search, RSS feeds, and a handful of other things and a lot of other features fall out as hacks and special cases.
It’s kind of like design patterns for endusers.
SH
on 27 May 08I’d be interested (if it hasn’t been touched upon in another post) to hear if/how 37signals tracks enhancement requests.
This is part of the job of our support/customer care person. It’s important to recognize volume of the same request over time, but it’s important to also have intuition about your own products.
I know we will never add Gantt charts to Basecamp. You can send 100 requests on it and we’re just not going to go that way. But we’ve had 1 request for something that was really in line with our philosophies and we were able to implement it in our products in a way that works well for all our customers.
We keep an eye on things we hear great rumblings about often, but we also listen to the soft spoken request by one person. What matters is knowing which is going to be more useful and complimentary for our products, not pleasing the masses with more features.
Stu
on 27 May 08What the heck? There will be no Gantt charts?
Alejandro Moreno
on 27 May 08I’d join Basecamp in a minute if only you had Gantt charts in it.
=D
someone
on 27 May 08Don’t you know that Gantt charts help lower LDL cholesterol as part of a low-fat diet?
Joe Mako
on 27 May 08How about the Feature Request from Backpack Customer Forum – Feature Requests – email reminders ?
I would think this could be in line your philosophies as per Achieving emptiness with Bit Literacy
I would not expect 37signals to approach generating calendar events in the same was as gootodo.com , primarily because Backpack manages events differently. There would need to be a way to determine what calendar to add the event to, and the major difference, there is no way to add details or a long description like the body of an email to a Backpack calendar event.
Maybe another approach is to convince gootodo offer a shared iCalendar subscription (I don’t know if they currently do), and then make use of Can I add an iCalendar to my Backpack Calendar?.
37signals’ software is more powerful than meets the eye.
Jason Luna
on 27 May 08Great post. I completely agree with the comments about not chasing customers who make specific demands.
That said, have you guys ever added a new feature and then measured its effect on new subscriptions? If so, what were the results?
I just wonder if the data shows that some people buy based on features, but stay based on simplicity and ease of use.
Tarık
on 27 May 08I think you should stop saying no to nearly every feature request and start saying some yes’s
Matt
on 28 May 08It’s as much about just being honest with customers as it is with knowing what your focus is internally.
In response to the original question “while it’s easy to say no internally…” – That’s the first hurdle to get over. If you’re not efficient at getting to the yes or no internally, you’ll often waste time / focus scoping things that are not in line with what you’re doing but you’ll also be more inclined to give a soft response. Everybody loses…
Mimo
on 28 May 08Ok, we got it. No Gant charts. Could you explain why? I would like to know the philosophy behind it.
Jeroen van Delft
on 28 May 08While I understand the necessity to say ‘no’ to a customer/user, I do believe that special attention should be given when forming a reply. As GeelWonder stated, a “thanks, we’ll consider it” is usually understood as a “not going to happen”, even when it eventually might.
My suggestion would be to avoid the standard copy/paste replies, and write a reply that actually mentions the suggestion that was given, and include a short explanation why it won’t be included (for now).
So instead of “Thanks for sending the suggestion over. While we can’t guarantee we’ll be adding this feature, we can promise you we’ll review it and possibly consider it for a future version.” you could have “Thanks for suggesting the use of Gannt charts. While this is certainly an interesting feature, this does not currently fit into our vision of Basecamp at the moment, because of .”.
In essence, “copy/past bad, personal attention good”, I guess.
Anonymous Coward
on 28 May 08@Jeroen van Delft: paragraph 3 mentions exactly this.
clifyt
on 28 May 08“No Gant charts. Could you explain why? I would like to know the philosophy behind it.”
I’m assuming because most people don’t know how to use them accurately and only use them for presentational chart junk. Either that, or 37 hasn’t found a way to use them appropriately because of their organizational structure.
In a small setting, everyone knows what they are doing and how fing up is going to hold others back…in a large setting, you need the gants so that you can quickly illustrate what needs to happen and when, and visually understand the consequences of it not happening.
For instance, I use to do a non-profit planning…I was in entertainment for a few years and folks would beg me to help out and blackmail my friends into appearing for free so they could make money for aardvark tit augmentation or otherwise. No one knew how to accurately get this stuff off the ground and volunteer work is notoriously flakey. Ended up that I organized everything because no one else had the planning skills.
Gant charts quickly let me visualize what happens if staging isn’t done by a certain time. Catering, decorations otherwise…don’t really affect much other than themselves. Rentals? Can’t do that until staging is done. Paid staffing? Gotta have other things in place first…and it is an intricate web that you can see what affects what, and what doesn’t affect what. I put the Type-A’s on the high-priority…can’t f-up crap.
Gant charts are important if you are dealing with more than maybe 4 or 5 people (more if everyone is really in-tune with eacher…REALLY in-tune). Small group settings or highly compartmentalized projects that don’t affect other.
Unfortunately, most people only use Gant charts for presentational “Look How Important I Am Because I Wasted 10 Hours Charting What Could Be Said In Two Paragraphs”...I’ve used Basecamp and it is nice, but too limiting for my own use…it would be nice if someone made an add-on product that used its APIs to add this feature. A little visualization goes a long way if you know what you are doing (and again, detracts if you don’t).
Jeroen van Delft
on 28 May 08@Anonymous Coward: I agree, I was attempting to address GeelWonder’s concern, but the point seems to have been lost along the way.
PSolus
on 28 May 08This reminds me of pharmacies that refuse to provide its customers with certain items based on religious beliefs, despite the fact that the custumers do not share those religious beliefs, and actually want and/or need those items.
Gary R Boodhoo
on 28 May 08in my own industry (videogames), it is significantly more difficult getting to “no” internally than with our userbase.
Couple of reasons for this… team sizes are often 120+ for “next-gen” titles. Our technology, tools and methods are often brittle, untested or invented as we go. This isn’t so much by choice, but relates to highly subjective factors such as novelty and narrative.
This discussion is closed.