Your team's first innovation week: a five-day plan

An innovation week works when it takes one real problem from understanding to a tested idea in five days, with the same small team in the room each day and a decision-maker present at the end. Monday is for the problem, Tuesday for the people who live it, Wednesday for ideas, Thursday for a prototype and Friday for testing and deciding. Below is what to prepare, who attends and what each day must produce.

This is not a hackathon and not a festival of talks. If your week has a keynote and a prize, it is a different event. If you want the longer, gentler version spread over a month, see Where to start with innovation in your team: the first 30 days.

Before the week: two weeks of preparation

Most innovation weeks are decided before Monday. In the two weeks before:

• Agree one problem with a sponsor. Written as a sentence about people, not a theme. "Visitors to our service centre leave without completing their request" is workable. "Improve service" is not.
• Name a decider. The person who will be in the room for the last two hours on Friday and will say what happens next.
• Recruit five users for Friday. Real people who experience the problem, booked for 30-minute slots. This is the step teams forget, and without it Friday is a presentation, not a test.
• Book four to six interviews for Tuesday morning, with people who live the problem and one or two who work around it.
• Clear calendars. Core team members are out of their normal work for the week, mornings at minimum. Half attention gives you half a week.
• Prepare a room with wall space, paper, markers and sticky notes, or one shared online board if you are remote.

The structure owes a lot to the Design Sprint developed at Google Ventures and published by Jake Knapp, John Zeratsky and Braden Kowitz in Sprint (2016). This plan is gentler: it spends a full day on listening, because a first-time team usually does not yet know its users well enough to start from expert interviews alone.

Who attends

• Core team (four to seven people): all five days. Mix the people who do the work, someone who faces users daily, someone who knows the systems or rules, and one outsider.
• Facilitator: runs the clock and the methods and does not contribute ideas. This can be someone from another team.
• Decider: Monday morning for an hour and Friday afternoon for two. Available by phone in between.
• Users: Tuesday (interviews) and Friday (tests).

Day 1 (Monday): agree the problem

Prepare: the draft problem statement, anything already known (complaints, data, previous attempts).

Run:

1. The decider opens for 20 minutes: why this problem, what is in and out of scope, what a good Friday looks like.
2. The team writes down, silently, everything it believes about the problem. Group the notes using affinity grouping.
3. Sort the beliefs into "we know" and "we assume". Turn the biggest assumptions into questions for Tuesday.
4. Finalise the interview guide. Short, open questions about real past events.

Comes out: an agreed problem statement, a list of assumptions, the interview guide.

Day 2 (Tuesday): listen

Prepare: interview slots, a note-taker for each, consent agreed.

Run:

1. Morning: four to six stakeholder interviews, in pairs. One person asks, one writes what is said, not what it means.
2. After each interview, ten minutes to capture quotes and observations while fresh.
3. Afternoon: build one empathy map per type of user you met.
4. Close by writing three to five "how might we" questions from what surprised you. The how might we guide shows how to keep them neither too wide nor too narrow.

Comes out: interview notes, empathy maps, three to five "how might we" questions, and the one the team chooses to work on.

Day 3 (Wednesday): generate and choose

Prepare: the chosen question printed large, the empathy maps on the wall.

Run:

1. Brainwriting: everyone writes ideas silently and passes them on to be built upon. Quantity first.
2. Crazy eights: eight rough sketches in eight minutes, to move from words to pictures.
3. Each person develops their strongest idea into a one-page sketch with a title.
4. Silent gallery, then dot voting to show where interest lies. The decider then picks one or two to prototype. Voting informs; it does not decide.

Comes out: one or two chosen concepts, with the reasons written down.

Day 4 (Thursday): prototype

Prepare: paper, card, a slide tool or form builder, whatever matches the idea.

Run:

1. Morning: draw a storyboard of six to eight frames showing a user moving through the new experience.
2. Split the work: who makes which part, who writes the words, who writes the test script.
3. Build a paper prototype or a mock-up just real enough for a user to react to. A new leaflet, a fake screen, a script for a counter conversation.
4. Rehearse the test once inside the team at 4 pm.

Comes out: a testable prototype and a test script with three to five things you want to learn.

Day 5 (Friday): test and decide

Prepare: the five user sessions, a quiet room, an observation room or video link for the rest of the team.

Run:

1. Morning: five 30-minute tests. One interviewer, everyone else watching and writing on a feedback capture grid: what worked, what didn't, questions, new ideas.
2. Early afternoon: look for patterns. What did three or more users do or say?
3. Decision session with the decider (90 minutes): show what you heard and saw, then decide one of three: build it further, test a revised version, or stop.
4. Last 30 minutes: a retrospective on how the week ran.

Comes out: a decision, an owner and date for the next step, and a list of who contributed what during the week.

Do's and don'ts

Do

• Book Friday's users before the week starts. No users, no test.
• Keep the same core team all week. People dropping in and out reset the room every day.
• Keep the facilitator out of the ideas.
• Write down the reason for every choice, not only the choice.
• End with an owner and a date. A week without a next step is remembered as a nice workshop.

Don't

• Invite twenty people. Beyond seven, sessions slow and quieter people stop speaking.
• Let the decider vanish until Friday, then overrule everything.
• Polish the prototype. If Thursday overruns, it is too detailed.
• Pitch on Friday. Testing means watching people use it, not presenting to them.
• Pick a problem the team cannot touch after the week ends.

Illustrative example

Illustrative: an invented organisation, for explanation only.

A public library network in a mid-sized European city runs its first innovation week on one problem: new members sign up but rarely come back after their first visit.

On Monday the head of services explains the scope: no building changes, no new staff. The team lists its assumptions; the biggest is that people do not return because opening hours are inconvenient. On Tuesday, five interviews with recent members tell a different story: most did not know they could reserve books online, and two felt awkward asking staff for help. The question becomes: "How might we make a new member's second visit feel easier than the first?"

Wednesday produces about 60 ideas; the head of services chooses a "second visit" card handed over at sign-up, with three things to try next time. On Thursday the team storyboards the sign-up conversation and prints a rough card. On Friday five new members try it at the desk. Four understand the reservation tip; none read the back of the card. The decision: test a shorter, one-sided version at two branches for a month, owned by the branch lead who joined the team.

Questions people ask

What should we do during an innovation week? Work on one real problem with the same small team for five days: agree it, listen to users, generate ideas, prototype one and test it with real people, then decide. Talks and competitions can come later.

How is an innovation week different from a design sprint? A Design Sprint, as published by Google Ventures, usually assumes the team already understands its users and moves to sketching quickly. A first innovation week spends a full day listening, because new teams usually need it.

Can we run an innovation week remotely? Yes, with one shared online board, shorter sessions (no more than 90 minutes without a break) and tests by video call. Keep cameras on during the decision session.

Where to go next

The methods behind each day are explained in the guides to stakeholder interviews, how might we, crazy eights and paper prototypes. For the five tools worth learning first, read The 5 methods every team should learn first. For the bigger picture, return to the first 30 days.