Most voice-of-the-customer work fails because it starts at the wrong step. Teams show customers a solution and hear “sure, looks fine,” which validates what the team already believed and teaches nothing about the problem the customer is trying to solve. The fix is structural, not procedural: put three to five working users of the product inside each project team and keep them there through the first field season. We call the mechanism a customer quick response council, and it is the fastest route we know to the right product. It also takes weeks out of the schedule by finding errors before engineering converges rather than after beta.
What a council is
A council is a small standing group of actual users, assigned to one product and involved in the details of its definition, development, and first season in the field. They are field designers: people who use the product on the job, not experts who speak about it. Five per project gives enough diversity of view while staying fast; three is the practical floor, and the formal sign-off check needs six, so beta candidates join the council to reach it. Each council also carries one buyer or manager alongside the users, because most products have two personas: the user who operates it and the buyer who decides the purchase and cares about the fleet and the back office. And each council has a named owner inside the core team with time allocated to the role, because frequency of contact decides whether the council contributes or drifts away.
Where it works, and its deliverable
The council works the first two steps of VOC and the last one. It states the wants, checks the translation into product requirements, and then confirms the product weekly through development, at introduction, and into the field. Customer requirements are the problem; product requirements are the means, and confusing the two is how teams ship features nobody asked for and miss the ones that matter. The translation deliverable is a sign-off: for each top customer requirement, members confirm the derived product requirement is a valuable reading of the need, would be superior at introduction, and is something they would buy. Where requirements live in a traceability matrix, the deliverable is a signed row. We have watched a council overturn a product definition before capital was committed; that is the sign-off working. The council also takes the trade-off calls, the how-much-is-enough decisions on things like screen size, battery life, and weight, which is where a small standing group beats a survey: the trade-off triangle gets argued by people who will live with the answer.
Why it accelerates the schedule
Five mechanisms, each one a known source of delay. Earlier convergence: the what, who, why, and value questions get answered by users in the first weeks instead of drifting, and fast teams diverge for a third of the program so convergence can have its two thirds. Errors found before build: an error caught in definition is a conversation, and the same error caught in beta is rework. Scope discipline: users rank needs, so features that solve no field problem drop out; on one lateralworks program, a set of wireless and software features left the first release this way, and deferred features became the next release’s roadmap. Shorter beta: council members become the beta sites, as four VOC customers did on that same program, so beta confirms what the team already knows instead of discovering it. And decision velocity: when a product debate stalls on competing expert opinions, a post to the council channel returns field evidence the same day. Position power leaves the room, and decisions move at the under-24-hour turnaround the return on fast decisions demands.
Where it sits, and why connected products raise the stakes
Across the eight modes of customer involvement in the FTTM best practices, the council covers requirements through the first field season, with two modes outside it: gestation, where the next wave of councils should form, and overrun, where a council becomes a mutual problem-solving forum if the program needs one. Connected products raise the stakes on the field season. Software keeps releasing after the hardware ships, each release builds on the last, and a council that disbands at launch loses the people best placed to judge the next release.
What it is worth
The economics are lopsided. A product with three million dollars of first-year incremental revenue loses about eight thousand dollars a day, fifty-eight thousand a week, straight-lined. Use incremental sales, not total product line sales, and the council’s cost, a Slack subscription and a few owner-hours a week, is small against one week saved. It routinely saves more than one.
Others have found the same channel. Slack’s own product organization runs its quarterly customer advisory boards in persistent Slack Connect channels, so the conversation continues between meetings, with separate feedback channels for small companies and enterprises. ProdPad, a product-management software company, built a customer Slack community after noticing most cancellations came from customers outside its community, and its customers now give live feedback on mockups and sketches, which is the council behavior exactly. Neither company frames it as VOC method; both discovered the same mechanics because the mechanics are what a standing channel to real users produces.
Standing it up, and keeping it honest
The mechanics fit in a week. A corporate Slack subscription with one private channel per product. A named owner inside each core team, with the time. An NDA as step zero of onboarding, plus a one-line rule on what never enters council channels, because the most sensitive differentiating IP stays with inside people. Council touchpoints written into the project schedule as dated tasks, requirement sign-off through first-season review, scrubbed weekly with the rest of the plan. Members told where the commit points are, so they know when input shapes this release and when it flows to the next, which is how a weekly council feeds change without feeding rework. A weekly AI scan of the channels to consolidate themes and open questions across councils. And the next wave recruited from current customer engagements, which is where the right customers are found, with those councils formed earlier still, at feasibility entry.
Two things go wrong with councils, and both are visible if measured. Members who lose contact stop contributing, which is why the owner role has time attached. And the council must stay on problems and needs; the moment it becomes a feature show-and-tell, it turns back into feature-based VOC and the schedule benefit disappears. A few per-council indicators, reported by exception in the weekly scorecard, keep both honest: median hours to answer a post, attendance, questions open longer than a week, requirement rows signed, decisions settled by council evidence.
We saw the pattern recently on a program where a paid customer council became the alpha and beta population, converting the best objection to speed into an accelerant. Form the councils now, while definitions are being finalized. By the time beta arrives, it should have nothing to teach. A beta that tells the team something it did not know has arrived too late.
References: Yehoshua, on Slack’s feedback channels and customer advisory boards, in “Product Strategy: Learnings from Slack’s Rapid Ascent,” ProductPlan. “Create a Slack Community for Potential and Existing Customers,” Upland Kapost, on ProdPad’s customer community. The brief’s own numbered references, items 1 through 7, are inside the download.
Related reading: From target market to product definition using VOC, Feature-based VOC vs discovering customer needs, VOC: what, want, how, how much, Differentiating Customer Needs from Product Features, Failure of VOC, Ask the Customer, Bimodal thinking, and The FTTM execution system.