Which innovation tool should I use? A guide by situation

Pick the tool by the question your team is stuck on, not by the tool's popularity. There are only about seven situations a team can be in, from "we don't understand the problem" to "we've decided and need to deliver", and each has a small set of tools that fit it. Name your situation first, and the choice of tool becomes short and obvious.

Most teams get this backwards. Someone attended a workshop, liked a canvas, and now every problem gets that canvas. A Business Model Canvas is used to fix a broken approval process. A brainstorm is called when nobody has spoken to a single customer. The tool is fine; it is being asked the wrong question.

This guide maps the whole territory. Use it as a lookup: find the situation that sounds like your week, use one or two of the tools listed, and follow the links to the deeper articles and the method guides.

Start with the question you are actually stuck on

Before choosing anything, write one sentence that finishes: "Right now, we cannot move forward because we don't know…". The ending of that sentence tells you which situation you are in.

If the team cannot agree on how the sentence ends, that disagreement is your real finding. Usually it means you are earlier in the sequence than the most senior person in the room believes.

There is one more situation that sits above the other seven: "we don't know where we should be heading at all". That is strategy, not problem-solving, and it has its own tools, covered at the end of the next section.

The seven situations, and the tools that fit each

1. You don't yet understand the problem

Signs: the team argues from opinion, the same anecdote gets repeated, and nobody can describe a real user's day. The answer is research, and the cheapest research is talking to people and watching them.

• Stakeholder interviews when you need the reasons behind behaviour.
• Contextual observation when what people say and what they do are likely to differ, which is most of the time.
• Diary study when the experience stretches over days or weeks, such as onboarding or a long application.
• Service safari when the team itself has never used the service it runs.
• Experience mapping and an empathy map to make sense of what you heard.

Most wasted research is wasted in the interview itself. Read 5 research mistakes that waste your interviews before you book the first one, and if you plan to map the journey, read a journey map that leads to change, not a poster.

2. You know the symptom but not the cause

Signs: the problem is measurable and recurring (complaints, delays, errors), and every fix so far has been temporary. You need root-cause tools, not ideas.

• Five whys for a single, fairly linear chain of causes. Associated with Taiichi Ohno and the Toyota Production System.
• Fishbone analysis, credited to Kaoru Ishikawa, when several kinds of cause (people, process, systems, policy) are tangled together.
• Pareto analysis when you have data and need to see which few causes account for most of the trouble.
• Problem tree when you also need to show leadership the effects, not just the causes.

The full walk-through is in how to find the root cause of a problem.

3. You have the research but not the problem

Signs: there is a wall of findings and everyone sees a different headline in it. This is the most underrated situation, because a weak framing quietly ruins every step that follows.

• Affinity grouping to cluster findings into themes the team agrees on.
• Point of view to state who has the problem, what they need and why it matters.
• How might we to turn that statement into a question that invites ideas without prescribing one.

Two deeper pieces: your problem statement is the whole project, and 10 "how might we" questions: five good, five bad.

4. You need ideas

Signs: the problem is clear and agreed, and the first three ideas on the table are the ones everyone had before the project started. You need range before you need quality.

• Brainwriting so quieter and junior people contribute before the loudest voice sets the direction.
• Crazy eights for fast, visual variety in eight minutes.
• SCAMPER when you are improving something that already exists.
• Analogies when the team is stuck inside its own sector's habits.
• Worst possible idea when the room is too cautious to say anything unusual.

Why an open "shout it out" session underperforms these, and what to run instead, is in brainstorming doesn't work; here is what does.

5. You have too many ideas

Signs: a wall of sticky notes, a deadline, and a sponsor asking "so which one?". The tool you pick here decides whether the choice is defensible later.

• Impact-effort matrix for a fast first cut.
• Weighted decision matrix when the decision has to survive scrutiny from finance or leadership.
• Now-how-wow when you want a balanced mix of quick wins and bolder bets.
• Dot voting only to surface opinion, never as the final decision.

Compare the options in how to prioritise ideas: five ways compared, and see why the last tool on that list misleads so often in why dot voting lies to you.

6. You have a favourite idea and don't know if it works

Signs: enthusiasm is high, evidence is low, and someone wants to start building. This is the moment that saves the most money.

• Assumption mapping to find the belief that, if wrong, sinks the idea.
• Paper prototype to test an interface or form in an afternoon.
• Wizard of Oz test when the user should experience an automated service that is actually run by hand behind the scenes.
• Concierge test when you deliver the service manually and openly to a handful of people.
• Hypothesis test to write down, before testing, what result would change your mind.

Start with how to test an idea before you build it, then the cheapest prototype you can make this week.

7. You've decided and need to deliver

