One of the teams I worked with got a new feature – a delete feature that was a new piece of functionality in part of an app. After some discussion about why (clean up, tidiness, find things that matter faster) and what (someone creates these as examples to verify results) – this new piece looked like a good thing to build for the right reasons. A quick run down of where it is and I felt like we had enough to solve the problem. The catch? This team had already decided how. A great way to squash innovation.

Immediately the team went to solutioning.

Let’s make it how the other screens work, how selections deletes were done. It was a “robust” solution – select multiple records, get a prompt, confirm the selections, display success or failures. It was a rather complex solution with states, transitions and all the error handling you could want – an “enterprise” solution …then the “what if” game started. What if two people do a delete? What if one fails? What if it’s not deleted? What if they change pages. This is what most teams do, and this is focusing on the output. Building a lot of things, covering all the scenarios. All these things must happen, so we must make a lot of things to accomplish this goal.

It wasn’t solving the customers problem, it was solving the teams beliefs. The team wanted to focus on things that might happen, that might occur … in other words, things that didn’t exist, that were not problems. Considerations maybe, things to follow up on sure, but not the problem the customer had. What I found worse about this discussion : the “solution” made the customer solving their problem way harder than it needed to be.

What problem are we solving?

I brought the team back with a simple question – “What problem are we solving?” The looks on their faces almost looked like I asked them to turn over their first born. Insisting that this was the way to solve it, I kept pressing and asked it a few times when one of the team members started to drill into the real problem, the outcome they needed to understand the behavior. It seemed like it made sense they wanted to delete a thing, but what things could be the driving force for those things? How could we setup a solution to fix the first thing, but gain insight into the whole reason for it? Now the questions were becoming interesting and going towards innovation.

Sometimes they don’t see the big red button.

A story I like to tell is about how a team I worked with years ago insisted a big, red button in the middle of a view would get their customers attention and they’d find it with ease. They didn’t interview a customer, they didn’t show it to anyone – so they no evidence whatsoever any customer would find it. After a few emails I got a customer to agree to a “prototype” we were working on and asked them to do the thing. Not only did they not find the button, but looked almost everywhere else to do the thing we wanted them to do. We knew 3 places to put it after that, and exactly where not to put it. Lesson learned.

With that lesson explained, a team member asked if they could hack something together some examples and just ask the customer “show me how you would delete a record” to verify if they would even find it. Another person asked if it made sense to create the API since it wouldn’t matter how it was implemented and they could start on it now (which they could). The conversation continued as the team began to tie the knowns, unknowns and experiments to run. Later on, one of the people came up and said it was the first time they were excited to do something inside the system. Fantastic.

It’s what separates good teams from great teams.

This exercise repeats itself over and over in companies big and small with the outputs taking priority over outcomes. I've heard a lot of the same reasons that hold them back -- the 5 monkeys experiment all over again.

“Just do like the rest of the site”

“We know what the customer wants because they told us”

“I could sell this if it did just one more thing”

This is the difference between a good team and a great team. A good team is told how to do it, a great team is told what to do and works together to solve it. A great team is honest about what they don't really know and works to validate their ideas. They take the opportunity to do something better because it is not "copy paste and iterate" it's "build different and innovate".