Where to start with innovation in your team: the first 30 days

Start with one real problem your team already owns, not with a strategy, a lab or a training course. In the first 30 days, choose that problem with a sponsor, listen to the people who live it, frame it as a question, try a few cheap ideas and end with a decision about what to keep. A team that finishes one small cycle honestly has started innovating; a team that spends the month writing a framework has not.

This guide maps the whole first month: what to decide before you begin, a week-by-week plan, who needs to be involved, what you should be able to show on day 30, and the mistakes that stall most first attempts. Each section links to a deeper article if you want more.

What "starting innovation" actually means

Most teams think they need permission, a budget line or a new unit before they can begin. They need none of those to start. They need a habit: notice a problem, understand it properly, try something small, learn from it, decide.

It helps to be clear about what kind of innovation you are starting. The OECD's Observatory of Public Sector Innovation describes four facets: enhancement (doing existing work better), mission-oriented (working towards a clear goal by means not yet known), adaptive (responding to a changed situation) and anticipatory (preparing for possibilities that could reshape what you do). The model was written for governments, but it is useful for any team. Almost every first 30 days belongs in the first facet. That is not a lack of ambition. Improving something people use every day is how a team learns the methods, earns trust and gets the right to attempt the bigger things later.

So the goal of month one is not a breakthrough. It is a team that has completed one honest loop from problem to decision, and wants to do another. If you are unsure whether the conditions are right, read 7 signs your team is ready to innovate, and 3 that it isn't. If you think you need a dedicated unit first, read "We need an innovation department first." Why you don't.

Before day one: three decisions

Spend an hour on these with whoever will sponsor the work. Skip them and you will have the same argument in week three, with less goodwill.

1. Which problem. Pick one problem, not a theme. "Customer experience" is a theme. "New clients wait eleven days for their first meeting and we don't know why" is a problem. A good first problem is one your team can influence without another department's sign-off, that people feel today, and that you can learn about by talking to real users within a week. The article The first question to ask before any innovation project goes deeper on choosing and testing the problem.
2. Who sponsors it. One named senior person who agrees to give 30 minutes in week one and an hour at the end, and who will make the decision on day 30. Not a committee. If no one will put their name on it, the problem is not important enough or you have picked the wrong one.
3. What "done" looks like. Agree in writing that day 30 ends in one of three outcomes: keep and scale a change, run a second round, or stop. Stopping counts as success if you learned why. Writing this down early protects the team from being judged on whether the first idea "worked".

The first 30 days, week by week

The plan below assumes a core team of three to six people giving roughly a day a week, plus a few focused sessions. It works with no budget beyond people's time. If money is the worry, see Innovation with no budget: what you can start on Sunday.

Week 1: understand who is involved

• Draw a stakeholder map. In 45 minutes, list everyone who touches the problem: the people who experience it, the people who cause it without meaning to, the people who could block a fix and the people who would benefit. A stakeholder map stops you designing for the people in the room.
• Book the conversations. From the map, choose six to eight people to talk to next week, including at least two who experience the problem directly and one who will be sceptical.
• Brief the sponsor. Show the problem statement and the map. Ask one question: "What would make you say this was worth it?"

Week 2: listen before you solve

• Run short interviews. Thirty to forty-five minutes each, two people per interview: one asks, one writes. Ask about the last time something happened, not what people think in general. The stakeholder interviews guide has a question bank.
• Watch where you can. Twenty minutes watching a process happen often beats an hour of talking about it.
• Map the experience. At the end of the week, lay out the steps people go through and mark where it hurts. An experience map built from what you heard, not what you assumed, is the most useful artefact of the month.

Week 3: frame the problem, then generate ideas

• Find the cause. Use a problem tree to separate the visible symptom from what is driving it. Teams often find the real problem is one step upstream of where they started.
• Turn it into a question. Write two or three "how might we" questions. The phrasing comes from Min Basadur's work at Procter & Gamble in the 1970s and was later popularised by IDEO. "How might we" invites options without promising a solution. See the how might we guide.
• Generate silently first. Run a brainwriting round before any open discussion, so the most senior or loudest voice does not set the direction in the first minute.
• Choose two or three ideas to try. Use an impact–effort matrix for a quick first cut. Pick ideas you can test in a week, not the biggest ones.

Week 4: test, then decide

• Make it cheap and real. A paper prototype, a mocked-up form, a changed script for one counter for one morning. If it takes more than two days to make, it is too big for this month.
• Test with five or so real users. Watch what they do, note where they hesitate, ask what they expected.
• Run a premortem before you recommend anything. Ask the team to imagine it is six months later and the change failed, then list why. The technique was described by the psychologist Gary Klein in Harvard Business Review in 2007. It surfaces risks people would otherwise keep to themselves. See premortem.
• Hold the decision meeting. One hour with the sponsor. Show what you heard, what you tried, what happened, and recommend keep, rerun or stop.
• Close with a retrospective. Thirty minutes on how the team worked, not what it produced. A retrospective is what turns one project into a habit.

