The first question to ask before any innovation project

Before any innovation project, ask: "If this works, what decision will change, and who will make it?" If nobody can name the decision and the person, the project has no landing place, and good work will end as a report. If they can, you know who to involve, what evidence to collect and when you are done.

Most kick-offs start with a different question: "What should we build?" or "What's the idea?" Those come later. The first question is about consequence, because consequence is what separates an innovation project from an interesting exercise.

Why this question comes first

Innovation projects rarely fail for lack of ideas. They fail at the moment a finding meets an owner who was not expecting it, has no budget for it, or never agreed to act. Asking about the decision up front surfaces that problem on day one, when it is cheap to fix.

The question also does three quieter jobs:

• It reveals whether the solution is already decided. If the honest answer is "the decision has been made; we need to justify it", you are doing delivery, not innovation. Better to know now.
• It sets the evidence bar. A director deciding whether to change a form needs different evidence from a board deciding whether to enter a new market. Knowing the decision tells you how much testing is enough.
• It defines "done". The project ends when the decision is made, not when the workshop series ends.

If you are still deciding whether to start at all, read 7 signs your team is ready to innovate.

How to ask it: seven steps

1. Ask it in the first meeting, out loud

Put the question on the first slide or the top of the page: "If this works, what decision will change, and who will make it?" Ask the person who commissioned the work, not only the team. Write down their answer word for word.

2. Push for a specific decision

Vague answers sound like "leadership will consider scaling it" or "it will inform our strategy". Push gently: "Which meeting? Which budget? Which rule?" A good answer sounds like "the operations director will decide in March whether to replace the paper intake form in all branches". You want a verb, an owner and roughly a date.

3. Name the decision-maker and talk to them

If the decision-maker is not the sponsor, go and see them in the first two weeks. Ask what they would need to see to say yes, what would make them say no, and what else is competing for the same budget or attention. A quick stakeholder map helps you see who else can block or accelerate that decision.

4. Ask the opposite: what if it doesn't work?

Follow up with: "If we find this won't work, what will you do instead?" If the answer is "carry on as we are", that's fine. If the answer is "we'll do it anyway", the decision is already taken, and you should say so. A short premortem at this stage brings out the reasons the decision might stall, even if the project succeeds.

5. Write the problem behind the decision

Now step back from the decision to the problem it serves. Use a problem tree to separate causes from effects, then write a point of view statement: who has the problem, what they need and why it matters. This keeps the team from solving the decision-maker's preference instead of the user's problem. The sibling article how to write a problem statement goes deeper on this step.

6. List what must be true for the decision to be yes

Write the assumptions that would have to hold for the decision-maker to approve the change: users will adopt it, the cost fits, the regulator allows it, the operations team can run it. Put them on an assumption map and pick the two or three that are most important and least known. Those are your first tests.

7. Agree the decision date and the evidence

Close the kick-off with one line both sides sign up to: "On [date], [person] will decide whether to [action], based on [evidence]." Put the date in the calendar now. Revisit the line every few weeks; if the decision-maker or the date changes, the project plan changes with it.

An illustrative example

Illustrative. A public library service in a Canadian city asks its digital team to "innovate around young adult engagement".

At the first meeting, the team lead asks: "If this works, what decision will change, and who will make it?" The commissioning manager pauses, then says the honest answer is the annual programming budget: the head of community services decides each spring how to split funds between events, collections and outreach.

The team meets the head of community services in week one. She says she would move money towards outreach if she saw evidence that young adults would come to events held outside library buildings, and that she would not fund another app. That single conversation removes the app idea that had been circulating and gives the team a clear test.

The team maps assumptions, picks the riskiest ("young adults will attend a library-run event in a non-library venue"), and runs two pop-up events in a community centre and a café within five weeks. They agree a one-line commitment: "In April, the head of community services will decide whether to fund a pilot outreach programme, based on attendance and sign-ups at two pop-up events." She makes the decision on schedule.

Do's and don'ts

Do

• Ask the question before discussing any idea.
• Get a verb, a name and a date, not a hope.
• Meet the real decision-maker early, even if they are not your sponsor.
• Keep the one-line commitment visible and update it when things change.

Don't

• Don't accept "it will inform strategy" as an answer.
• Don't let the decision-maker's preferred solution replace the user's problem; hold both.
• Don't start testing before you know what evidence the decision needs.
• Don't treat a changed decision-maker as a minor detail. Re-ask the question with the new person.

Questions people ask

What questions should I ask before starting an innovation project? Start with "If this works, what decision will change, and who will make it?" Then ask what that person needs to see, what happens if it does not work, what problem the decision serves and what must be true for a yes. Those five answers shape the whole project.

How do I scope an innovation project? Scope it backwards from the decision. The decision tells you the owner, the evidence needed and the deadline. Then narrow the problem with a problem tree and turn it into one or two how might we questions that the team can work on within that window.

What if the sponsor can't say what decision will change? Treat it as a finding, not a failure. Spend one or two weeks talking to the people who own the budget or the process and come back with a proposed decision and owner. If none exists, the work may be better framed as research, with a clear end date, than as an innovation project.

Where to go next

The guides that carry this step are the stakeholder map, the problem tree, assumption mapping and the premortem. For the wider first month, read where to start with innovation in your team, and if money is the constraint, innovation with no budget.