Getting Real: Forget feature requests - Signal vs. Noise (by 37signals)

Getting Real: Forget feature requests 13 Sep 2005

66 comments Latest by Michael

Ok, so I’m positive this post will be misunderstood and we’ll be branded as arrogant, self-centered, customer-hating snobs. But here goes anyway…

When you launch your products, customers will send you hundreds or thousands of feature requests. Just take a look at the Basecamp Forum or the Backpack Forum — the feature request category trumps all the others. They’ll want everything under the sun. You’ll hear about “just this little extra feature” or “this can’t be hard” or “wouldn’t it be easy to add this” or “it should take just a few seconds to add this” or “if you added this I’d pay twice as much” etc. Of course we don’t fault them for making requests. We encourage it and we want to hear what they have to say. Most everything we add to our products started as a customer request.

They’ll post messages in the forums, send your emails, and find your IM address and hit you up there as well. They’ll fire requests at you faster than you can imagine. So what do you do with all these requests? Where do you store them? How do you manage them? How do you track all these requests? You don’t. Read them and then throw them away.

Yup, read them and throw them away. The ones that are really important will keep bubbling up. And those are the ones you’ll remember. Those are the important ones. You don’t need to track or remember everything — let your customers be your memory. They’ll remind you.

How did we come to this conclusion? When we first launched Basecamp we tracked every major feature request on a Basecamp to-do list. When a request was repeated by someone else we’d update the list with an extra hash mark (II or III or IIII, etc). Then one day we figured we’d review this list and start working from the most requested features down. Truth is, we never looked at it again. Our customers constantly remind us what’s important by making the same requests over and over again. There was no need to be analytical about it since it was happening in real time. You don’t forget what’s important when you are reminded of it every day.

So, ask for requests, read the requests, listen to your customers, and then forgot what they said. Let them remind you over and over and over again. That’s how you find the real gaps in your product. That’s how you’ll remember what new features are really worth considering.

And one more thing: it’s not just about the sheer number of requests (we don’t recommend adding something just because X# of people requested it), it’s about customers planting a seed in your mind. If they keep reminding you of something, it forces you to think about it. Maybe it is a good idea. Maybe it isn’t. But at least it’s important enough to consider if so many people keep asking for it.

66 comments so far (Jump to latest)

Bryce 13 Sep 05

Why you… arrogant, self-centered, customer-hating snobs.

;-)

David Heinemeier Hansson 13 Sep 05

The “seed in your mind” approach also works on single, great innovative ideas. You might think “hu, that’s a neat idea”, then forget about until you face the context in which it was conceived. If the idea is good enough, your brain will bring it up again through the power of association.

So while sheer repetition is one driver of need, a single seed in your mind can be at least as powerful.

Daniel Lakier 13 Sep 05

Scope and risk management are 2 of the most important components of project management. Managing the enhancements you implement is scope management, so you are not being unreasonable (nor particularly revolutionary) with this suggestion.

I think that there is a difference between managing web sites targeted to the general public, and custom developed applications for a specific business. Each would have a different change management process. The one proposed by you may not be viable for some applications, which would probably require a more formal (and cumbersome) change review process.

If the SEC “suggests” options need to me margined in a specific way, you can’t really throw away the change request. :) Whereas, if the intern wants a new color schema, you probably can.

JF 13 Sep 05

Certainly if the SEC requires something to comply with a new law, ruling, or federal mandate, then you have to act. And certainly this “throw them away” method doesn’t apply to every situation (that should be a given), but for the bulk of people developing consumer facing apps today, I do believe this is helpful advice.

Brad 13 Sep 05

Except for my ideas. Of course. Why haven’t you implemented my ideas? Ignore everyone elses requests and just listen to me. Now that is helpful advice.

Brady Joslin 13 Sep 05

When trying to develop innovative products, you must be acutely aware of what the customer problem is, but where you ignore them is in how that problem is to be solved. The customer may not have the creativity or technical knowledge to come up with the best solution for the problem - that is where innovators can show their true value. If your solutions typically increase user satisfaction and productivity greater than what would have been realized by user suggestions, you are a step ahead of the pack and can enjoy great success.

Steve Thorn 13 Sep 05

Ha! I thought it was a common practice to forget what they say because they’ll harp more on the important ones,.. I just didn’t think anyone would have the balls to say it out loud. Nicely done!

