Three proposals can land in the same week, each promising a mindset shift and a wall of sticky notes. The innovation lead wants a method the squads will still use in March. The digital lead wants the work tied to a service that is already late. The learning lead has to tell a sponsor why this room is different from the last offsite.
If you are the person choosing, read the problem before you read the method names. A programme earns its cost when a real situation comes in the door and a rough version of a fix leaves with the team. A day that ends on a poster, with a promise to socialise it later, has taught the vocabulary and left the work where it was.
Mindset and method
IDEO describes human-centred design as the mindset: a deep read of people, including the gap between what they say, think, do and feel. Design thinking is the process that puts that mindset to work, asking what is desirable for people, viable for the organisation and feasible with the technology you have. Buy them together. The mindset is time with people. The process is how the team turns that time into a prototype and a decision.
IDEO also says that learning the language is a weak substitute for practising it. The practice takes judgment and the right conditions inside the organisation. I use that as the buying test. If the proposal teaches the stages and never puts the team in front of a person who lives with the problem, you are paying for the vocabulary. The conditions have to be in the room too. A sponsor who has already chosen the feature, and wants the team to decorate it, will undo the method before lunch.
The problem you bring
The best programmes I run start from a live problem the business already cares about. A claims path customers abandon. An onboarding sequence new staff complain about in week one. A service handoff that generates the same incident every month. A made-up case lets everyone be polite, and polite people learn very little they can use on Tuesday.
Write the problem as a situation with a person in it. Customers dropping out of a form gives the room something to investigate. Build an app hands them the answer and asks them to decorate it. I push back on the second kind of brief before we lock a date. The longer argument, when a sponsor has already picked the feature, is in solve the right problem before the build starts.
Innovation, digital and learning leaders often arrive with three different sentences for the same mess. Innovation wants a new bet. Digital wants the current journey to stop leaking. Learning wants a skill the company can repeat. Make them agree the situation in writing before you book the room. If they cannot, the first hour will be a negotiation you should have finished on the call.
Who has to be in the room
Bring the people who will have to live with the outcome, and keep them together. Product, operations, the front line and the function that owns the policy each hold a slice. A room of only innovators will draw a careful map and then discover that the team who can change the system was never invited. A room of only learners will leave with a method and no permission to use it on the live work.
Keep a sponsor for the moment the problem gets rewritten and for the readout. A sponsor who opens the day and leaves before the evidence arrives will overrule the team later from a slide they did not see built. Eight to thirty people is the range that still lets everyone do the work. Past that, the day turns into a presentation with stickers.
Digital leaders should bring the constraint that is actually binding. A security rule, a legacy screen, a call-centre script, a regulator's notice. Hide the constraint and the team will design a fix you cannot ship. Innovation leaders should bring the bet they are willing to kill. Learning leaders should bring the names of the people who will run the method next time, without a facilitator in the room.
What the days have to include
IDEO's account of the work is the one I hold a proposal against. Deep research with real people in real contexts. Prototyping and testing early, with the people the product, service or experience is meant to serve. That circle includes customers, and it includes employees and other stakeholders. Refining until the rough version is a true response to what you heard. A programme that skips the research and keeps the prototyping has taught craft without a target.
In our design thinking workshop the team frames the challenge, spends time in the user's world, turns the mess into a problem worth solving, then diverges and builds something rough the same day. The outputs I want are a defined problem, a pile of ideas the room is willing to kill, at least one low fidelity prototype, and a method the team can run again. Half a day can frame and test the brief. A full day can reach a prototype. Two days give you time to put that prototype in front of someone outside the team and to change it.
Both in person and remote can do this. The remote version needs shorter blocks. A long stretch of silent sticker work on a webcam wears the room out before the useful argument starts. The conversations with users still work on video, provided someone has booked them. If nobody owns the recruiting, the interviews quietly become a panel of colleagues, and colleagues will defend the process they built.
A workshop and a programme
A single day can reset a team that has been guessing. It will not install a habit across a portfolio. IDEO frames capability building as a handoff: the organisation carries the work after the engagement, people learn by doing the real project beside someone who has done it before, and they leave owning the practice. People support what they create. A slide pack they did not create will sit in the drive.
If you are buying the first day and want to know what the agenda should contain, read what a corporate design thinking workshop should cover. If the brief is a service people already use, the longer note on getting those people into the work is how to design a service with its users. Buy the day when you have one live problem. Buy the programme when several teams need the same method, and when you can name who will coach the next one.
A programme I would accept has a rhythm, not a catalogue. One live problem in the first session. A second problem, run by the internal people with a lighter hand from us. A date when the sponsor looks at whether the method was used without being summoned. If the plan is a stack of modules and a completion row, you are buying attendance. Ask what the second team will hold in their hands, and who will be in the room when we are not.
What a proposal gives away
Some warning signs show up before you sign. The agenda lists a stack of canvases and no time with users. The pack promises a mindset shift and never names an output. The facilitator offers a case from another industry so the team can practise without touching a live complaint. Any one of these means the day will feel busy and the backlog will look the same next month.
Another sign shows up in the room. People present to each other, cluster notes and never sit with someone who uses the service. The energy is real. The user is absent. You will leave with a tidier version of the assumptions you walked in with. I would rather cancel the afternoon and book three conversations than finish the wall.
Watch the language in the proposal as well. A document that cannot say who the work is for, in one sentence, will not suddenly become specific at 9am. A document that promises to align stakeholders and never says align them on what, will spend the day on the org chart. Ask for the sentence. If they cannot write it, they have not understood the brief, and another workshop will not fix that on the day.
What to ask before you book
- What live problem will we bring, and who has agreed it is the one?
- Who recruits the users or frontline staff, and will the team actually hear them?
- What will we hold at the end of the first session, and who outside the team will have seen it?
- Who runs the method on the next problem, and when will we check that they did?
The last question separates a workshop from a programme. If the answer is a centre of excellence with no date, you are buying a label. Ask it while changing supplier is still cheap.
After the first session
Leave with the problem statement, the rough prototype, the owner and the next date. If the day shows you have been solving the wrong problem, that is a useful result, and the next booking should take the problem you just found. If the prototype holds and turns into a bet about what people will adopt, test that bet with evidence before the business case gets thicker.
Regulated teams can do this work. The interviews and the rough test have to stay inside the rules you already live with. A paper screen, a rewritten notice or a role-played call can teach you a lot without putting a customer or a licence at risk. Put the constraint in the brief so the room designs a test that can actually run.
If you want to choose the programme, send me the problem the way a user would describe it, the names of the innovation, digital and learning leads who have to agree, and whether this is one day or a run of them. We will shape the work around that problem and plan the conversations with you.
