Why We Credit Users by Name in the Development Queue

There is a small line of text under almost every shipped feature in the Baseline Maps Development Queue. It says who asked for it. A first name, sometimes a last initial, sometimes a town. It is the most opinionated design decision we have made, and almost nobody notices it on first read. That is fine. The people it is for notice immediately, and they are the only people it has to reach.

The phrase “customer feedback” and why we don’t use it

“Customer feedback” is a phrase invented by people who have never met a customer. It flattens a specific person with a specific problem into a data point that can be aggregated, prioritized, and ignored. We do not say it inside the company and we do not say it in the app. There are users, and there are requests, and there are names. The language we use about people is the language we end up treating them with, and the abstraction begins the moment you rename them.

What a credited ship feels like

A ship note in our Development Queue is two lines. The feature, and the person. “Wind gust overlay on the river forecast — requested by Marcus in Coeur d’Alene.” That is the entire entry. It takes the engineer eight seconds to write. For the user who sent the request three weeks earlier, opening the app and finding their name there is something they will tell other people about. They become a small permanent part of the product, and they will keep checking back.

The social contract a credit creates

A credited ship is a public receipt. It says: a person outside this company sent us a sentence, and the sentence became a feature, and the feature became a thing you can use, and here is the person. It rewrites the unspoken deal between a small app and its users. The deal stops being “submit feedback into the void” and becomes “ask, and the asking is part of the record.” Every future request is sent under that contract.

The opt-in default (and why it matters)

The visible credit is opt-in, not opt-out. The submission flow asks three questions: name on ship, anonymous, or private notification only. The default is private. Most users pick visible, but the ones who do not are protected by default rather than by complaint. The opt-in matters because a credit is a gift, and a gift you cannot refuse is not a gift. It is a marketing asset wearing a friendly hat, and users can smell the difference.

What we credit (and what we don’t)

We credit features that came from a specific request. We do not credit bug fixes, because a bug is a thing we should have caught and the user is doing us a favor by reporting it, not earning a place on the wall. We do not credit features that were already queued before the request arrived, even if the request matched. The bar is: would this exist, in this form, on this timeline, if this person had not written in? If yes, the name goes on. If no, no.

Where this idea came from

It came from open-source contributor lists, museum donor walls, and the credits at the end of a film. None of those are products. All of them understand that the people who made a thing possible deserve to be named in the thing itself. Software has spent twenty years pretending users are a faceless aggregate because faceless aggregates are easier to A/B test and easier to disappoint. We are choosing the older tradition. The one with names.

How it scales

The question we get is whether this works at a hundred thousand users. The answer is that it scales with hiring, not with users. Most users never send a request. The ones who do, we already read every word from. Writing one line of credit when a feature ships is a rounding error on the engineer’s day, smaller than the time it takes to draft a release tweet. If we ever reach a scale where naming people feels like overhead, we will have lost the thread.

The cost of not crediting

The cost of not crediting is that you build a product that feels like it descended from a corporate boardroom rather than one that grew out of conversations with real people. Users still benefit from the features. They just do not know where the features came from, and so they do not know that they could be the source of the next one. The silence trains them to stay silent. Then you wonder why nobody sends requests anymore, and you start running surveys.

A credited ship is also a hedge against drift. When the team can see, in the same list, that the last twelve features each came from a named human who needed them, it becomes very hard to spend the thirteenth slot on something nobody asked for. The Development Queue becomes a forcing function for staying close to the ground. It is harder to build the wrong thing when the right thing is in front of you with someone’s name on it, waiting.

The other cost is what happens inside the company. A team that ships anonymously starts to think of itself as the source of the product. A team that credits users every time it ships is constantly reminded that the product is a conversation, and the team is one half of it. That posture is hard to fake and easy to lose. The credit line is how we keep it. It is a daily check against the slow drift toward thinking we know better than the people using the thing.

We have shipped features for guides in Yakima, for steelheaders in Forks, for a contractor in Boise who needed lake bathymetry on a specific reservoir, for a hunter in eastern Oregon who wanted controlled-hunt boundaries clearer at zoom level eight, for a forager in the Olympics who wanted a soil-temperature trigger that nobody else was asking about. None of those names made the product better in any technical sense. All of those names made the product better in every sense that matters. People who read the Queue see the names and write in. People who write in see the names and trust us with the next request. The loop closes itself.

There is one more thing the credit does, and it is the thing we did not plan on. It makes the team braver about shipping small. A feature that helps eleven users does not feel like a waste of a sprint when the eleven users are named under it. The credit reframes scope. It is permission to do work that would not survive a portfolio review at a larger company, because the eleven names are themselves the justification. The named user is the unit of value, and once you adopt that unit, the spreadsheet stops mattering.

We have also noticed the credit changes how requests arrive. Users who have seen a credited ship write more carefully. They explain where they fish, what gear they run, what time of year they are out, what the gap in the map costs them. The signal-to-noise on the inbound channel improves because the senders know a named human will read it and write back. None of that was the goal when we started. It was the dividend.

The credit is also, quietly, our entire community page. We do not have a forum. We do not have a Discord. We do not have a feature voting site with upvote counts and stale threads from two years ago. We have the Development Queue, and the Queue has names, and the names are what people scroll. New users open it before they buy. They are not looking for a feature list. They are looking for evidence that the people running this thing know who is using it. The names are the evidence.

Open the Development Queue. Every ship has a name beside it. That’s the model.