Building a Value Discovery Squad

Context and the problem

Our design organisation had just been reorganised from regional teams into newly formed subfunctions built around specialised competencies. With new structures came uneven ways of working and few shared reference points for how requests should flow or who should own what.

The challenge was that each lead brought a different lens on what “valuable” design work looked like, shaped by their discipline and experience. Without a shared definition, evaluation naturally varied from case to case. A process document could help, but it wouldn’t be enough on its own.

Over several months, we co-created a scoring framework the leadership team genuinely owned. The next question was whether it would hold up day to day, especially when decisions happened quickly and without deliberate calibration.

I didn’t have formal authority to mandate how work was evaluated, and auditing decisions would have introduced unnecessary politics. Instead, I proposed a structure that made consistent evaluation the default: shared training, paired assessment, and a cadence that kept judgement aligned without relying on oversight. That’s what the squad was for.

Value Discovery Squad - not a solo function

After rounds of iteration with the leads, the evaluation criteria set was finally agreed on. Next, we needed a structure that made consistent evaluation the default rather than dependent on any one person's discipline or instincts, and not vulnerable to reverting to informal judgement once a decision was happening behind closed doors.

I designed the Value Discovery Squad (VDS) model, a two-tier structure that split the work by commitment level:

• VDS Lead: A near-full-time coordination role. Senior enough to challenge stakeholders several levels up, and responsible for the health of the whole evaluation pipeline, not just individual tickets.
• VDS Members: Rotate in on a quarterly basis at partial capacity, each bringing their own competency's point of view into stakeholder interviews. Assignments are paired wherever possible, matched by domain familiarity and requester location, so no one investigates a request alone.

Every new request moved through the same visible pipeline: logged centrally, triaged weekly, and handed to a paired squad member for structured light discovery with stakeholders before a recommendation had to be made.

Findings were scored against the shared framework across value (user need, business impact, strategic fit) and risks (delivery risk, project risk), then presented to the leadership team at a weekly meeting where the LT made the actual intake and assigning decisions.

Protecting the boundary between discovery and commitment

One of the most important design decisions in this workflow was a rule about what the VDS was not allowed to do. Initial stakeholder meetings were for information-gathering only. VDS do not have the authority to make informal agreements with stakeholders to take on the work, no matter how reasonable the request sounded in the room.

This mattered because the entire premise of this process was to enable a considered, consistent assessment before any commitment was made. A single well-meaning "yes, we can probably help with that" in an early conversation would have quietly reintroduced the exact problem we were trying to remove: decisions made by whoever was in the room, not by a fair evaluation of the evidence.

• Stakeholder meetings were always staffed by at least two squad members.
• The scoring questionnaire was intentionally never shared with requesters as it covered judgment calls that needed to stay internal to stay honest.
• Every request had to be scored — at minimum, enough to route it straight to "in progress" or decline it outright.
• A low score was treated as information for leadership, not a verdict.

How the process evolved

What held up from the pilot:

• Evaluation became consistent across subfunctions instead of defaulting to whoever's instincts were loudest or most available.
• Discovery work had an actual owner and a time box, instead of open-ended informal investigation.
• Leadership decisions were grounded in shared, comparable scoring, instead of whoever wrote the most persuasive summary.

What changed over the following two years:

• It became formally governed. Evaluation moved from a squad-run pilot to a tracked pipeline with defined stages and a documented service timeline.
• The scoring framework kept evolving. Within its first six months, one of its "fit" criteria was swapped out entirely once live cases showed it wasn't predicting anything useful.
• Its scope grew past discovery. A separate, smaller consultation function for lightweight design assistance program was folded into the same pipeline. The demand process also gained a third possible outcome: a request could now be routed straight into a pod, but only where one already existed to receive it.

Then, it ran into its own ceiling

The more the squad worked, the clearer it became that consistently evaluating incoming requests, however rigorously, was still a fundamentally reactive posture. We were waiting for others to tell us what they thought they needed, then deciding whether we agreed.

For a central design organisation trying to advance design maturity across the company, that wasn't enough. Raising maturity requires showing up before the brief arrives, not after. The squad, and the centralised pipeline it ran, kept operating throughout. Ad hoc requests never stop arriving, but the limits of a purely reactive model became the real prompt for thinking differently about how a central design practice should relate to the business. That's a different story.

Strategic takeaways

Go deeper

One post follows a thread the VDS work raised, written to be useful beyond this specific case, for anyone navigating the gap between what they're optimising for and what the organisation is quietly measuring them against.

---