3 added 255 characters in body
source | link

For each of our products, we have a "list of ideas for future versions". So what we tell our users is "we will put your suggestion on that list" - and that is honest, we actually do that.

The list has no priorities, but we regularly pick things from it and use them to feed our backlog. We do not take them "in order", instead we try to identify which ideas give the "most bang for the buck" - the most benefit for as many of our users as possible, for a reasonable development effort.

Feature requests against the conceptual integrity of the product are likely to stay there forever. But occasionally, it happens that at least some of the ideas buried in those feature requests can be realized, maybe not exactly the way the person who suggested it was thinking of, but in a way which fits better into the product's architecture.

So my suggestion here is: do not just say "We will take that into consideration." and forget the idea as soon as you end up the phone call. Instead, have a tool where you store ideas and feature requests, maybe in an issue tracker, maybe in a Wiki, maybe in a spreadsheet, whatever suits your needs best.

For each of our products, we have a "list of ideas for future versions". So what we tell our users is "we will put your suggestion on that list" - and that is honest, we actually do that.

The list has no priorities, but we regularly pick things from it and use them to feed our backlog. We do not take them "in order", instead we try to identify which ideas give the "most bang for the buck" - the most benefit for as many of our users as possible, for a reasonable development effort.

Feature requests against the conceptual integrity of the product are likely to stay there forever. But occasionally, it happens that at least some of the ideas buried in those feature requests can be realized, maybe not exactly the way the person who suggested it was thinking of, but in a way which fits better into the product's architecture.

For each of our products, we have a "list of ideas for future versions". So what we tell our users is "we will put your suggestion on that list" - and that is honest, we actually do that.

The list has no priorities, but we regularly pick things from it and use them to feed our backlog. We do not take them "in order", instead we try to identify which ideas give the "most bang for the buck" - the most benefit for as many of our users as possible, for a reasonable development effort.

Feature requests against the conceptual integrity of the product are likely to stay there forever. But occasionally, it happens that at least some of the ideas buried in those feature requests can be realized, maybe not exactly the way the person who suggested it was thinking of, but in a way which fits better into the product's architecture.

So my suggestion here is: do not just say "We will take that into consideration." and forget the idea as soon as you end up the phone call. Instead, have a tool where you store ideas and feature requests, maybe in an issue tracker, maybe in a Wiki, maybe in a spreadsheet, whatever suits your needs best.

2 added 255 characters in body
source | link

For each of our products, we have a "list of ideas for future versions". So what we tell our users is "we will put your suggestion on that list" - and that is honest, we actually do that.

The list has no priorities, but we regularly pick things from it and use them to feed our backlog. We do not take them "in order", instead we try to identify which ideas give the "most bang for the buck" - the most benefit for as many of our users as possible, for a reasonable development effort. 

Feature requests against the conceptual integrity of the product are likely to stay there forever. But occasionally, it happens that at least some of the ideas buried in those feature requests can be realized, maybe not exactly the way the person who suggested it was thinking of, but in a way which fits better into the product's architecture.

For each of our products, we have a "list of ideas for future versions". So what we tell our users is "we will put your suggestion on that list" - and that is honest, we actually do that.

The list has no priorities, but we regularly pick things from it and use them to feed our backlog. We do not take them "in order", instead we try to identify which ideas give the "most bang for the buck" - the most benefit for as many of our users as possible, for a reasonable development effort. Feature requests against the conceptual integrity of the product are likely to stay there forever.

For each of our products, we have a "list of ideas for future versions". So what we tell our users is "we will put your suggestion on that list" - and that is honest, we actually do that.

The list has no priorities, but we regularly pick things from it and use them to feed our backlog. We do not take them "in order", instead we try to identify which ideas give the "most bang for the buck" - the most benefit for as many of our users as possible, for a reasonable development effort. 

Feature requests against the conceptual integrity of the product are likely to stay there forever. But occasionally, it happens that at least some of the ideas buried in those feature requests can be realized, maybe not exactly the way the person who suggested it was thinking of, but in a way which fits better into the product's architecture.

1
source | link

For each of our products, we have a "list of ideas for future versions". So what we tell our users is "we will put your suggestion on that list" - and that is honest, we actually do that.

The list has no priorities, but we regularly pick things from it and use them to feed our backlog. We do not take them "in order", instead we try to identify which ideas give the "most bang for the buck" - the most benefit for as many of our users as possible, for a reasonable development effort. Feature requests against the conceptual integrity of the product are likely to stay there forever.