If you prefer to compress the method work into a single focused stretch, Your team's first innovation week: a five-day plan runs weeks two to four as five consecutive days.

Who needs to be involved

• A sponsor who owns the decision on day 30 and protects the team's time.
• A lead who keeps the rhythm, books the sessions and writes up what was decided. This does not have to be the most senior person. It has to be someone others will turn up for.
• A core team of three to six people, ideally mixing those who do the work, those who see the user and one person from outside the unit who will ask naive questions.
• Users and frontline staff, involved in weeks two and four, not invited to a presentation at the end.

Keep the core team small. Ten people make every session a meeting. If many people want to join, invite them to the test sessions in week four, where an extra pair of eyes is genuinely useful.

What you should have on day 30

You are not aiming for a finished product. You should be able to show:

• a one-paragraph problem statement that the sponsor agrees is right;
• notes from six to eight conversations, and an experience map built from them;
• two or three ideas that were tested, with what happened in each test;
• a decision (keep, rerun or stop) with a short reason;
• a list of who contributed what, so the people who did the work are visible;
• the team's own view, from the retrospective, of what to do differently next time.

That last item matters more than it looks. The point of the first month is to build the team's ability to do it again without you.

The methods to learn first

You do not need dozens of tools. Five carry most of a first project: interviews to listen, "how might we" to frame, brainwriting to generate, an impact–effort matrix to choose and a paper prototype to test. Each is explained in The 5 methods every team should learn first, with what to skip until later.

If you work in government

Public bodies have particular constraints: procurement rules, approval chains, annual planning cycles and a reasonable fear of public failure. The 30-day loop still works, but the first three months need a different rhythm, with more attention to mandate, governance and evidence. See Starting innovation in a government entity: the first 90 days.

Do's and don'ts

Do

• Pick a problem small enough to finish in a month and real enough that people care.
• Talk to users before anyone suggests a solution.
• Protect a fixed slot each week. Innovation that fits "when there is time" never happens.
• Write down who contributed each insight, idea and test, as you go.
• Treat a well-reasoned "stop" as a good outcome.

Don't

• Start with a branding exercise, a logo for the initiative or a launch event.
• Ask for ideas from the whole organisation before you know the problem. You will get hundreds you cannot follow up, and people will stop sending them.
• Let the most senior person speak first in idea sessions.
• Build anything that takes more than two days before you have tested it on paper.
• Judge the month on whether the first idea worked. Judge it on whether the team learned and decided.

Illustrative example

Illustrative: an invented organisation, for explanation only.

A regional office of an international logistics firm, in Rotterdam, has a customer-service team of twelve. The manager wants to "start innovating" and has been asked by head office to show something within the quarter.

Instead of launching an ideas campaign, she picks one problem: customers call several times to ask where a delayed shipment is. Her director agrees to sponsor it and to decide on day 30.

In week one, four team members map who is involved: customers, drivers, the warehouse, the tracking system team. In week two they interview seven customers and sit with two drivers for a shift. The experience map shows something they had not expected: customers are not mainly asking where the parcel is, but whether anyone knows it is late. In week three, the "how might we" becomes "How might we tell customers about a delay before they notice it?" Brainwriting produces 40 ideas; the matrix narrows them to two. In week four they test a manually sent message for delayed shipments on one route for three days. Repeat calls on that route drop noticeably, and the premortem flags that a manual message will not survive a busy week.

The decision on day 30: rerun, this time with the tracking system team in the room to explore automating it. The retrospective notes that the driver shifts were the most valuable two hours of the month.

Questions people ask

How do I start innovation in a team that has never done it? Pick one problem the team already owns, give it a fixed weekly slot and a sponsor, and run one loop: listen, frame, generate, test, decide. Do not start with training. People learn the methods faster by using them on something real.

How long does it take to see results from innovation? You should see a tested idea and a clear decision within about 30 days. Measurable change in a service usually takes longer, often a second or third cycle. Be wary of anyone promising transformation in a quarter.

Do I need an innovation strategy before I start? No. A strategy is much easier to write once you have run a few cycles and know what your team is good at and where the real problems are. Start small, then use what you learned to shape the strategy.

Where to go next

The articles in this section go deeper on each part of the first month. Is your team ready to innovate? helps you check the ground before you start. The first question to ask helps you choose the problem. Your team's first innovation week and The 5 methods every team should learn first cover the practice. Innovation with no budget, Why you don't need an innovation department first and Starting innovation in a government entity deal with the usual objections and settings.

For the methods themselves, start with the guides to stakeholder interviews, experience mapping, how might we and premortem, or browse all of them in the guides index.