12

Very commonly we have feature requests for fields that only one customer wants. This, at best, clutters the application's code. Often when we look in their database a few months after adding the fields, we can see that they are not actually even using the extra fields. Also, it's quite an old application so adding a single field requires multiple code changes, changing reports, and making sure that it doesn't affect other customers who do not need to see the field.

  • How can we make sure that a customer actually needs these feature requests?

  • How do we politely say "you don't really need that"?

Currently we are beginning to charge for certain feature requests. (Previously, feature requests were free usually) Is there anything else we can do?

|improve this question
  • With a lot of grumbling and cursing under my breath >.< Afterall, they are paying me.... – Rachel Jan 6 '12 at 17:12

12 Answers 12

16

Are they paying for the additional features? If so, then it's really not your business whether they are using them or not. Give them what they pay for. If, however, that is not the case, then it's up to your leadership to decide if they are willing to keep adding features at no additional income.

|improve this answer
  • 2
    Well they are paying, but we'd really like to be focusing on larger feature requests that they will end up using(and that may get us more customers in the future) rather than lots of trivial little requests that are just cluttering up the code – Earlz Aug 23 '11 at 19:36
  • 8
    @Earlz - "We'd really like to be focusing on..." - I'm sure you would be that's not how customer relationships work. These small requests (which may add significant value to the customer) are the price you pay for getting to work on the bigger stuff. They need a supplier who responds to their need, not who picks and chooses. The way to deal with it is to price them fairly but to point out that bundling them into larger releases is cost effective (less regression testing and so on) and try and make it more appealing to handle them that way, but you can't pick and choose. – Jon Hopkins Aug 23 '11 at 20:40
  • 2
    If you can cut costs by 50% by losing 5% of customers, it's a good deal, goes conventional wisdom. Are these custom fields really a lot of sweat for little reward? – 9000 Aug 24 '11 at 2:19
  • 5
    There is a poor trend in software development for developers to not want to do what the customer wants, because it isn't cool or fun. We developers tend to put our own happiness before the wants of the customer almost universally. However, its not about our fun and enjoyment. Its about the customer. The customer is the one who pays the bills, you'd better make them happy. If you are in the business of writing customizable software, this is part of the job. – John Kraft Aug 24 '11 at 13:17
  • 3
    @Wayne M thanks for demonstrating the attitude I was referring to. The customers may not understand technology, but they usually are not idiots. It's usually the developer that doesn't understand the business need. Moreover, if adding a feature compromises the integrity of the application, that's a sign of poor application design. – John Kraft Aug 24 '11 at 14:56
3

We have a similar situation. The way we handle is building a trust-based relationship which gives us the liberty to say "you don't need this". It takes time, pacience and you have to be prepared to talk a lot and have lunches and other boring tasks. These boring meetings will pay for themselves in the long term where you can focus on creating really important features.

Talking will also make you see if what they're asking is really that important.

|improve this answer
3

I don't think you can get into the "do you really need it?" arguement with customers. Personally, I'd like to ask, "How will this make your company more money?" but the fact of the matter is, some manager, for some reason wants to track it and they're use to getting their way. If you don't want to do it, say no or charge such a large amount of money to discourage the request.

Start considering ways to make it easier for your application to handle a larger number of customer fields.

  1. Allow labels in reports and forms to be set by the customer to utilize existing fields.
  2. Add generic fields (String12) to existing or additional custom field tables.
  3. Have a user defined field system where this is all handled by data entry and not having to create new columns in tables (I cannot remember what this is called-help.).

You may find that existing customers are out-growing your system. The industry may be shifting so new requirements are popping up.

Sorry, but if you can't offer your customers what they want purely for technical reasons and not profit, you need to pick up the pace. It wouldn't be difficult for a new comer to enter your market with more fields, so don't let that happen.

|improve this answer
3

Looking from the other side of the window for a moment, at my last job I was exposed to an ERP system that allowed "custom" columns to be added by the end user to any entity/table. From my brief interactions with it, it looked like they were dynamically adding the columns to a second table with a one-to-one mapping. For instance:

WIDGET table with static columns:

  • WIDGET_ID
  • WIDGET_NAME
  • WIDGET_COST
  • etc.

WIDGETCUSTOM table with user-definable columns:

  • WIDGET_ID
  • WIDGET_WEIGHT
  • DID_BOB_WORK_ON_WIDGET
  • etc.

The WIDGET_ID column could tie them together. It automatically showed your extra fields when you were editing a widget, and you could include them in dynamic reports, or even search by them. It was fairly efficient because the database could still keep track of them and index those columns if necessary, etc.

From a programming standpoint, I see how that would keep it sane. Every customer can have their own custom columns, but those custom columns don't interfere with your core logic.

|improve this answer
  • This application is too complex to add such functionality without a huge overhaul. So this solution is out (but planned in a major version update that would come in hopefully a year) – Earlz Aug 23 '11 at 20:11
  • 1
    If you can handle this in a year, what's the big deal? – JeffO Aug 23 '11 at 20:14
  • @Jeff a year assuming we don't get bogged down by these feature requests in the mean time.. A year of uninterrupted development time basically – Earlz Aug 23 '11 at 21:21
1

