How We Rate Your Feature Requests

Quality Comes First

In order to evaluate the ideas and requests in a fair way, we decided on some root principles so you and our other customers can profit from our development in the best possible way.

The first principle is what we call "quality beats feature": Before we consider creating new features, we always fix known problems first. Maintaining the reliability and stability of our software is the vital first step before considering any new features.

Bang for the Buck

For all feature requests we developed a "formula" which enables us to estimate the best possible priorities, so we can make as many of our customers as possible happy, while using reasonable resources. Our "formula" also takes into account how often we receive a certain request. This, again, shows how important it is that you bring in your ideas, so we know what's important for you.

We evaluate each and every item on our wish list according to four metrics:

• Affected Users: How many of our license-holding customers will benefit from the new feature? How many have asked for it?
• „Boah Effect": How likely is it that those users will be impressed, happy, or relieved by this new feature?
• „Annoyance² Factor": How much pain would it be to the affected users to _not_ have this new feature? This value is used squared in the following calculations, so a truly annoying problem is much more important than any nice-to-have „boah effect" item
• Developer Days: How many days are needed to research, create, develop, test, and document the feature?

With these four variables we calculate a new metric, the „bang for the buck":

bang_for_buck = ( users * ( 1 + boah ) * ( 1 + annoyance )² ) / devdays

We think this is the fairest way to work out the best value that your suggestion can bring.

Our List

Using the formula gives us a list that we can sort by "bang for the buck." That helps a lot when coming up with a new roadmap. How ever, we don't completely rely on math to do the job. In the end we work through the list one by one and overrule decisions made by our formula where necessary.

Lastly, there are some feature requests that we simply do not want to explore. We have a clear vision of PRTG. We want to keep it very simple to operate, yet very powerful and extendable in daily use. So there are ideas that simply do not fit into our long-term strategy for PRTG.

Sample Calculations

• If we think of a feature that affects 100% of our users, has a boah effect of 100%, has an annoyance factor² of 100% and can be created in 1 developer day: This reaches the maximum value of 800. Unfortunately no feature of such greatness has ever been so easy to implement.
• Or think of a problem that affects half of our users (users=50%), with a medium annoyance (50%) and can be fixed in 2 developer days: The bang for the buck is 56.

 Eventually, all of these considerations result in the roadmap of PRTG which determines the direction that we take with our software. I will talk more about our roadmap in the next blog post.

The Complete Series

At Paessler, we have developed a culture of listening to our customers. We put our best efforts into constantly improving on our products, so you get the most out of them. We appreciate your feedback and want to give you an insight into how we go about producing our product roadmap. We evaluate each and every one of your suggestions and combine them with our own ideas to develop the best solution for all and provide maximum value.

Read the other posts of this series:

• Company Culture Part 1: Your Feedback is Highly Appreciated!
• Company Culture Part 2: How We Rate Your Feature Requests
• Company Culture Part 3: The Paessler Roadmap