When you have a product with tens of thousands of subscribed organizations, you receive tens, maybe hundreds of requests for new features… every month! The decision matrix and a formal process to prioritize features are key to wisely decide which functionalities to include in the product.
The balancing dilemma
Achieving a balance is difficult. On one hand, there are the requests of important customers, who have been loyal to the product, and if they ask for it, it is because they really need it. On the other hand, we must ensure to keep the product as simple to use as possible, giving priority to those features that have a great impact, that are intuitive, and that constitute a differential.
In this article, we try to address these challenges providing a really simple mechanism, yet very effective and immediately useful.
The feature request form
In order to manage requests for new features in a professional manner and always keeping the needs of our customers at the center, we built a formal process. And we automate it in Flokzu, of course.
The first element to automate this process is building the process form. In this form, we set-up all the fields we need to identify the feature, who has requested it, who has to be notified about it. And we also set-up the decision matrix. The following image shows part of the process form.
The Decision Matrix Section
This is the most interesting section of this form. We introduce values in fields for several dimensions and the form will calculate the relevance of the feature. It will consider the value that the feature adds to the business and the complexity of building it.
The “Business Value Subtotal” is a metric that shows how much value this feature adds to the business. It is calculated as the average of the following fields:
- Customer benefit
- Opportunity size
- Competitive positioning
- Strategic alignment
- Customer satisfaction
Each field should be completed with a natural number from 1 to 5. It is easy to fill the form, and the result is pretty easy to interpret too.
Ok, this is great. But… on the other hand, you need to take into consideration the complexity. You can seize the Complexity Subtotal, as the average of:
- The complexity of the software development
- The complexity of the deployment into production
Then, Decision Matrix Total = Business Value Subtotal – Complexity Subtotal
Please note that we use an arithmetic average, but it could also be a weighted average. You just need to assign a weight to each field and consider it when calculating Business Value Subtotal and Complexity Subtotal.
Decision matrix documentation
Of course, you might be thinking that the values that you put in the fields are subjective. Mmmm… yes. They are, but you can use the following guideline to make them much more objective:
The feature request process
Besides the decision matrix, you will need a process, in order to track every feature request. Using this process you can be confident that none feature request is lost. And most important, the customer always receives an answer, even if it is rejected.
In fact, in case of rejection, the BPMN engine will send an email to the customer (notification email field in the process form). This is done using a send task in the BPMN diagram. Of course, if the feature is accepted and goes into production, the customer will also be notified.
Once you deploy this process (form + workflow), you will have an effective tool to receive, analyze, prioritize, and respond to your customer’s feature requests in a timely and professional manner.
Or schedule here a 30 minutes session to see how you can improve and prioritize feature request using a decision matrix, in just minutes.