Feature "requests" are just that, requests. If they're making demands then you need to decide how much it is worth to the company to "clutter" the codebase with that. If it becomes an endemic problem then you can clamp down on it, but if they're willing to pay what you're asking or something close to it and it's just a few features here and there, I say go with the money.

To go even further, if this is a constant issue with your product and multiple customers are looking for these sort of customizations, perhaps it's time to rethink these portions of your app and make them flexible in a way that the customers are empowered to do this themselves, be it ad-hoc reporting, flexible data gathering, etc. Try to turn these annoyances into a selling point. "Our stock data model not good enough for you? Check out our customization options! You can do it yourself!"

|improve this answer
  • 2
    Remember, behind every problem is an opportunity to make a solution, and then sell it to someone ;) – MattC Aug 23 '11 at 19:42
0

You should be speccing out exactly what you are going to be doing in said feature and applying an estimated time to build it. If the customer wants additional fields that is fine, bill them for it. I tell my customers that if you want to add features after i've built the feature, that is fine, but it's going to cost a bit more to work them in, in some cases.

I'm having a hard time understanding why you care if they use it or not. It's simple, you build what they want and you get paid for it.

Code base clutter? If you need to refactor your code when working in the new feature charge them for it.

|improve this answer
0

Create a list of several features you consider adding, including adding "just a few extra fields". Show the list to your customers and ask them for feedback on which ones they'd like first. Explain that your resources are limited and that you can't do it all at once. Use the feedback to decide what direction you want to go with your application.

If a customer insists that the few extra fields really are that important and you still decide on not adding them, hopefully the customer can still see the benefit of the features you are implementing instead.

|improve this answer
0

It sounds like you might benefit from some sort of pull system. Let the user choose what feature gets implemented next, but limit the number that can be in development at any given time. A Kanban board is terrific for this. It can give the user ownership of the priortiztion process (aka less responsibility and stress for you). Trust me, if the user is forced to decide which feature gets put into development next, knowing that the other requests will be put aside, they will invest a lot more in really deciding what they need to have.

|improve this answer
  • Kanban methods only work when you can go to the Gemba: the place where problem occurs. Be in the physical space, speak to the people who are doing the work, watch them show you how they do it. See with your eyes, touch with your fingers. Then, and only then, try to figure out how to improve it. And ask them how to improve it. – Christopher Mahan Aug 23 '11 at 21:51
  • @Christopher - point taken, but surely the system could be modified to some extent. Perhaps forget the Kanban, but try to preserve the idea of a pull system. No matter how it works specifically, the user must have some way to prioritize tasks and choose which one gets done next in an environment where development is continuous. A developer has no way to really know what feature needs to get done next on their own. – Morgan Herlocker Aug 24 '11 at 13:07
  • 1
    Ironcode, you're right. I work at Bank of America and our team lets the business unit prioritize the feature requests via bugzilla bug priority. They file the bugs, then prioritize the bugs. They can change the priority anytime, and we adjust. Yes, sometimes it incurs switching costs, but we've found it's more effective for the business. Note that this would probably not work for the original poster, as the management may have goals to those of their customers. (as a lean aside, this management approach seems misguided) – Christopher Mahan Aug 24 '11 at 17:00
0

I think you should ask your customer to put one or more of you through a "day at the office" to see how they really use the software... Wait... Hire me for $250/hour and I will go find out. Also, please, please don't goldplate. Make it just work. Most businesses don't care that it looks ugly when it works well.

|improve this answer
  • We've done this. This is why we know when feature requests probably won't be used. – Earlz Aug 23 '11 at 21:54
  • Ah, well, then there's political fights in the client company. You are screwed. Or you could Steaks and Strippers them. – Christopher Mahan Aug 23 '11 at 21:58
0

Track the requests. As you get to designing/developing the big features, pick a handful of prioritized requests to include in that release.

|improve this answer
0

Build a standard negotiation system for requests. Maybe something based off of a bug-reporting or feature request system, like fogbugz. Allow your customers to place a request, and prioritize it based on:

  • the technical feasibility/cost of the feature
  • is the feature request a "for pay" one? If it's in a contract, and/or they've paid for it, then put it in
  • does the feature "make sense"? This is a bit of an art, but, generally, if enough customers ask for a feature, then implement it for free. It's an opportunity to make your product better, and make the sale to the next customer an easier one
  • do you have unused, paid cycles available? If you include a set of monthly hours for maintenance/support as part of your contracts (I highly recommend you do, even if the number is very low), and they're not getting used, start throwing them at making these kinds of changes
|improve this answer
0

If the customer has total ownership of the application, then do what they ask. Let them blow their money; it's theirs.

However, if you don't then you want to go to a solution for these auxiliary fields that involves storing them outside of the core datamodel. You can then use something like a database view to merge the extra fields back in for this particular customer. (There are a few ways to do the auxiliary store, depending on what the nature of the data being stored is; the simplest is just a table that has the same primary key as some PK in your main table, but that's inefficient when the use of the field is very sparse. It's only truly a problem when they want features of the field that require things like indexing.)

You can also put off the customers' requests saying that you've not got sufficient resources to implement them at this stage. It really helps if at that point you point to your roadmap which says (your best estimate at) when it will become possible to implement what they want cheaply. And you should prioritize getting the application into a state where it becomes possible to support the features cheaply, as that meta-feature becomes a core selling feature of your main application.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.