One step ahead: early feedback

You probably know the value of getting good feedback before going too far with an idea.

But how much feedback?
And when?
And from whom?

I like to think of it like this:

Look for feedback in layers, starting from yourself and circling out to the people farthest from you in the process — the ones who probably won't see it until it's live, but will then be using it the most.

Two examples from projects I'm working on right now:

1. QR Logging: We’ll let conference participants log their attendance at each training session by scanning a QR code posted inside each session room.

2. Permissions: We’re completely revamping the permission scheme for staff users on an existing CiviCRM site.

At each layer, we get feedback to check our assumptions before proceeding to the next.

Layer 1: "Does this sound right?"

Here we're asking people who are very close to the idea. Often it's me (the specialist) getting early feedback from the client — but not always.

• In QR Logging, once the client had explained the concept, I put some thought into it, and on our next call I explained it to her verbally, asking, “Does that sound right?”

• In Permissions, the client and I fleshed out the concept together, and then he went to a couple of his teammates and asked, “Does that sound right?”

Layer 2: "Does this look right?"

• In QR Logging, I created a minimally functional proof-of-concept, which didn't do any real logging, but demonstrated the look and the user experience. The client took this to a couple of her teammates and they tried it out together.

• In Permissions, the client and I wrote up a detailed summary of the new user roles and what each role should be able to do. He took that to a few more of his teammates for a closer look.

It's worth noting, in both of these projects we’re finding important changes to make, with every layer of feedback.

Layer 3: “Does this act right?”

• In QR Logging, I'm now creating the actual system, fully functional. The client and several of her team will put it through its paces for everything they can think of. I fully expect they will find ways that it could be improved.

• In Permissions, I built out the new user roles and assigned all the appropriate permissions. The client and a couple of teammates created test users with those roles and tried out the system themselves. They found some issues, and we fixed them, but we're not done yet.

The goal at this layer is to anticipate and fix every issue we can, before expanding to our last layer.

Layer 4: “Does this actually work?”

At this layer, we're bringing in people who are almost completely new to the idea. This is our last layer before we expose the finished product to everyone.

• In QR Logging, the client will ask a close circle of about 30 participants to use this system in real time at their next conference. That's less than 10% of the total attendees, and they're all people she knows personally.

• In Permissions, the client will ask existing system users — one for each role — to work under the new role for their normal daily tasks. Everyone else continues with their existing roles.

At this layer, we're putting the idea and its implementation to the test in real-world usage.
But we're not releasing it to everyone.
Not until we get feedback from a small set of real-world stakeholders.

Why this works:

The very best person to get feedback from
is the person who will be experiencing the new idea when it's implemented.

But that doesn't mean
we should ask all of our constituents for their opinions when the idea is still a constant.

Nor that we wait
until the idea is fully implemented before getting feedback from people in that position.

Whatever the shape of the project —
whether it's for a new training program, a new membership structure, a new software feature, whatever —
there will be phases in taking the idea from concept to completion.

By getting feedback one layer ahead of each phase,
we can get feedback that's appropriate to that phase,
while troubling no more people than necessary.

We also don't get more feedback than we can actually use.

It’s a way to stay one step ahead and check your assumptions as you go.

All the best,
A.