Elliott Rosenthal 13 Sep 05

This method only makes sense when you have a suitable level of interest in the product as its being developed.

Not really that controversial, what you saying makes total sense!

later guys.

Steve 13 Sep 05

I think recurring reminders in backpack is a really needed feature. Not really for me, but for the starving children all over the world. Do it for the children.

See, now if they don’t add it, that means they forgot about the starving children of the world. Shame!

-s

Reed 13 Sep 05

I disagree. What this is basically saying is that small minorities with special needs will never have those needs met. If the federal government operated in this manner, section 508 wouldn’t exist. Let’s take an easy example: web-browsers.

In the early Netscape vs. IE wars, both browser companies implemented features as quickly as they could. Most of the time they were requests from users. Often, however, they were not. (Proprietary browser tags, etc.)

Today, IE is dominant. As such, they seem to be adopting the “feature request” system you describe: if enough people complain regularly, it’ll be fixed. Firefox, on the other hand, seems to be more interested in getting as many new features as possible. (Integrated SVG, quicker security patches, etc.) Bugzilla, for instance, is a great way to remind developers of what still needs to be fixed. The idea that users need to constantly squeak to get grease greatly misses the limited free time users have. Instead of speaking with our keyboards, we’ll speak with our wallets and go elsewhere.

And that, in my mind, is the distinction that needs to be drawn between a *bug* and a *feature*. For me, the lack of Ogg support on iPods is a “bug”, not a lack of a “feature”. Yet I’m sure Apple doesn’t view it this way. And I’m equally sure that the iPod developers have no incentive to listen to multiple requests, made year after year, to add ogg support to their players. Yet doing so would easily put a cadre of coders on their side…

Christopher Fahey 13 Sep 05

37s is not the first company to ignore unsolicited feature requests from customers. Almost all of them do the same thing! The fact that you even read them puts you in an elite group already.

It’s absurd for a consumer to expect a company to pay more than passing attention to unsolicited feedback, and it’s dangerous for a company to listen too much to such feedback. Instead, firms should put more trust in real focused customer research and usage data. While they may occasionally have good ideas that you can steal, people who write letters are usually not representative customers.

What I think is important here is the fact that you still READ the requests, and then take a big picture approach to making a product that meets your goals (whatever they might be). My experience has been that some user input with regards to a problem/inefficiency (not necessarily the solution) can be very helpful.

Dan Boland 13 Sep 05

A couple of years ago, I think I would have disagreed, but since I’ve been developing an in-house web-based CMS for my company for the past two years, I can say that the last thing I want to do is implement yet another feature. What it costs me as a developer is the proper time and energy to tighten up what we have and make it better. I’ve been trying to get a redesign off the ground, but new features keep cropping up. And we can’t simply refuse them because doing so would be “hurting the company.” It’s a sucky catch-22.

For me, the lack of Ogg support on iPods is a �bug�, not a lack of a �feature�.

That’s completely wrong. And besides, it hasn’t hurt Apple, has it? Hell, I didn’t even know what Ogg was until you just mentioned it. You think the average iPod customer does?

37s is not the first company to ignore unsolicited feature requests from customers.

You got it wrong in your first sentence. We don’t ignore anything. We read everything. We absorb everything. And then we throw it away. Once we’re reminded of something more than a few times then we start to consider it for a future release.

Wrong choice of words, but you know from my second sentence that I didn’t mean it that way

Got it Christopher. I shouldn’t have rushed to judgement.

Abdul Ovaice 13 Sep 05

I don’t see how this post is problematic. Flickr developed their site based on “User-Driven Development”. They looked at requests their users were making (obviously the frequent requests received more attention) and implemented them, which is what transformed their business into a success.

In general - you have to know when to apply some of the “Getting Real” suggestions (in context), rarely anything in development is an absolute truth. If all web application companies listened to the “3 man team” for 1.0 releases, most of us might be out of a job. Its about context.

simple 13 Sep 05

so the squeaky wheel gets the oil?

David 13 Sep 05

Firefox, on the other hand, seems to be more interested in getting as many new features as possible.

Firefox doesn’t seem to be interested in “as many features as possible”. Heck, they think it’s already too complex! Adding support under the covers for expanding technologies isn’t “as many new features as possible” and is more likely based upon what the masses of their user base are requesting, not sucking in every feature the small minorities request.

Dr_God 13 Sep 05

