20 Questions to Ask Your Innovation Team

What are the 20 questions to ask an innovation team?

They are the primary questions a sponsor asks at each stage of an innovation team’s work, from my book Enquire to Inspire: five to learn whether the problem is real, five to learn what the evidence means, seven to decide how the work scales and who owns it, and three to close the work well. Ask them in order. The team’s answers, not yours, are the point.

Why questions, and why these

Have you ever worked for someone who asked you to do things they were unwilling or afraid to do themselves? Most innovation teams get that treatment: a sponsor hands over an idea, a budget and a deadline, then waits. The team builds. The customer shrugs. Everybody learns the expensive way that nobody asked the obvious question early enough.

The twenty questions below are the obvious questions, in the order a team needs them. I did not invent the stages; every innovation team walks through them whether anyone names them or not. What I learned from more than 50 teams (as of 2026) is that the sponsor who asks these, and then keeps quiet long enough to hear the answer, gets a very different team than the sponsor who tells. Managing people limits them. Mentoring expands them.

One warning before the list. These are questions to ask the team, not questions to answer for it. If you already know the answer, you are not enquiring; you are checking whether they agree with you. Different sport.

Stage one: is the problem real? (Chapter 4)

The chapter question: “How do you know?” The team has an idea. Your job is not to judge it. Your job is to find out whether anyone outside the room has the problem it solves, and whether the team knows the difference between what it knows and what it believes.

1. “What problem are we here to solve?” Agree on why the team exists, at least until the team learns something different. A problem is a pain, a passion or a job to be done, felt by someone with the desire and the means to fix it. “The customer lacks our product” is not a problem.
2. “Who is your customer?” The person whose life gets better or worse when the problem changes. The business is never the customer, even when the problem is a business problem. Find the human beings whose motivations and behaviors sit at the center of it.
3. “What is your theory of customer value?” Value as the customer defines it, learned in the moments before, during and after the problem shows up. Press on: How do you know? What behaviors have you observed? How have some people solved this for themselves?
4. “What do you need to learn?” Separate what the team knows from what it thinks it knows. Map the customer’s experience, find the gaps, turn them into assumptions, and test the riskiest first. Make them eat their vegetables first; the easy, low-risk tests are always tempting.
5. “What resources will you require?” A prioritized backlog of assumptions lets the team look ahead: what each experiment needs, what to do if it cannot be had, who secures it and by when. Be clear about what the team expects of you, because not every need is yours to fill.

Stage two: what does the evidence say? (Chapter 5)

The chapter question: “What does it mean?” Data is not insight. This stage is where a team looks at everything it gathered and admits what it means, including the parts that contradict the idea everyone loved in stage one.

6. “What have you learned?” A complete, visual share-out of the team’s data on the customer maps it built. Blind spots show up here. When something was missed, find out why: unable, unwilling, or a bias at work. That is a teachable moment, not a scolding.
7. “What does it mean to your understanding of value delivery to the customer?” Connect insight to opportunity. Customers get value if we deliver it in what ways? The answer points at the riskiest assumption to test next.
8. “How have your beliefs around customer, problem, and theory of value changed?” Go back to question three with the evidence in hand. A team whose theory has not changed at all has probably not looked hard enough.
9. “What has surprised you?” Surprises are the dividend of a bias-free search. If there are none, ask how the interviews and observations were designed, and whether the team gave customers room to say the unexpected.
10. “What is your recommendation for the next step?” An evidence-based story of the customer, the problem and the solution space, then a recommendation to the people who decide. Timing, budgets and executive preference can still shelve it. Keep the team grounded in the one thing it controls: the quality of the work.

Stage three: can it scale, and who owns it? (Chapter 6)

The chapter question: “Where do we go from here?” A prototype that works for twenty customers is not a business. This is the longest stage because it holds the questions teams most want to skip: whether the company can and should build it, and when the team has to let go.

