How We Decide What to Ship Next (The Actual Process)

Most product teams have two versions of how they decide what to ship: the version on the slide deck and the version that actually runs the company. The slide-deck version has matrices, scoring rubrics, and a quarterly cadence. The real version is usually one person, a feedback inbox, and a quiet conversation about what hurts most this week.

We don’t have a slide-deck version, because there’s nobody to show it to. What follows is the real one — the process that turns a request from a user standing in a parking lot at dawn into a feature shipped to everyone two weeks later. No theater. No invented rigor. Just the loop.

The daily read

Every morning, somebody on the team reads the feedback queue. Not skims — reads. Every message that came in overnight, in full, in order. It takes twenty to forty minutes depending on volume, and it’s the most important meeting we don’t have. The daily read is where emergency rule notifications first surfaced — three messages in a single morning, all about the same closure nobody saw coming. You can’t catch that pattern weekly.

The weekly cluster

Once a week, the messages from the past seven days get clustered by theme on a single page. Not a database — a page. Hatchery alerts started as four separate requests across a week that all named different rivers but wanted the same thing: tell me when fish were released near me. Clustered, they became one feature. Read individually, they would have been four small “maybe later” notes drifting to the bottom of the list.

Three questions, no spreadsheets

For each cluster, three questions. Who specifically needs this? How many other users will it help once it exists? How long will it take to build the smallest useful version? That’s the entire framework. The Celsius readout took an afternoon and helped a small but real set of users, so it shipped fast. A full unit-preferences overhaul would have taken a month and helped roughly the same group, so it didn’t. The math is usually that obvious once you write it down in plain words.

When user requests collide with team plans

Sometimes the queue says one thing and the team wants to build another. The CFS-to-gauge-feet toggle is a good example — it wasn’t on any plan, it interrupted a different piece of work, and it shipped in two days because the request was specific and the friction was real. The rule we use is simple: if a user request beats a team plan on all three questions, the user request wins that week. The team plan moves to next week. Nobody loses face because there’s no face to lose.

How we say no

Saying no is mostly saying “not now.” A direct no is rare and reserved for things outside scope — social feeds, leaderboards, friend-tracking. For everything else, the reply is a paragraph that says where the request sits in the queue and why. Adding the Niagara River was technically a “no” the first time it came up because the data wasn’t there yet. Two weeks later the data appeared and the river shipped. The requester got both replies. Saying no in detail is more work than saying yes vaguely, and it’s the work that keeps the loop honest.

The infrastructure-work problem

Not every shipped feature comes from a user request. Some weeks the most important work is something nobody asked for — a security patch, a payment fix, an under-the-hood rewrite that prevents an outage. These compete with user requests in the same queue, with the same three questions applied. The turbidity read shipped in the same two-week window as a quiet infrastructure rebuild that nobody saw and everyone benefited from. Users see both in the Development Queue, labeled honestly. The feedback we get on the under-the-hood items is almost always positive — people respect the trade when it’s named out loud.

What two weeks of shipping looks like

A representative fortnight: one user-requested feature shipped (the gauge-feet toggle), one clustered feature shipped (hatchery alerts), one quiet infrastructure improvement shipped, two bugs fixed within hours of being reported, one new river added to the catalog, and one larger feature scoped but not yet started. That’s roughly the cadence — six to eight things moving from “request” to “shipped” every two weeks, most of them small, one or two of them meaningful. The cadence holds because the loop is short, not because anyone is grinding.

Where the process breaks (and what we do)

It breaks when a request looks small but isn’t. The first version of emergency rule notifications shipped without proper regional filtering and produced noise for users far from the actual closure. We had to pull part of it, rework the filtering, and reship a week later. The process also breaks when we cluster too eagerly — three requests that look related but actually want three different things. We catch it now by going back to the requesters before scoping, asking the clarifying question, and waiting for the answer before writing anything. The fix for a broken process isn’t a heavier process. It’s a slower first pass and a faster second one.

The whole thing is unromantic on purpose. A scoring framework would let us defend any decision with a number, but the number would be invented and we’d know it. A committee would let us share blame when something didn’t land, but the blame would slow the next decision. A quarterly roadmap would let us announce things to the world, but the announcements would constrain us when the queue surprised us — and the queue always surprises us.

What we have instead is a loop short enough that nobody needs to defend anything for very long. If we ship the wrong thing this week, we’ll know by next week, and we’ll fix it the week after. The cost of being wrong is low because the cost of changing course is low. That’s the actual prioritization framework: keep the loop short enough that being wrong is cheap.

The other thing worth saying is that we don’t pretend the process is finished. The clustering step is newer than the daily read. The infrastructure-work labeling is newer than the clustering. Each piece showed up because something broke and we needed a small change to keep the loop honest. We expect more changes. The shape we just described is the shape today — not the shape forever.

People sometimes ask whether this scales. The honest answer is the same one we give about everything else: we’ll find out, and when it stops working we’ll change it in public. For now, the queue is manageable, the cadence holds, and the people who send requests usually hear back within a day, sometimes within an hour. That’s the bar. As long as it stays the bar, the process is doing its job.

The deeper reason the loop works is that the team reads requests as language, not data. A user writing “the gauge number doesn’t match what the sign at the bridge says” is not a feature request — it’s a clue. The actual request, two clarifying replies later, was the gauge-feet toggle. A user writing “I keep missing the windows” is not a bug report — it’s a clue. The actual request, two replies later, was hatchery alerts. The clustering and the three questions only work because somebody upstream took the time to figure out what each message actually meant. Skip that step and the whole thing turns into spreadsheet work, which is the failure mode of every prioritization framework we’ve ever seen.

One more thing worth naming: we ship features the way we ship updates to a paper map — slowly enough to be sure, fast enough that the map still matches the river. A new river added today should reflect the river as it is today, not as it was a quarter ago. Our two-week cadence is the slowest cadence that still lets the map stay current. Anything slower and the app drifts out of sync with the world it’s describing. Anything faster and we ship sloppy work. Two weeks is the speed of the rivers, more or less, and it’s the speed we hold to.

If you want to influence what’s next, send the voice memo. The Development Queue is in-app — it shows the answer to the three questions, in public.