The Power of a Value Committee: Making User Value the Responsibility of the Whole System, Not a Single Team

To understand how seriously a company really takes user value, I don't look at the roadmap. I don't look at the org chart either. I ask for the ten requests support receives most often, and for the notes on the ten deals sales lost last quarter.

Put those two lists side by side and a strange picture usually appears. The support requests come from the gap between what was promised during the sale and what the product actually does. The lost deals come from things the product does that nobody managed to explain. Over-promising on one side, under-explaining on the other. And both are the work of people who meet at the same coffee machine in the same building.

When I see that picture, I think: in this company, value is somebody's job, but it isn't everybody's job.

Value is not a department

In most companies, the question of user value has been quietly handed to the product team. It seems reasonable; they build the product, after all. But what the user experiences isn't the product. It's the whole company.

The user meets you in an ad. Forms expectations in a sales call. Touches the product for the first time in onboarding. Talks to support when they get stuck. Gets an invoice from finance. Meets an account manager when renewal comes around. Every link in that chain affects the equation from the first article of this series: it either grows the progress or raises the cost.

The product team controls one link. The rest is run by teams that never talk about value. Marketing is measured on clicks, sales on closed deals, support on closed tickets. Everyone hits their own number. And the user still leaves.

User value isn't the output of one team. It's the shared product of the whole system. What no one can own alone needs a mechanism to be owned together.

Why a committee?

I know “committee” has a bad reputation. Bureaucracy, long meetings, crowds that never decide anything. I hesitated before choosing the word myself. But it's exactly the name for what I mean: a small structure where people from different teams meet at regular intervals to look at a single question.

That question is: what did our users actually get from us this month?

No dashboard can answer it alone. Product data shows behavior but not the reason. Support tickets show the reason but not the scale. Sales notes show expectation but not outcome. Put all three on the same table and for the first time you see the whole picture.

A practical format

There's a format that has settled over time in the teams I work with. It isn't perfect, but it's enough to start.

Keep it small. One person each from product, sales, support and marketing, plus a leader who connects those teams. Five people, six at most. The more people, the faster the meeting turns into a slide show.

Meet monthly. Weekly is too often; not enough data accumulates to see change. Quarterly is too rare; problems grow.

The agenda is the same four items every month:

1. Proof of value: which user segment repeated the product's critical behavior this month, and which one stopped?
2. Promise gap: what is being said in sales or marketing that has no counterpart in the product?
3. Invisible value: what does the product do that users don't notice or sales can't explain?
4. One decision: which of these gaps do we close next month, and who owns it?

The last item matters most. The committee meets to decide, not to comment. Every meeting should end with one concrete decision and one owner. A committee that makes three decisions usually executes none.

Closing the gaps

In the first few months, promise gaps dominate the table. Sales told a customer “yes, that integration exists,” when the integration only half works. Marketing wrote “set up in five minutes,” when the average setup actually takes half a day.

The important thing here is not to hunt for someone to blame. Sales isn't lying; they're trying to hit the target they were given, and nobody ever spelled out the product's limits for them. The committee's job is to make that information flow both ways. Sales tells product what gets asked most in the field. Product tells sales what's safe to promise. Support shows both of them how those promises blow up in front of users.

Invisible value is talked about less, but it's where the fastest wins are. Almost every product has a capability most users never discover, while the ones who do discover it stay far longer. You don't need to write new code to find it. You only need to carry it into onboarding, into the sales conversation and into support answers. Sometimes a company's most valuable feature is the one that's already built and that nobody talks about.

A shared language

Perhaps the committee's biggest benefit isn't the meetings themselves but the shared language it builds over time. After a few months, sales starts asking “will this customer reach the critical behavior?” Support begins classifying tickets as “a promise gap or a product gap?” Marketing starts judging campaigns not by clicks but by how many of the users they bring reach the moment of value.

That shift in language looks small, but it's a cultural shift. Value stops being a technical concept of the product team and becomes the company's shared goal. Everyone keeps their own metric, but a shared question sits above it.

Start small

I'm not suggesting you read this and call five departments into a meeting tomorrow. There's a simpler start: next month, put support's ten most frequent requests next to the ten deals sales lost. Spend an hour looking at that list with someone from the product team. Once you see how many things grow from the same root, you won't need to convince anyone why the committee is necessary.

In the next article we'll add the dimension of time to this discussion. Because value isn't only about who owns it, but about how it accumulates as the user stays in the product.