11. “What about viability and feasibility?” Desirability is documented by now. Feasibility asks whether anything legal, technical or financial makes it impossible; viability asks whether it pays. Watch how ‘feasible’ blurs as the prize gets bigger.
12. “How does this fit into our current business model?” Map the similarities and differences with the models the company already runs; the differences carry the risk. Rehearse the questions leadership will ask. A Business Model Canvas keeps the learning in one place.
13. “What critical assumptions do you have regarding the path of scaling?” The same discipline as stage one: list the assumptions, rank them by risk, test the riskiest first. Include the manual shortcuts inside the prototype, the ‘technical debt’ that will not survive volume.
14. “How will your value proposition have to change for a larger market?” Low-fidelity prototypes are hand-made, and the hand-made touch may be part of what customers valued. Scaling means understanding the needs, and the wants on top of them, deeply enough to replace that touch without losing the value.
15. “How will you pull in additional resources as you test scale assumptions?” Growing the team is a project of its own. Agree on the ground rules before the new people arrive, starting with where the core team airs its disagreements. My favorite team nearly met its Waterloo here.
16. “At what point does this team transfer ownership of this product?” The hard conversation. Finishing may sit outside the team’s competencies, in IT or in sales, and the stakes are bigger than egos and ownership. Name the handoff point before the last mile.
17. “What are your critical assumptions around final transfer?” Expectations, assumptions, outcomes, key players, timetables and responsibilities, mapped with the receiving unit. You monitor it, because the team may disband before it can. Too many great projects get lost in transition.

Stage four: close it well (Chapter 7)

The chapter question: “What do we do for an encore?” Teams are people, and people need an ending. The last three questions are about what the team learned about itself, how the work gets seen, and what comes next.

18. “What’s working well for this team?” The final retrospective. A tool for the first day and the last, it lets the team talk about its own culture and whether that culture is serving or enslaving it. If they want to run it without you, let them.
19. “How do we want to celebrate and publicize the team’s accomplishments?” People are not machines. They need rest, recognition, belonging and closure, and companies forget all four. If your team does great work and no one hears about it, does the work matter? This one we know: it does not.
20. “What will this team tackle next?” Closure comes easier with a new focus. Ask what their dream project would be, or offer a slate from leadership’s strategy backlog. Great teams are ambitious, even brashly so. Feed that.

How to use the list

• In order. Stage three questions asked in stage one produce confident answers about a customer nobody has met.
• Out loud, with evidence. The team answers; you listen for what is missing. Interview notes, observed behavior and experiment results count. Opinions, including yours, do not.
• Then wait. The silence after a hard question is where the thinking happens. Count to ten before you rescue anyone.
• Write down what you heard. The answers to questions three, eight and thirteen should change over time. If they do not, the team is not learning; it is reporting.
• Get help asking. If nobody in your organization is used to enquiring instead of instructing, that is what a coach is for. A coach leaves you able to ask these yourself; the 3-Hour Innovation Plan walks one idea through the first two stages in three sessions.

The book gives each question its own section: the secondary questions behind it, the tools (customer maps, the adoption curve, the Business Model Canvas, the retrospective), the stories of teams that got it right and wrong, and a Sponsor Focus recap at the end of every chapter. It is 106 pages, which is about the length of a single sponsor meeting done badly.

Frequently asked questions

Do I have to ask all twenty questions?

No, but ask them in order, and do not skip a stage because the team is eager to build. Most failed innovation projects skipped stage one or stage three. The questions are short; the answers are where the work is.

Who asks the questions, the sponsor or the coach?

The sponsor owns them. A coach can ask them in the room and help the team learn how to answer, but the point of the book is that the person who funds the work learns to enquire instead of instruct. Managing people limits them; mentoring expands them.

What if the team cannot answer a question?

Then you have found the next experiment. An unanswered question is not a failure; it is the riskiest assumption announcing itself. Ask what the team would need to learn, and what the cheapest way to learn it is.

Where do these questions come from?

They are the twenty primary questions in Enquire to Inspire: 20 Questions to Mentor Your Innovation Team to Success by Bill Murray (FifthWhy, LLC, 2023), chapters four through seven. Each chapter in the book adds the secondary questions, the tools and a Sponsor Focus recap.

How is this different from a checklist?

A checklist is answered by the person holding it. These are answered by the team, out loud, with evidence, and the sponsor’s job is to listen for what is missing. Ask the question, then wait longer than is comfortable.