The Real Way to Make People Feel Appreciated

Feigned Appreciation

A few years ago, I was working with a Product Owner who was struggling to make her team feel appreciated. I suggested she thank the team for the product they were delivering. Her response fascinates me to this day: she felt a “thank you” would come off as disingenuous and patronizing.

A Genuine Thank You

Why does that fascinate me? Let me try and illustrate with an anecdote. The other day, I went for a ten-mile hike in 100+ degree temperatures and when I got back to my car, there was a guy in the parking lot hawking ice cold bottles of water for a dollar. I purchased one from him and thanked him as he handed me the bottle. I can assure you that my “thank you” was not disingenuous or patronizing. Quite simply, that was an example of a customer genuinely thanking a provider for a product that the customer asked for.

Who Asked for This?

So, what does this have to do with a team feeling appreciated? Well, that Product Owner was not going to be using the product the team was building; she had no personal interest in it. In fact, the product was the brainchild of her boss but her boss wasn’t going to be using the product either. He was simply trying to come up with something that his boss might want (who also, by the way, was not the end user).

This is a far cry from the scenario where a person or team hands a product directly to the person who asked for it. It’s no wonder that team didn’t feel appreciated. There’s no guarantee that what they were building was something that anyone wants!

Stop Me If You’ve Heard This Before

My recommendation is that we eliminate these countless barriers between customers and development teams. Instead, shift to a model whereby:

1. The customer explains their problem directly to the team.
2. The team goes off and develops approaches to solving the problem.
3. On a regular and recurring basis (every week or two), the team checks in with the customer, shows them what they have, lets the customer toy around with it, and finds out whether the product is solving the customer’s problem.
4. At any time, when the customer either has what they need or has lost all confidence in the development team, the development team should be relieved of its duties and deployed to another customer (or, potentially fired altogether).

Funny, I’m not the first one to suggest this “model” – (for more, see Scrum).