I have a terrible memory, so I can’t afford to rely on the “absorption method.” And I’m usually juggling several websites at once, so I give all feature requests the Gene Siskel test - thumbs up or thumbs down. If I like the idea, it goes straight onto my Ta-da list for that website. If I don’t like the idea - it goes in the trash. I find myself reviewing my Ta-da lists for website quite often.

Anonymous Coward 13 Sep 05

“What this is basically saying is that small minorities with special needs will never have those needs met.”

IMO, for a general market product, that would be a correct statement, and a reasonable way of doing business. In my line of work I often have customers who will make reasonable requests- reasonable in that the request they are making is a valid need that they have, that they would like for me to fill. But they’re not the sole client and you have to be able to balance their niche need witht he needs of the rest of your customers. I get a lot of “You need to…” which I counter with “SOMEONE needs to, but it ain’t me.”

The most important thing my software does is what it doesn’t do. That’s why my customers buy. It’s important for them to understand the vision for the product, which can take some teaching. But in the long run, their apprecaition stems from the product’s simplicity, rather than a bloated list of half-implemented “features.”

I suppose I am too corporate here, but really this isssue is the implementation of a change management process. Having users contact developers directly is a disaster, not listening to your users, at all is a disaster. Implementing a change management process should be a key component of your software development life cycle.

37Signals as a process of analyzing requests and then using them as inputs to their design process, but not as specific requirements is a valid and appropriate change management process for their, and many other situations.

Other situations might require different change management processes, but anyone producing a product should really spend some time on this part of the lifecycle.

My only beef with this topic is the use of absolutes with regards to the type of change management solution that is appropriate.

Dante Hicks 13 Sep 05

That’s all fine and good for a product that is being offered to the general public. It doesn’t hold true for products you develop for specific clients tho. When they say they want something, you can’t really ignore that request because you’re not sure if it’s really needed or not.

You got it wrong in your first sentence. We don�t ignore anything. We read everything. We absorb everything. And then we throw it away. Once we�re reminded of something more than a few times then we start to consider it for a future release.

You use the best aggregator of data you have: your brain. ;)

Of course you may still come across a lone request that makes you go, “Of course!” and then you are off to fix the problem.

This method works very well for small groups, with little turnover, working on the same efforts. Anything bigger and I think you need to track things like you were doing before.

Andrew 13 Sep 05

You’re talking of course about the difference between a “request” and a “requirement.” Anyone can make a “request”, but it takes considerable thought, need, and benefit before that becomes a true “requirement” that eventually becomes an aspect or behavior of the product.

“Requiurement management” is when an idea (“more than one client per project in Basecamp”) becomes a requirement (validate that it’s not the same customer twice, make sure to extend user lists to include users in both clients, make sure outgoing emails don’t refer to the other client by accident, etc.)

Joe Rawlinson 13 Sep 05

Applying a filter like you describe will prevent you from getting hung up on the “great” feature that only one person wants.

While that one person’s idea could be stellar, you need a way to balance your resources and the needs of the masses for your next product release.

Today, IE is dominant. As such, they seem to be adopting the �feature request� system you describe: if enough people complain regularly, it�ll be fixed

Of course you may still come across a lone request that makes you go, �Of course!� and then you are off to fix the problem.

Don’t confuse a feature request with a bug fix. I’m sure if only one person contacted 37 and told them where something was actually broken it would not be read and forgotten.

It’s not about ignoring the flat tire, but questioning the addition of the 500 watt sub woofer. That’s what I think anyway.

Dima 13 Sep 05

I’m trying to add all good feature requests to a special page at BackPackIt, even if I read them for the first time (some of them with status POSTPONED - which means I would do them, but don’t know when exactly).

Shanti Braford 13 Sep 05

In all reality, you probably won’t “throw away” the requests that you’ve taken note of, if you’ve even done that. You just won’t use the list when it comes time to implement anything.

The psychic tension will have built up so much by then that you’ll be going off that instead. Like the math problem you come back to a few hours later and have figure out subconsciously.

Now, bugs, genuine *bugs* - should be noted. Unless you have the DHH’s of the world on your squad who can knock them out faster than you can say “David Heinemeier Hansson”, three times fast! =)

Don Wilson 13 Sep 05

So don’t count the requests and forget all fo them, but use the requests (that you forgot) that are requested the most?

