The Case for a Feedback Box Over a Roadmap Committee

Most companies decide what to build through a roadmap committee. A handful of product managers, a few engineering leads, sometimes a designer, sometimes a marketing representative, all gathered in a recurring meeting where ideas are ranked, defended, deprioritized, and eventually compressed into a quarterly slide. The output is a deck. The deck gets presented. The deck rarely matches what ships, and by the time anyone notices the gap, the next planning cycle has already started and a fresh deck is being assembled to paper over the last one.

Baseline Maps doesn’t work that way. We have an in-app feedback box, a daily triage habit, and a public Development Queue users can read whenever they want. There is no committee. There is no quarterly planning ritual. There is no slide deck. We think this is the better way, and we want to explain why — because every time we tell another founder how we run product, we get the same surprised look, followed by the same question: doesn’t that fall apart at scale? We don’t think it does. We think the committee model falls apart first, and the box model is what’s left when the theater clears.

We didn’t arrive at this by reading a book or copying a playbook. We arrived at it by trying the committee model, hating every meeting, noticing that the meetings produced documents instead of features, and gradually replacing each meeting with a smaller, faster, written habit. By the time we looked up, the committee was gone, the box was full, and the product was shipping faster than it ever had. What follows is the structure that emerged, and the failure modes we’ve watched other teams stumble into when they try to copy it without copying the discipline underneath.

There’s a particular kind of process theater that infects product teams once they cross a certain size. The roadmap meeting starts as a useful coordination ritual and ends as a defensive posture — a place where everyone shows up to prove they’re on top of their part of the product, to align their team’s narrative with everyone else’s, and to make sure no surprise lands in their inbox later. The actual work of deciding what to build gets done in side conversations and DMs, and the meeting is just where those decisions get ratified for the record. The meeting becomes a stage, the deck becomes a script, and the user — the person whose problem the product is supposed to solve — becomes an abstraction referenced in slide three.

We don’t blame anyone for falling into this pattern. It’s the default any sufficiently large org drifts toward, and resisting it requires constant maintenance. But the cost is real. Every hour spent preparing for a roadmap meeting is an hour not spent reading what users typed last night. Every layer of approval between an idea and its execution is a layer where momentum dies. And every committee member who insists on being consulted is a committee member who has effectively bought a veto on the team’s velocity. The math gets worse the bigger the room.

What committees optimize for

A roadmap committee optimizes for what’s defensible in a room full of peers. Ideas that sound clever get traction. Ideas that have a confident sponsor get traction. Ideas that involve cross-team coordination get traction because they justify the committee’s existence. The user’s actual day-to-day friction is third or fourth on the list, behind politics, narrative, and whoever spoke last. The result is a roadmap that reads beautifully and ships incoherently, and everyone in the room learns to perform certainty about features they have not yet started.

What a feedback box optimizes for

A feedback box optimizes for whatever made a user open the app, hit a wall, and care enough to type. That filter is brutal and honest. Nobody types into a feedback box to score points with their boss. They type because something broke, something annoyed them, or something delighted them so much they wanted to say so. The signal-to-noise ratio is wildly higher than any meeting we’ve ever attended, and the cost of producing that signal is zero meetings, zero decks, and zero recurring calendar invitations on anyone’s calendar.

The 30-minute triage discipline

Every morning, someone on the team reads the box. Bugs route to whoever can fix them. Feature requests get clustered by theme and dropped into the Development Queue. Thank-you notes get read and answered. The whole thing takes about 30 minutes. There is no agenda, no facilitator, no parking lot, no follow-up email. The work that comes out of it ships the same week, often the same day, and the loop between user complaint and user-visible fix is short enough that users notice and tell their friends, which is the only marketing engine that has ever consistently worked for us.

What gets surfaced (and what doesn’t)

The box surfaces the things users actually trip on — a button in the wrong place, a layer that won’t load offline, a regulation that changed last month and we missed, an icon whose meaning isn’t obvious, a flow that asks for permission at the wrong moment. It does not surface abstract strategic bets, brand positioning shifts, or pricing experiments. That’s fine. Those bets are not what daily product work is made of anyway. Daily work is friction reduction, and friction is exactly what users describe in the box, in their own words, with their own context attached.

Strategic decisions that don’t fit in the box

There are real decisions a feedback box can’t make for us. Which mode to launch next. Which state’s hunting data to add first. How to price a new tier. Whether to invest in a feature that no user has asked for but that we believe will matter in a year. These get decided by the team in writing, fast, with the feedback box as one input among several. A written decision with a date is not a committee — it’s a record. The difference is that nobody had to sit through a meeting to produce it, nobody can later claim they weren’t consulted, and the decision is searchable forever.

Common failure modes of the feedback-box model

The model fails when the box becomes a black hole. Users submit, nothing happens, and they stop submitting. It also fails when triage becomes a queue rather than a habit — once a backlog forms, the signal drops because the freshest, most urgent messages get buried under stale ones. It fails when the team treats the box as a place to dump support tickets without sorting them. The discipline is to read it daily, reply to every named submission, and act on the ones with momentum within a week. If you can’t do that, the box rots, and a rotted box is worse than no box at all.

When you’d actually want a committee

There is a stage where a committee starts to make sense — when the team grows past the point where one person can read the box and reasonably understand the whole product, when regulatory or contractual obligations require formal sign-off, or when a single decision affects so many parts of the organization that not having a meeting would be reckless. None of those describe us yet, and we plan to delay that stage as long as we can, because every committee added is a layer of distance between the team and the user, and distance is the single most expensive thing a small product company can buy.

How to start

If you’re running a product and you don’t have a feedback box, add one tomorrow. Put it in the app, not on a support site buried behind three navigation taps. Make it one tap from the home screen. Have a named human reply to every submission within 48 hours. Cluster the requests into a public queue users can see and reference. Skip the next planning meeting. Read the box instead. The first week will feel chaotic because you’ll see how much you didn’t know. The second week will feel like clarity, and by the third week you’ll wonder how you ever made shipping decisions any other way. You’ll also notice that the people in your company who used to dominate roadmap meetings have less to do, and that fact alone will tell you something useful about how much value those meetings were actually producing.

The Development Queue is in-app, visible to every user. Reading it once a week is more useful than any roadmap meeting we’d ever attend.