Signs: the idea has passed its tests, and now it must survive contact with operations, IT, procurement and the people who will run it on a Sunday morning.

• Service blueprint to show what happens front-stage, back-stage and in the systems underneath.
• RACI so every step has one owner.
• Premortem, popularised by the psychologist Gary Klein, to imagine the launch has failed and work out why, while you can still act on it.
• Rollout checklist for the dull, decisive details.

Above the seven: you don't know where you're heading

If the question is about direction rather than a specific problem, use strategy tools: SWOT and PESTLE to scan the position and the environment, three horizons to balance today's business with tomorrow's, and a scenario matrix when the future could go several ways. These belong to strategy work and are best used before a problem-solving project begins, not in the middle of one.

When you need a whole process, not a single tool

Single tools answer single questions. When a project has to travel from "we don't understand" to "it's live", you need a process that strings the situations together in order.

• Design thinking walks through understanding, framing, ideas and testing. The best-known versions are the Stanford d.school's five modes and the UK Design Council's Double Diamond. See design thinking, step by step, and where it goes wrong.
• The design sprint, developed by Jake Knapp at Google and Google Ventures (GV), compresses framing, ideas, choosing and a prototype test into five days.
• Lean startup focuses on situation 6, testing assumptions in a build-measure-learn loop.
• Agile covers situation 7 and beyond: delivering working pieces in short cycles.
• Stage-Gate, developed by Robert G. Cooper, governs a portfolio of projects through decision points.

How to choose between the first four is the subject of design thinking vs lean vs agile vs design sprint. If you want a short list to train a team on first, see the 10 tools every innovation team should know.

A worked example

Illustrative. A regional water utility in a mid-sized European city receives a steady stream of complaints about its new-connection process for homes. The operations director asks the innovation lead to "run a design thinking workshop and come up with ideas".

The innovation lead writes the sentence first: "We cannot move forward because we don't know… why applications stall." That ending points to situation 2, not situation 4. The complaints are a symptom with an unknown cause.

The team pulls six months of application records and runs a Pareto analysis. Most stalled applications stop at one step: the site survey. A fishbone session with surveyors, schedulers and the call-centre team shows several causes tangled together, but one stands out: applicants are not told they must be at home for the survey, so many visits fail.

Only now does the team move to situation 3, framing the problem as "how might we make sure applicants are ready on the day of their survey?". A twenty-minute brainwriting round produces thirty ideas. An impact-effort matrix leaves four. The team tests the top two with a concierge test: for two weeks, a coordinator phones applicants personally two days before each survey.

The result goes back to the operations director not as "ideas from a workshop" but as evidence: what was tried, with how many applicants, and what changed. The service blueprint for the permanent version follows. Five tools were used, each for the question it answers, and the workshop the director first asked for was a small part of the whole.

Do's and don'ts

Do

• Name the situation before you name the tool. Write the "we don't know…" sentence and agree on it.
• Use one or two tools per situation. Depth beats a parade of canvases.
• Move backwards when you need to. If testing shows you misunderstood the user, go back to research; that is the process working, not failing.
• Keep the outputs of each tool where the next step can see them. A fishbone that lives on a photographed whiteboard is lost by Thursday.
• Match the tool to the audience. A weighted decision matrix persuades a finance committee; a storyboard persuades a frontline team.

Don't

• Don't start with ideas because ideas are the fun part. Ideation without framing produces the ideas everyone already had.
• Don't use dot voting to make the final call. It measures popularity in the room, not merit.
• Don't run a full design sprint when you need one root-cause session, or a single root-cause session when the problem needs months of discovery.
• Don't let the facilitator's favourite tool decide the agenda.
• Don't skip testing because the sponsor already likes the idea. That is exactly when testing matters most.

Questions people ask

What are the most common innovation tools? The tools teams use most are interviews, journey or experience maps, how might we questions, brainwriting or brainstorming, impact-effort matrices, prototypes and the business model canvas. Being common is not the same as being right for you, though: use the situation table above to pick.

What is the difference between an innovation tool and an innovation process? A tool answers one question, such as "what causes this?" or "which idea first?". A process such as design thinking, a design sprint or Stage-Gate puts several tools in an order so a project can move from problem to launch.

Can I use these tools without a trained facilitator? Yes, most of them. Tools like five whys, impact-effort matrices and paper prototypes are simple enough for any team to run from a guide. A facilitator becomes valuable when the group is large, senior or divided, or when the stakes of the decision are high.

Where to go next

If you are early in a project, start with stakeholder interviews and how might we. If you are drowning in ideas, go to the impact-effort matrix. If you are about to build, run assumption mapping first. All 75 method guides are in the guides index.