Excellent oxymoronic post.

Gen Taguchi 13 Sep 05

Hello, i enjoy reading your blog from here in Japan. Thanks always for your inspiring inputs.

this post reminds me of a venture company called “Hatena” (http://www.hatena.ne.jp/) based in Tokyo.

they have a service called “Hatena Idea” (http://i.hatena.ne.jp/), which they treat feature request as a “stock”. Other users can buy & sell their ideas (if you like the idea, they can buy, if they don’t they sell). looking at this “stock price”, Hatena people can measure what’s really needed by users. and if Hatena decides to adopt an idea, they pay dividends to users who “hold” the idea.

although it is still in beta and is a little complicated to understand, over 5,800 ideas (=stocks) have been registered and actively traded.

this might be a new way to treat user requests… i know it’s against your policy being “less and simpler”, but hey, i just wanted to let you all know a little bit about what’s going on here in Japan.

FYI, Hatena is also a small company (with 10+ people), and is getting huge attention nowadays for their products and their unique developing style (let me know if you would like to know more… i’d like to keep this comment short).

Ian 13 Sep 05

I hope the feature requests that spark an idea are not tossed directly in the trash without at least noting the idea. The brain is horrible for information retrieval. Relying on customers to serve as your reminder that the idea needs further thought seems like a good way to miss a lot of ideas that only one person has.

I agree with most of Getting Real. But I am concerned about over-commitment to ideology. I also feel like 37S believes more every day that it can’t learn from other companies, it can only teach. Beware…

I also feel like 37S believes more every day that it can�t learn from other companies, it can only teach. Beware�

Where do you get this impression? We’re obsessed with learning, changing, and trying new things. We’re constantly evolving and are inspired by many sources.

BL 13 Sep 05

First off, I want to say that I’d agree with most of the Getting Real stuff. Personally, I tend not to think of these things in such absolute terms. But that’s just me. My only comment is that I really don’t like the name “Getting Real”. For some reason, it strikes me as condescending. I mean if someone were to say to me “Get real”, I’d take that as an insult.

Yes, from the name Getting Real to the recent spate of criticisms against other software/software companies… it’s just a zeitgeist thing in my mind.

I tend to agree with your opinions, and love your software. I would even call myself a Zealot. Maybe it’s just that I am halfway through “Why Smart Executives Fail” and saw a few too many symptoms of the Zombie Company disease manifesting in 37S.

I can certainly appreciate how open you guys are; I can’t think of any other company that would reveal this much of their business model to the world. But here you present an methodology for handling feature requests that

a) may miss some really keen ideas that only happen once (like most good ideas do)
b) ultimately reward the most popular ideas

I’m saying this as someone who posts regularly to both forums, mostly about potential new features. Knowing that this is the system you guys use to process those requests will change the way I post.

We don’t miss anything. We read and absorb everything and we don’t delete forum posts — just emails. Further, if it’s a great idea it *will* be repeated or it will be so great that it stands out and we go with it.

For example, only *1* person came up with a solution to comment editing in Basecamp (give people 15 minutes to edit their comments). We loved the idea so much we ran with it. We didn’t need validation from others — we know it was the right idea.

As far as “the recent spate of criticisms against other software/software companies,” we’ve always been about calling things out that we think are problematic. Ever since 1999. There’s nothing new here.

We have tremendous respect for anyone who manages to get a product to market. And we know we have a lot to learn. And we’re learning, making mistakes, and learning some more.

So a “Zombie Company” we are not.

Mathew Patterson 14 Sep 05

a �Zombie Company� we are not
Sounds like a great new tagline for 37Signals.

JF 14 Sep 05

Sounds like a great new tagline for 37Signals.

Better than “We put the DIG IT in Digital” ?

Better than �We put the DIG IT in Digital� ?

Damn, that’s good too. Tough call. I went to Caringbah High School (Sydney)…we ‘put the Caring into Caringbah’.

Beckie 14 Sep 05

Is Bush listening to his fellow Americans? Well, look who’s calling himself president…

Ian 14 Sep 05

I’ve thought about this a lot since posting, and though I meant what I said at the time—I think it was more about impulse than anything. Again it’s probably just the context of the book I’m reading (a good read, by the way, though appeals to the same part of the brain that stays to watch a train wreck).

Joe Clark 14 Sep 05

