We started this month with a significant milestone in our project. As I've mentioned before, after a year of research, it's crucial to put our ideas into practice and test them. We need to make things much more concrete.

We're starting one of our first user tests today. I had previously thought through this entire session in my head - that was n=1. Then we went through it in detail with the team, bringing us to n=7. But today, we have our first actual users who will go through the entire run-through in a day-long session.

Problem or User driven hypothesis for testing?

I know, I know... we should only be testing one element, but we couldn't decide where to start. We discussed what our we needed a hypothesis or test-goal. Our first testgoal was; "When users are extremely engaged with a challenge it provides a great reflection and learning opportunity. So we want to test where we find the biggest correlation between an out of your comfort zone challenge and the engagement of the user." In short, we wanted to discover potential learning zone's.

With hindsight this was still testing our idea, maybe we should have written down a more user driven hypothesis like; "We believe that managers are most easily triggered by an element of competition, and the need/want to compare themselves to others on how well they are doing."

If, This, Then, That, Else

We translated this using an IFTTT statement; "IF a user is extremely challenged THIS will get them out of their comforts zone THEN we will observe more natural leadership behavior THAT we can use for self-reflection ELSE we will fall in the trap to start explaining new tools in stead of experiencing the much needed mindset-shift."

Prototyping one element or a quick & dirty version of the entire runthrough?

So we've opted for a full day run-through, with the plan to identify the element with the most traction during the reflection (while still accomplishing a good portion of our mission). For this test, we have a diverse group - a designer, an anthropologist, a data scientist, a coach, and a strategist - who will tackle various challenges during the session. I've decided not to provide any direction, wanting to conduct an extreme experiment in self-organization and motivation while observing how they handle the different challenges.

I'm not sure if this is the smartest approach, but it feels right to put ourselves completely in the hands of the users. They found it extremely difficult, which was part of the plan. I wanted to see how they would cope without guidance. It's a bit nerve-wracking, but also exciting to see our ideas finally being tested in a real-world scenario (and ofcourse nothing is going accord=int to 'plan).

Building the bridge while crossing

What was it that management guru Robert Quinn called this? Ah yes, "building the bridge as you walk on it." That's exactly what we're doing today. It's a big step forward, and regardless of the outcome, I know we'll gain valuable insights that will help shape our project moving forward. Here's to taking a daring leap and learning from them!