Toggle Menu

Blog > Agile > The Real Way to Make People Feel Appreciated

The Real Way to Make People Feel Appreciated

We need to create genuine appreciation by eliminating the countless barriers between customers and development teams.

By Dan Greenberg

June 05, 2020

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).

Category: Agile

Tags: Leadership

You Might Also Like


Is SAFe Agile? The Case for SAFe

I’m new to Agile, relatively speaking. I first heard of it only five years ago....


The Transient Team Charter

In nearly any industry, the best work is accomplished by teams. The best teams are...


Cynefin 101

Cynefin is a sensemaking framework that helps teams conceptualize different types of problems and agree...