Key Questions to Answer Before Adding A Feature to Niche Software

A niche software supplier provides expertise and functionality that individual firms in an industry would find more expensive to develop on their own. Managing the feature content and evolution of the feature set requires that a reasonable fraction (for example at least 30-40%) of the customer base needs the feature so that they feel they are getting their money’s worth out of a monthly or annual software subscription. Here is a checklist that one of our customers, DataCare, uses to evaluate new feature requests.

Key Questions to Answer Before Adding A Feature to Niche Software

1. Please describe only the functional aspect of the Feature Request. (What would you like the system to do?)
2. Explain the reason for this request: what is the problem you trying to solve?
3. Have you explored alternative workflows available from DataCare on how to solve?
4. Is this request due to a change affecting the industry (e.g. new regulations or laws, new accounting or billing practices, a court ruling or new interpretation of regulations)?  industry requirement or change? If so please describe.
5. What are the specific consequences of not having this feature? (lost time, lost revenue, state compliance etc.)
   1. Are you anticipating a future requirement due to pending changes in regulation or legislation?
   2. Are you anticipating a future requirement due to a change in your business operation (e.g. operating in a new jurisdiction or a new line of business)?
6. What specific users are being affected and how many users?
7. How long has the lack of the feature you are requesting been an issue?
8. Will other customers be able to utilize this functionality? Please outline briefly some aspects of their operation that would mean they are likely to benefit.

These questions can be answered directly by the customer or as the result of an interview with sales or customer support.

Six Ways to Address a Feature Request

You have six broad dispositions for a feature request:

1. Help the customer solve the problem with your current version of software. Determine if changes in configuration of the existing product can satisfy their need, or if a training issue exists that may be causing the problem.
   Risk: if this really represents a need that would be better addressed by changing code this may just be phase 1 of a two phase process involving options 2,3, or 4 below.
2. Agree to include it in the basic release. Provide a time table for when the customer can expect to start evaluating or using it. This may also involve informal or formal conversations with enough customers–and prospects–to satisfy yourself there is enough demand to justify inclusion.
   Risk: you invest resource in a feature that is not widely used such that it does not increase customer satisfaction, customer retention, or encourage prospects to purchase. You lose the opportunity cost of the development effort on other features that would increase satisfaction, retention and improve win rate.
3. Offer it as an extra cost option to the requesting customer and other customers in your installed base. Provide a time table for when the customer can expect to start evaluating or using it–after they provide a purchase order. This may also involve you canvassing other customers to assess the level of demand or need.
   Risks are two fold: (1) very few or only the requesting customer pays so that this should have been structured as private feature or a no; (2) this is a basic feature that will be widely used and you will actually decrease customer satisfaction and retention because you product is viewed as unnecessarily expensive.
4. Offer it as a private feature at extra cost only available to the requesting customer. Develop a detailed statement of work and timetable for joint testing so that the customer can signoff on the plan.
   Risk: you have to recoup the opportunity cost of your development for other features that can drive general product adoption and retention; you also risk becoming more of a consulting or contract development shop if more than 10-20% of your revenue is coming from “specials” and you see new customer sign-ups slow or renewals drop.
5. Say no. Explain to the customer it’s off strategy and would require extensive modification to your architecture such that option 4.
   Risks are two fold: (1) you have mis-assessed and this should be a basic feature or extra cost option in which case you risk general customer satisfaction and competitiveness for new business; (2) this should have been offered as a private feature and you lose the requesting customer.
6. Say maybe. This can take various forms: we have not yet prioritized your request (if this takes longer than a few weeks something is wrong); we will re-evaluate in several months (it’s better to say no now and have the detailed discussion). This is always the worst option because it leads to a large feature backlog without a strong connection to customer interest or willingness to pay.

I am Indebted to Alex Atkins at DataCare

I am indebted to Alex Atkins at DataCare for permission to adapt his original set of 8 questions for this article. Primary changes were to generalize medical and workers compensation terminology appropriate to their niche software to make it more general. I thought his perspective as VP of Sales for a niche software player was valuable and worth sharing.

Related Blog Posts

• Distant Early Warning Signs of Market Disruption
• Write Down Key Commitments And Questions That Need Answers
• Extracting Insights From A Competitor’s Software Demo It’s a good idea to keep an eye on competitor’s feature content as they may often be the source of new feature requests.
• Tom Van Vleck’s “3 Questions” Complement Root Cause Analysis
• 21 Great Questions for Developing New Products
• First Seven Questions Any Product Plan Should Answer

Photo Credit: “Steel Grate” © James Lough; used with permission