In Part 1 of this blog series, I explained that high engagement is key to successful innovation outcomes.

Part 2 addressed why telling teams what to do works counterproductive. It may even repel some innovators, who then will go stealth so they can keep doing their own thing. The way to circumvent that, is to ask the right questions at the right time. Questions that make even the smartest innovators pause and realize they have not considered or know everything yet.

Off-putting lists with questions

Unfortunately, a long battery with questions is equally off-putting. Such a list does not qualify as asking the right questions at the right time. A simple test will prove my point.

Do you have a one-pager with about 7-10 questions you ask new teams to fill out as the intake form? If so, how many people volunteer to fill out this list? How many fill it out thoroughly without taking any shortcuts? And how many try to bypass this process by talking to you directly?

While I don’t know the exact numbers in your organization, I do know that these intake forms are usually not very effective from an engagement perspective. You may even consider it an effective hurdle to deter wannabee inventors who don’t want to do any of the necessary work.

However, does that make for a good start of the innovation process?

No. Asking a team to fill out a form does not fit in a process in which you strive for high engagement from start to finish.

The list is the problem, not the questions

So, what is the alternative?

Making the list shorter won’t be of much help, as there is information that you need and questions the team must consider. What more, you do want to know if a team is committed to do the work. So for the innovation process and to ensure successful outcomes, it is therefore better to ask more instead of fewer questions.

It is the list that is the problem. Because high engagement is not only about asking the right questions at the right time. It is also about giving teams the support they need to answer these questions.

Provide support to answer each question

Providing support to answer questions, what does that mean?

Take something like the job-to-be-done framework. If you ask this question, “What is the job to be done?”, in my experience you don’t get a good answer. While seemingly simple, is actually a very difficult one to answer right. In practice, most will not be able to go beyond describing what their user is currently doing.

Job-to-be-done example

However, that is not what the job-to-be-done is about. It is about the why. Why are users doing what they are doing? On our Steering Wheel platform, we use the pizza example to explain the concept. A hungry youth team at the end of the tournament day celebrates their efforts by eating pizza together. A couple, celebrating their 5th anniversary decides to go to an Italian restaurant known for their excellent pizzas. Both “users” will be eating pizza – but that is not the job to be done.

For the team, the job to be done is feed a group of hungry kids at the end of a tiring tournament. Doing this job well, means finding something fast and cheap to eat. Pizza, fast food, hot dogs, or perhaps even ice cream are all good options that could accomplish the same goal. For the couple celebrating their anniversary, none of these would be plausible alternatives for their anniversary. Their job to be done is having a nice evening together. While perhaps not completely price insensitive, cost is not a key criterion, and they are looking for the opposite of fast. They want their evening together to last! As such, for them the movies, an escape room, a concert could have been the alternatives they considered when planning their evening. The latter options clearly won’t do for the hungry team!

This example is to show, that while both users are eating pizza that is not the job-to-be-done. It also means, that if we would have grouped them together based on what they were doing – eating pizza - and provided them with a same offer both probably would have been unsatisfied. Because a solution somewhere in the middle – not too cheap and not too expensive, not too fast and not too slow – would have made both the couple and the team unhappy. It also illustrates the value of the jobs-to-be-done framework, as understanding what someone is trying to do is closely linked to the performance metrics and alternatives they will be looking for when considering a new solution.

Back to what this means for your team. So, next time you ask about the job to be done – give them an interesting video to watch. The pizza example above for instance comes from this Jobstobedone.org video. In addition, offer the team examples that are relevant to their context. In other words, ensure that your “list” with questions becomes a valuable critical thinking exercise and meaningful learning experience. In our experience, such support is a rock-solid way to engage teams.

However, did you know that all of this is still not enough to keep teams engaged or to set them up for success over the course of 2 to 26 weeks? Any idea what is still missing?

Stay tuned, I will let you know in part 4!