Hypothesis-led Discovery: The Work Before The Workshop

The workshop is too ambitious

Discovery workshops promise a lot. Gather the right stakeholders, cover the walls in Post-it notes, ask open questions and the future will reveal itself.

It rarely does.

Put someone in a room with their colleagues and ask what the business needs… It’s a complex pressure test. They must do several things at once: recall facts, interpret customer behaviour, protect internal relationships, negotiate competing priorities and imagine a future state.

The problem is not the workshop. It is asking the participants to perform political-intellectual gymnastics live in front of their peers.

Little wonder some hedge, while others parry the question and fall back on familiar complaints or familiar solutions.

Nor is a blank wall neutral. Arriving without a point of view can look collaborative, but it transfers the analytical burden back to the client.

Statements accumulate quickly. Consensus starts to resemble factual truth.

A useful workshop should not begin Discovery. It should test the work that has already begun. The point of Discovery is to clarify uncertainty. Not catalogue knowns.

A hypothesis is an opinion, not a recommendation

Hypothesis-led Discovery begins before the first workshop.

We review what is already available: strategy, analytics, customer behaviour, product and content structures, technology, service history, previous research and abandoned initiatives.

From that evidence, we identify the questions whose answers would impact the customer experience, operating model, architecture or delivery plan.

For each question, we form a provisional starting position: what appears to be true? Why we think so? What remains uncertain and what evidence would give us reason to change our mind?

A hypothesis is not a recommendation. It’s an idea capable of being validated, refined or rejected.

This gives stakeholders something specific to challenge. They no longer have to invent the future from a blank wall. They can expose exceptions, correct false assumptions and distinguish enterprise requirements from subjective preferences.

A useful hypothesis does not close the question. It makes the question testable.

Make the workshop sweat

Once hypotheses exist, the workshop works harder.

We brief participants in advance, invite them according to the evidence required and focus discussion on actual customer, commercial and operational practices.

Provocation does not mean confrontation. It means presenting a position clearly enough that people can show where experience or evidence contradicts it.

Not every statement becomes a requirement. We distinguish observed facts from stakeholder perspectives, actual requirements, constraints, assumptions and subjective preferences. Assertions are cross-checked against evidence such as analytics, CRM records, code, service history and policy.

Disagreement is not arbitrated into artificial consensus. It smokes out uncertainty to be resolved after the workshop, whether through targeted follow-up, further analysis, a prototype or a technical spike.

By the time the sponsor plenary convenes, its purpose is to challenge synthesised findings and resolve material disagreement, not fill another wall.

The room stops generating requirements from scratch. It becomes a place to validate, refine or reject work already underway.

Earned, not inherited

Hypothesis-led Discovery changes what gets designed.

Each validated finding needs a traceable route from question and evidence to decision, requirement and architectural consequence. That chain prevents the loudest workshop comment from becoming a platform feature. It also helps teams understand why a choice was made months later.

Existing sites, components, customisations, integrations and processes are not carried forward simply because they already exist. Nor is new technology selected because it is fashionable, already licensed or prominent on a vendor roadmap.

Every material decision must be justified against validated customer, commercial, operational and technical requirements.

Where the available evidence cannot resolve a choice, we record it as a Known Unknown and define how it will be answered.

Uncertainty remains visible and manageable instead of silently becoming an assumption. Architecture should be earned, not inherited.

Discovery must produce delivery

A Discovery that ends with a deck of observations has stopped far too soon. And deserves a visible eye-roll.

Validated hypotheses must converge into decisions: agreed goals, prioritised requirements, customer journeys, architecture, governance, an operating model and a sequenced roadmap.

The final Scope of Work should be assembled from those decisions. It must define what is included and excluded, the milestones and acceptance criteria, responsibilities, dependencies, risks and Known Unknowns.

Together, these outputs explain not only what the future should look like, but why, what it will take to build it.

That is the difference between describing a future and making it deliverable.

Workshops still hold value. Stakeholder knowledge remains absolutely essential. But both become more valuable when they operate inside a prepared, evidence-led process.

Good Discovery should leave an organisation with fewer unanswered questions, explicit unresolved ones and enough confidence to commit.

As we say, the point of Discovery is to clarify uncertainty. Not catalogue knowns.