The short version
- Internal feedback comes from people who work on the product, not people who pay for it.
- It outvotes customers for four reasons, none of them a decision anybody made.
- It's good for support patterns and bad for deciding what to build next.
- Separate the queue, or at least the label, because internal people write better sentences.
Internal feedback is what people inside your own company say about the product. It arrives faster than customer feedback, in greater volume, from people who are better at describing software, and it's not evidence of demand.
The accident in the title is that nobody decides internal input should outweigh customers. It just does, because of who is in the room.
What is internal feedback?
Anything said about the product by somebody who works on it or sells it, rather than by somebody who pays for it.
Three sources produce almost all of it. The people who build it and notice everything broken, the people who sell it and hear objections, and the people who support it and answer the same question forty times.
Each of those is worth having, and each is worth a different amount.
There's a board with real requests on it if you want to see the difference between the two kinds, and the demo is open without an account.
Want the counting done for you? Twenty eight feedback tools, the price and the unit each one bills on, read on one day.
Why does it outvote customers?
Four reasons, none of them a decision anybody made.
| The reason | What it does |
|---|---|
| Availability | Internal people are in the room. A customer has to be asked |
| Fluency | They describe software well, so their requests sound more buildable |
| Repetition | They are present for every prioritisation conversation, so their item comes up every time |
| Authority | Some of them can simply ask, and asking is not a queue |
Put those together and internal items reach the top of a list without ever having been compared to a customer item on the same axis. That's the whole failure, and it's structural, not anybody's fault.
What internal feedback is genuinely good for
Support patterns. Somebody who has answered the same question forty times has a count the rest of the team doesn't. That's not an opinion, it's a measurement, and it's the most valuable input on this page.
Sales objections. The thing that stopped four deals is real information about what the product is missing, as long as the four deals are named. A remembered pattern isn't.
Things that are broken. An engineer noticing that a screen is wrong needs no customer to confirm it. Bugs aren't a demand question.
Speed. Internal input arrives today. That's worth something in a week where you need to decide by Friday.
What it is not good for
Deciding what to build next, on its own.
The reason is narrow and it's worth stating precisely. Internal people can tell you what's wrong with the product, and they can't tell you how many customers care. Those are two different questions and only the second one orders a roadmap.
How to keep it from drowning the customers
Separate the queue, or at least the label. Internal items and customer items in one undifferentiated list will be ranked against each other by how good the sentence is, and internal people write better sentences.
Make relayed items name their source. "Sales says enterprise accounts want single sign on" becomes useful the moment it reads "three accounts asked, here's which three". If the names can't be produced, the item is a hypothesis.
Give customers a way to agree without being asked. This is the structural fix and the only one that works over time. A request list customers can reach on their own accumulates counts between meetings, so by the time a prioritisation conversation happens there's something on the customer side of the scale.
Count the queue by weight, not by voice. A request with four paying accounts behind it and a request with one enthusiastic colleague behind it should not look the same in a list.
The internal request that is actually a customer request
The most useful thing anybody inside the company can do with a request is put the customer's own words on it.
A support person who files the request with the three ticket quotes attached has turned an opinion into evidence. The same person filing "customers find the export confusing" has filed a summary, and the summary is the version that loses the argument in six weeks when nobody can remember which customers.
How do you do this without a tool?
Two lists, or one list with a column saying who asked. Internal items go in with a name attached, customer items go in with the customer attached, and the ordering conversation reads the column.
What a document can't do is let the customers add themselves to an item, which means the customer side of your scale only ever contains what you personally remembered to write down.
How does this product do it?
Requests live on a board that can be public, so customers add and agree with their own. Each voter carries whatever you know about them, including the revenue on the account, and the weighted count sits beside the plain headcount so the two can be read against each other, not one replacing the other.
Your own team can file on a customer's behalf, and nothing a visitor writes appears publicly until somebody approves it, so an open board doesn't become a wall.
The revenue weighted voting page covers the weighting, and client feedback examples covers the other half of this problem.
The types of user feedback puts internal feedback beside the eight external kinds.
14 days, a card at signup, then $9 or $39 a month.
