Before we had a system, product requests lived in email, Slack DMs, and one very stressed PM’s memory. (That PM was me.)
This isn’t an unusual situation. Most product teams I’ve talked to have gone through some version of it. The team is growing, the stakeholder list is growing, the number of people who have opinions about what should be built is growing — and the mechanism for capturing all of that is still “talk to the PM and hope they write it down.” It works at small scale. It stops working, noticeably and painfully, somewhere around the time you realize you’ve had three separate conversations about the same feature request with three different people and given three slightly different answers about its status.
At Voxy, this problem arrived with extra context: the company had gone through two acquisitions in 18 months, the team was larger and more distributed than it had been, and there were more stakeholders with more varied interests than before. The ad-hoc system was not failing catastrophically — things were getting built, decisions were being made — but the overhead was constant and the visibility was low.
Process First, Tool Second
This is the thing I most want to say clearly: I did not start by evaluating tools.
There’s a tempting sequence that goes: “We have a prioritization problem” → “Let’s find a prioritization tool” → “We’ll adopt the tool’s workflow.” That sequence produces a system optimized for whatever the tool was designed for, not for how your team actually works and what your stakeholders actually need.
The sequence I followed was: define the intake flow, define the prioritization criteria, define the stakeholder communication cadence, define what “done” looks like for a feature request — and then find a tool that could support that process. Productboard fit well. If it hadn’t, we’d have used something else.
The intake flow question was the most important. If you’re going to consolidate requests into a single channel, you need that channel to be genuinely easier than the alternatives. If submitting a structured request through Productboard is more work than sending a Slack message, people will send Slack messages. The intake form needed required fields — what problem are you solving, who is affected, what’s the business impact — but not so many that filling it out felt like filing a government form.
🚧 Need more context: What were the specific required fields in the intake form? Was there a triage SLA — a commitment about how quickly submitted requests would receive an initial response?
What the System Looked Like
Once intake was defined, the architecture of the system had three main components:
Structured intake for everything. Feature requests, bug reports, and strategic initiatives all entered through the same channel with the same required context. The context requirement was deliberate — “can we add X?” is not actionable, but “sales is losing deals to competitors who have X, and it affects this customer segment” is. Getting that context at submission time meant the prioritization conversation happened with information rather than guesswork.
Stakeholder-specific views. Productboard’s view system let different stakeholders see what was relevant to them without seeing everything. Engineering used a triage view organized by status and effort. Leadership used a strategy view organized by initiative and quarter. Customer-facing teams could see a status view showing where requested features were in the process. Different people needed different lenses on the same data — building those views was a significant part of the rollout work.
Bi-weekly written updates. The most valuable single change in the whole system was a short written product update sent to all stakeholders every two weeks. What was shipped, what was in progress, what had been scoped and was coming up. The format was deliberately readable — not a Jira dump, but a paragraph or two with context.
The update didn’t just inform; it reduced a specific kind of interruption. A meaningful portion of the “what’s happening with my request?” questions came from people who genuinely didn’t know the status — not because we weren’t working on things, but because there was no reliable place to find out. Regular updates trained stakeholders to wait for the update rather than pinging directly.
🚧 Need more context: By how much did “what’s happening with my request?” interruptions decrease after the bi-weekly cadence was established? Was this tracked, or is it more of an observational estimate?
The Cultural Side
Rolling out a process change is not the same as rolling out a feature. With a feature, you ship it and users adopt it or they don’t. With a process change, you have to convince people to change behavior — and behavior change is hard, especially when the old behavior (Slack DMs) is easier in the short term.
The argument that worked was not “this tool is better.” The argument that worked was: “When you send me a Slack message about a product request, here’s what happens to it. It goes into my mental queue, competes with everything else in my mental queue, and may or may not get properly documented. When you submit through this system, here’s what happens: it’s recorded, it’s prioritized against everything else, and you’ll hear back about its status in the next update. Which outcome do you want?”
That framing made the ask concrete. It also made the ask reasonable — it’s not “please follow our process.” It’s “here’s how to make sure your request doesn’t get lost.”
🚧 Need more context: What was the adoption rate across stakeholders? Were there specific teams or individuals who were resistant? How long did full rollout take from design to stable operation?