Four numbers about one request. Nothing is sent anywhere.
- Worth a month when they asked
- –
- Gone, a month
- –
- Gone, a year
- –
- Still paying, still waiting
- –
Askers times price is what the request was worth. Leavers times price is what has gone, times twelve for the year. The rest is what is still there to keep. No rate, no model, no benchmark.
Does this prove they left because you did not build it?
No, and a calculator that hands you a savings figure is quietly claiming it does.
People leave for reasons that have nothing to do with your roadmap. Read this number as a ceiling: the most the request could have cost you, with the truth somewhere between that and nothing.
What it is good for is comparison. Run it on two requests. If one is carried by customers who have mostly left and the other by customers who are all still here, those two are not tied whatever their vote counts say.
How do you read the four numbers it gives back?
Left to right, they answer a different question each, and the fourth is the one worth acting on.
Worth a month when they asked is the whole group at the moment they told you. It is the size of the thing you were deciding about, and it is the number people quote when they want the request built.
Gone, a month is the part of that group which is no longer paying you. It is the only figure here made of events that actually happened rather than of what might.
Gone, a year is the same figure times twelve. It is included because a monthly number is easy to shrug at and the annual one usually is not, and because a subscription lost in January is twelve payments missing by December rather than one.
Still paying, still waiting is the number to act on. The first three are about a decision already made. This one is the revenue still in the building, still asking for the same thing, and still reachable.
What counts as churn here, and what does not?
A customer who stopped paying you altogether. Nothing else, and the limit is deliberate.
A customer who moved from a large plan to a small one has cost you real revenue and has not churned. Counting them here would mix two different events, and the fix for a downgrade is usually not the fix for a cancellation. If you want to count the money rather than the people, put the lost monthly amount in as a number of average customers and the arithmetic still holds.
A customer whose card failed and who came back the following week has not churned either, whatever your billing system recorded in between. Involuntary churn is a payments problem and it is not evidence about your roadmap.
The definition, and the two ways this figure is usually reported, is on its own page, because the word covers two measurements that answer to the same name.
Which requests is this worth running on?
Three, and there is no value in running it on the rest.
The ones at the top of your board by plain vote count. That is where the argument happens, and this is the number that decides whether the top card and the third card are actually in the same class.
The ones you already declined. Running it on a request you turned down is the uncomfortable version and the useful one. If the group behind it has mostly left, you have learned something about the decision rather than about the request.
The ones carried by few voters. A request with six voters looks unimportant beside one with sixty until you see what the six pay. That gap is the entire argument for weighting a vote by what the customer pays, and this calculator is the version of it you can run before changing anything.
Run it on two requests before you read either number on its own. A figure with nothing to compare it against invites you to decide what it means.
Where do the numbers come from?
Your billing system, and whatever holds your requests.
On a board that knows who pays, the first two are already on the request: the voter list names everybody who voted, with what each pays on their own row. The third one, who has since churned, is the awkward one, and the API answers it in a single call.