If you go for this business that popularity, recency effect, and top-of-mind awareness guide your feature updates, then golly, features that are *mandatory* for a minority of your users will never, ever get added. Like accessibility, which I remind you lot about every couple of months.

You won’t even hear a request half the time if your product is intrinsically inaccessible. Claiming to respond to overwhelming customer demands will *always* leave customers out, including groups of customers it is illegal to leave out in many places.

Don’t suppose you thought about that, Jason?

DJ 17 Sep 05

I’m on the fence on this after Joe’s comment. While I agree the methods you use are (mostly) logical, Joe also has a good point about accessibility, the possible users accessibility opens up to is immense, while you may have a very low number (or no) “extra-needs” users at the moment - (hence the lack of requests for accessibility) news spreads fast. So a whole market you feel aren’t interested could very well be balancing on the tips of their toes for the right sort of thing to come along.

p.s. this isn’t just limited to accessibility, opening open to a broader group of people can always bring in the masses in any scenario.

Barry Welford 17 Sep 05

I believe you should only listen to *smart* customers. What I mean by that you can find in a post yesterday on ” Listening To Customers May Not Be Customer-Centric”. There you’ll also find mention of a very recent post by Kathy Sierra in her blog, Creating Passionate Users, entitled “Listening to users considered harmful?” It’s all going along with the same basic theme that’s being discussed here.

Noel Guinane 17 Sep 05

“Read them and throw them away … Our customers constantly remind us what�s important by making the same requests over and over again.”

So what you’re saying is that you have to be nagged into listening to what your customers want. You’ll only pay attention to what they’re saying if lots of them keep bothering you with it and going on and on and on about it.

I’ve heard some dusies, but this has got to be one of the dumbest things I’ve heard anyone publicly admit to doing when it comes to their customer relations.

I downloaded your product and thought it was good. Now I know that if I spotted an improvement and suggested it to you that my suggestion would be read (or so you say) but “thrown away” unless and until I and hundreds of others have hassled you so many times that you’d actually pay attention to what we’re saying.

Your approach to customer relations would not encourage me to either use your product or recommend it to others.

Alexandre Simard 17 Sep 05

I downloaded your product

Where’s that download link? I’m dying to install and personnalize my BaseCamp copy. ;-)

Greg Hunt 18 Sep 05

One thing that seems to be missing from your approach… Sometimes people ask for things that address the symptoms of their real problems, not for the things that deal with their problems.

Users approach software in different ways and their feature requests reflect those ways. Knowing what combinations of things people ask for, and looking at the recurring combinations is a useful way of understanding the client’s world and of steering the feature set. If you discard the requests you can’t go back and discover those relationships.

Chris 19 Sep 05

Let them bubble to the top! You are exactly right. As a software developer, I get my share of feature requests directly from users. Users know what they want but they don’t understand realistic development time, testing time, etc. They also think in a very self-centered manner. Nothing wrong with self-centered in this context but if their request would require 8 hours of work and they are the only user that has ever requested that feature - it’s just not worth it.
I also can’t release an update anytime I want. I find it best to see what stuff continually bubbles up and then grab those requests and impliment them all into a new version (if they are reasonable requests).
My only other note of importance is THINK about the feature requests regardless of their frequency. Maybe there is a new PRODUCT that could arise based on ONE users request. Look at the different types of laundry deturgent! You might sell one product but have the hidden potential for three.

Pat 19 Sep 05

I find a couple of things troubling about this.

I agree that customers will keep reminding you, but what the feature is or issue is will be hard to explain because it’s not their job to explain in technospeak. And sometimes they’ll have very different approaches on how they think the problem should be solved. Sometimes you have to read every customer service to see the patterns, and while the good ideas may bubble up, they usually won’t be as obvious as suggested here. There also should be the real world realization that every feature, fix, change should have a dollar amount matched to it, because that’s how businesses work. Some things are hard to quantify, but others are very easy by estimating the ROI.

The other is that most developers/product managers think in terms of the big features. Users don’t want big features — they just the want the product they are using to work., so it’s usually a number of smaller changes; basically the sum is more that the total of the parts.

Noel Guinane 20 Sep 05

In Jason’s view it is the parts that are more irritating than the sum.

Stephanie 21 Sep 05

