Innovation talk vs workshop: run a session on a live problem instead

On-Off Group

October 2026

An innovation talk raises energy for a day. A workshop on a live problem, run with the people who own that problem, produces decisions and a rough version of something you can test. If you only get one slot, use it on a real problem.

If you work in digital, HR or innovation at a bank or insurer, someone has probably asked you to book a speaker for a staff day. A keynote on innovation, an hour, a full auditorium, good photos for the internal newsletter.

This is for when you have one budget line and one day in people's calendars, and you have to choose between a talk and a workshop. The short version: a talk puts people in a good mood, but usually nothing in the work changes the week after. A workshop on a live problem gets you decisions and a rough version of something, plus a number you can compare against later.

Below is how to set one up, what problem to pick, and what to measure so you can answer when your boss asks whether it worked.

What happens the week after a talk

The talk lands well. People clap. The feedback scores are good and someone quotes the speaker in a group chat.

Then Monday comes and the onboarding form still takes the same number of days it did before. The team still re-keys the same customer details. Nobody has permission to change anything, because nothing was decided in the room. A talk is meant to leave people feeling good. Nobody went back to their desk with anything to do.

We have seen this from the other side. Workshop participants from 2015 are now senior across Philippine financial services, and the ones who still talk about those sessions talk about the problem they brought in, not the speaker. What they remember is the problem they brought in and what they changed about it afterwards.

If the budget only pays for one session, spend it on the session where someone in the room can approve a change.

Pick a problem the owner can describe in one sentence, with a number in it

The most common way a workshop turns into a talk with sticky notes is a theme instead of a problem. Customer centricity. Being more innovative. A room cannot do anything with either of those in a day.

What works is narrow. The onboarding flow where applications drop off at the income step. The branch queue on the 15th and the 30th. A claim where nobody can say which step is the slow one.

Ask the owner of the problem to describe it in one sentence with a number in it. If they cannot, that is useful information before you book anything. Two or three candidate problems is plenty. Choose the one where someone in the room can approve a pilot, otherwise the output goes into a queue and dies there.

If you want to see what a team actually does with a problem like that, this page on design thinking walks through the steps without the theory.

Get a number before the day starts

Most companies skip this part, and then six months later nobody can say whether it worked.

Before the workshop, write down one number about the problem. Current turnaround time. Percentage of applications completed. Number of calls to the branch about one step. It does not need to be perfect. It needs to exist, and it needs a date next to it.

Without that, the session can only be judged on how it felt. With it, you have something to show three months later, even if the answer is that nothing moved. A small honest number is easier to defend than a big vague claim when someone asks what the day produced.

The number also keeps the room honest. When a team knows the measure is completion rate on the onboarding form, ideas that do not touch completion rate get dropped quickly.

What you should have at the end of the day

A good workshop ends with something you can put in front of a person. A paper version of the new form. A clickable prototype. A revised script for branch staff. Rough is fine. It just has to be specific enough for someone to tell you it is wrong.

At a large insurer, customer-facing web journeys had been running on a six month cycle from idea to live. Working in five-day design sprints, those journeys were designed and tested with customers in two weeks and live in four. Twenty-six weeks down to four. Completion rates on the new journeys rose 80 per cent, measured by the client, and the old drop-off points stopped showing up in their data.

That came from putting a rough version in front of real customers early, while the mistakes were still cheap to fix. The people who own the process have to be in the room together long enough to make those calls.

Who to put in the room

For a workshop you want six to twelve people who actually touch the problem.

That means branch or frontline staff, not just their managers. Operations. Someone from risk or compliance, early, so the answer is not discovered later. One person who can say yes to a pilot. Bring the developer who will have to build it. A bad idea dies fast once someone says what it would take to build.

Mixing the roles is what makes it work. The arguments happen early in the day, instead of in a steering meeting weeks later. Design thinking training for cross-functional bank teams covers how those groups are usually put together.

One more thing on format. If the problem is already agreed and you just need a rough version built and tested with customers, book a five-day design sprint instead of a general workshop. If the problem is still fuzzy, start with the workshop. What a custom workshop is and how we build one with your team sets out what we ask for beforehand.

What to do this week

Write down two or three live problems you would put in front of a room, each in one sentence with a number in it.
Pick the one where someone in the building can approve a pilot without a committee.
Find or estimate the current number for that problem today, and put the date next to it.
List the six to twelve names who touch the problem, including branch staff and whoever would build the fix.
Go back to whoever asked for a speaker and tell them what you are running instead, and what you will have at the end of it.

Questions people ask

Is there ever a good reason to book an innovation talk?
Yes, when the goal is genuinely to open an event or introduce a theme to a large audience. It stops working when it is asked to change how people do the job on Monday.

How big should the problem be for a one-day workshop?
Small enough to name in one sentence, like the onboarding form that branch staff have to re-key. Broad themes such as customer centricity give the room nothing to work on.

What should we measure before the workshop?
One number about the problem itself, for example current turnaround time or how many applications drop off at a step. Without it, nobody can answer whether the session worked.

Who needs to be in the room?
The people who touch the problem daily, including branch or frontline staff, plus someone who can approve a pilot. Six to twelve people with decision power beats a full auditorium.

On-Off Group trains teams, tests products with real customers, finds where a transformation has stalled and builds what gets it moving, for banks, insurers and enterprises in the Philippines, since 2015. How we help with design thinking.