How I run an engagement.

Agree what the engagement is for before any research starts.

Activities

• Scope and success criteria agreed
• Data and systems request issued in week one
• Hypotheses to test, rather than assumptions to confirm
• Stakeholder map across business, ops and tech
• Research plan, and the questions it must answer
• Programme plan and staffing
• Governance, cadence and reporting line

Getting setup right makes everything easier. Correcting course later is harder — other decisions already rest on it.

Example output

Outputs

Scope · data and systems request · plans · stakeholder map · success measures

Four accounts of the same service, each tested against the data.

Activities

• Customer — interviews and journey research, run separately per persona
• Stakeholder — cross-functional interviews, from board-level to shop floor
• Market — competitors, channels, partners and the rules it works inside
• Technology — reviewed with an architect: what the estate can actually do
• Operational immersion — watching the work, not hearing it described
• Themes synthesised as interviews complete

One view of the whole service: every output from discovery summarised into a single blueprint.

Example output

Outputs

Service blueprint with pain point and opportunity themes

Make the whole system visible at once, so people are arguing about the same picture.

Activities

• Priority journeys agreed with the client, validated with users
• Journeys mapped from the perspective of customer and organisational personas
• Process mapping for internal workflows
• Systems, hand-offs and data flows
• Pain points logged against the step they occur
• Quantified where the data allows — volumes, drop-off, handling time

The baseline has to be what actually happens in these journeys, not what the process documentation says happens. Everything after this is measured from it.

Example output

Outputs

Journey maps · service blueprint · personas · prioritised journeys

Set out everything the organisation could do, before deciding what it will.

Activities

• Opportunity themes grouped into strategic epics
• Epics arranged against the journey stages
• An initiative card per epic: impact and features
• Epics sized against each other, before costing
• Overlaps and dependencies named across epics
• Checked back against the blueprint for gaps

Deliberately not user stories. It sits between the strategy deck and the delivery backlog — fundable by leadership, breakable down by a team.

Example output

Outputs

North Star Backlog · initiative cards · features listed

Design what the service should become, then test it before anyone commits to it.

Activities

• To-be journey mapping and future-state blueprint
• Operating model — roles, processes and constraints that have to change
• Design sprints per stage, and wireframes
• Clickable prototypes of the priority flows
• Feasibility tested with the engineering team
• Validated with users, and with the teams who will run it

The prototype is the specification. It is easier to argue with several linked screens than with a document no two people read alike.

Example output

Outputs

To-be journeys · future blueprint · operating model · prototypes · feasibility

Decide what gets built, in what order, and make the case for paying for it.

Activities

• Value, requirement and operational complexity scored separately
• Operational constraints surfaced explicitly
• Dependencies mapped, releases shaped
• Benefits quantified against success measures
• Options costed, including platform choice and doing nothing
• Cost, trade-offs and recommendation, put to the board with the workings visible

Prioritisation usually starts where the organisation owns the journey — you want to avoid sending more users into a journey that is not yet ready.

Example output

Outputs

Scorecard · prioritised roadmap · business case · funded scope

Get the organisation ready for what is coming.

Activities

• Impact assessment across affected teams and roles
• Process and policy changes, with an owner
• Communications sequenced against the release plan
• Training written for the people who will use it
• Champions identified inside affected teams
• Readiness check, with authority to delay go-live

Adoption is where the business case either lands or does not. It is planned before release rather than after it.

Example output

Outputs

Impact assessment · comms and training plan · adoption measures

Build it in cycles, and own what ships.

Activities

• Research re-tested before each build
• Features, stories and acceptance criteria
• Backlog ownership, the board and the standups
• Design iterated with the team through build
• Prioritisation with client leadership
• Staged releases, measured against the criteria

It runs as a cycle, not a handover. Each pass checks that what discovery established still holds.

Example output

Outputs

Requirements and backlog · working releases · measured outcomes

The engagement ends. The service does not.

Activities

• Benefits reviewed against the business case, including the misses
• Whether the new ways of working stuck, or quietly reverted
• Backlog refreshed from live behaviour
• Handover, so the client’s team can carry it without me
• The next cycle scoped from what the service does

This is where the loop closes. What the service does once people use it is better evidence than anything gathered in discovery.

Example output

Outputs

Benefits review · adoption check · refreshed backlog · handover