A feature factory is a team measured on how much it ships rather than on what changed after it shipped.
The phrase gets used as an insult and it works better as a diagnosis. Almost nobody sets out to build one. You get one by picking a number to report upward, reporting it every month, and discovering two years later that the number was the only thing anybody was optimising.
What is a feature factory?
A feature factory is an organisation where output is the measurement and outcome is an anecdote.
Output is things done. Releases shipped, tickets closed, features launched, requests cleared. All of those are real, all of them are countable on a Friday, and none of them says whether anything got better for anybody.
Outcome is the change afterwards. A task that used to take twenty minutes takes two. The support queue for one topic empties. People who were leaving stop.
Those are the things the work was for, and they share one awkward property, which is that they are slow, noisy and hard to attribute. So they lose to the countable ones, every time, in every reporting cycle, without anybody deciding they should.
That is the whole mechanism. It is what happens when one kind of number is available weekly rather than cynicism or laziness, because the other kind and the other kind is not available at all.
VoteFirst does this part on a board, and the demo is open without an account.
How is that different from shipping a lot?
Shipping a lot is good. Being measured only on shipping a lot is the problem, and the two look identical from outside for about a year.
The distinguishing question is what happens to a shipped thing afterwards. In a healthy team a feature has an expected effect, somebody checks whether it arrived, and the answer sometimes changes what happens next.
In a factory, shipping is the terminal event. The item moves to the shipped column, the column is the report, and nobody returns to it unless it breaks.
The second tell is what a failure looks like. If a feature nobody used is remembered as delivered on time, the measurement is output. If it is remembered as the one that did not work, there is an outcome somewhere in the process, even an informal one.
Is a vote count an output metric?
Yes.
A vote count measures how many people asked. It does not measure whether building the thing helped them, and there is no version of a voting board that can, because the board stops watching at the moment the card moves to shipped.
A request with the most votes is the most requested request. That is all it has ever been.
This matters more than it sounds, because a vote count is unusually convincing. It has a number, it is sorted, it comes from real customers, and it can be put on a slide.
A metric with those four properties will beat a better metric that has none of them, which is exactly the mechanism described above wearing a friendlier face. The better metric usually has a name, and a north star metric is the one most teams reach for when they go looking for it. Whichever board keeps producing the count in the meantime, thirty two feature request tools and the eight ways each one gets billed is where to see what it actually costs to keep counting.
What is VoteFirst's own score made of, exactly?
VoteFirst's own score is made of three activity counts and nothing else; here is the formula rather than a description of it.
The demand score on a request is the votes multiplied by three, plus the comments multiplied by two, plus the views multiplied by a tenth. When you set an effort estimate, priority is that demand divided by that effort.
Read the three terms. Votes, comments, views. Every one of them counts an action somebody took before you built anything, and not one of them can move after you ship.
VoteFirst's own priority number is an output metric with an effort guess divided into it, and calling it demand does not change what it is made of. The full formula and the three places it misleads are written out separately.
The defence for it is narrow. Weighting a vote by what the person casting it pays you at least replaces one popularity count with something connected to the business, which is why it exists at all. It is still a count of asks rather than a measure of results.
What would an outcome actually look like on a board?
Four things, and a board shows you none of them, VoteFirst's included.
The workaround disappearing. If people were exporting a spreadsheet every month to get around a gap, the honest test of the fix is whether they stopped, and that lives in your own product analytics rather than on any feedback tool.
The request not being filed again. A shipped feature that keeps attracting near duplicates six months later did not solve the problem it was named after. This one is at least visible on a board if you go looking, and almost nobody goes looking.
The support volume on that topic falling. Also yours to measure, in a different system, and it is the fastest of the four to check.
Whether the people who asked ever used it. This is the one that would be most useful and it is the furthest from what a feedback tool knows.
A board can tell you who asked. It cannot tell you what they did afterwards, and any tool claiming otherwise is describing an integration rather than a board.
Why do companies become feature factories?
Because output is the only thing that is easy to count.
A shipped feature has a date and a name. An outcome has neither for months, and by the time it arrives the team has shipped forty more things and nobody can say which of them moved it. So the countable thing takes over the review, then the roadmap, then the hiring plan.
The second reason is a request queue with no rule behind it. Without something that decides what gets built and what gets refused, the loudest account sets the order, and a team that says yes to everything is a factory whatever it calls itself. Saying no in public is the uncomfortable half of that.
How do you tell if you are in one?
Three questions, and they are uncomfortable in a specific way.
Ask what the last feature was supposed to change, and see whether anyone can answer in a sentence with a number in it. Not what it was, what it was supposed to change.
Ask when anybody last decided a shipped feature had not worked and did something about it. If the answer is that it has not happened, that is not a record of consistent success.
Ask what would have to be true for the team to build nothing new for a quarter and consider it a good quarter. If there is no version of that sentence that is sayable out loud, the measurement is output and everything else is decoration.
Where VoteFirst sits
This is a board that produces a sorted list of asks, and a sorted list of asks is an output metric.
What the board is genuinely good at is stopping you build the wrong thing, which is a different job from telling you whether the right thing worked.
It shows the size of a request before you commit, it collapses six descriptions of one problem into one row, and it gives a refusal a public place to sit with a reason attached. Those save you the work rather than measuring it.
The measuring is still yours, and what it would mean to measure it is written up as feature adoption. The board and the roadmap are one page at nine dollars a month, and a card is required for the fourteen day trial.
14 days, a card at signup, then $9 or $39 a month.