And, so I still don’t see why certain requests are deemed unworthy: ie multiple lists on single pages. There are certainly enough requests for this feature, and they are not crackpot requests. The reasons for this request are, to my mind, substansive; and the work-arounds required to accomodate for its lack seem unnecessary and cumbersome. Why wouldn’t you want to please your customers in a situation like this. It is not like we are not paying for your product or that you are letting us share something you designed solely for yourselves.

I like backpack very VERY much, but it is incredibly frustrating to me that I cannot use it as I would if this one feature is added.

Jason, please explain if you would (and yes, I hear you that you don’t have to explain…)

John Wood 03 Oct 05

This attitude to feature requests is absolutely spot on. It’s ceryainly not new, though, and was introduced to software engineering by Brooks in the Mythical Man-Month over 20 years ago. It’s called conceptual integrity and means that someone needs to control the vision of what a product is and what it is not.

Alan Cooper shows what happens when you do not retain control of a product in The inmates are running the asylum, he calls it the customer driven death spiral, which is where contradictory requests will tear a product in hundreds of directions and please no one, not even the customers making those requests. I’ve seen it happen first hand, not pretty.

Say no to a request, and people usually buy anyway. If they don’t, you are better off without their business.

Jeff Wright 05 Oct 05

This makes no sense at all. On one hand I can understand that tracking of requests is little better than waiting for them to be repeated. But that only measures frequency.

What about the good ideas that are had only be a few? As most good ideas are. Or the serious problems had only by a few? They are to be forgotten?

It seems to me that if you’re presented with a good idea you’d be a fool not to remember it, regardless of how many people have bugged you about it.

Michael McDade 18 Oct 05

Waiting for something to continually surface in order to remind you of the need is one of the most ridiculous things I’ve ever heard. It’s all about functionality and ease of use. Once you’ve identified good ideas, then put out a poll listing the top 10 enhancements you are considering (chosen by how much it improves the basecamp system). Give everyone 30 days to vote - then do it. The global milestones view to keep from overloading our staffs must have been more desired and usable then a whiteboard. Gosh!

John 09 Nov 05

You’re invited to visit my Partnersuche site.

JP 09 Nov 05

So much for listening to your clients

me 17 Jan 06

Careful porno links

John Luker 22 Feb 06

I’m in the process of reviewing PM software. Although I like Basecamp in concept this blog entry (along with the forum topic that linked to it) has eliminated it from consideration. 37signals is not MS and you sir are not BG. I applaud your commitment to timely response to user questions but find the attitude about a major bug (bounced email) more than outweighs the positive. Good luck.

I’m in the process of reviewing PM software. Although I like Basecamp in concept this blog entry (along with the forum topic that linked to it) has eliminated it from consideration. 37signals is not MS and you sir are not BG. I applaud your commitment to timely response to user questions but find the negative attitude about a major bug (bounced email) more than outweighs the positive. Good luck.

Jeff Coleman 13 Mar 06

I think it’s fascinating that even after Jason Fried’s most recently replies, there are still posts saying “What about really great requests that only get posted once?”

Like, for example, allowing users to edit their Basecamp comments for 15 minutes?

Jason gave an exact example of how that can work, a suggestion that was made once and was considered worth doing.

In my opinion what they’re suggesting is not ignoring your customers or literally “forgetting” their suggestions, but it’s about responding organically to the requests rather than wasting time on an overly-structured request-tracking scheme.

Al Gore 12 May 06

Al Gore Here. I read this post and already forgot about it.
This technique must be work.

Hugs

Michael 07 Jun 06

This is a disappointing attitude towards your customers, and it strikes me a somewhat lazy. But now that I know this is your approach I’ll just set up my email to automatically send you my feature requests once a month. :-)

In any case, the major pitfall to this approach is that it might favor the popular ideas over the good ideas. I think we’d agree that there is a big difference between the two. It also seems to encourage people to repeat themselves to you.

What happens if your employees leave? A big chunk of your brain-based feature tracking system is now taking 6 months off to travel the world or work for a competitor.

I am a product designer and where I work we keep feature requests in a database. (I don’t think we could use a Basecamp list either — it’s not built to support this activity at a large scale). Our database feeds directly into our project tracking tool, and so actual user feedback becomes the kernel around which we add our own internal design and development of the idea. I like having a history of who requested a feature and when. When we are working on a feature, I can contact the users who requested it to get additional feedback and ideas.

So, interesting idea, and it must save time, but the requests are too valuable to throw away, IMO.

— mlc —