Provide Useful Feedback

The most important ingredient in a software project is timely user feedback to developers. In order for that to be effective, users and developers need to communicate well with each other. That’s not always easy because users and developers speak different languages, and often come from completely different viewpoints. From a user’s point of view, developers can be defensive and dismissive. From a developer’s point of view, users can be imprecise, incomplete, and arbitrary. This habit helps improve communications and improve feedback.

Pain Points

  • Developers are not open to suggestions or new information
  • Developers do not understand why a feature is important
  • Users feel that explaining themselves is a waste of time
  • Users feel they aren’t being heard
  • Developers feel that users aren’t giving them good information


  • Faster time to market
  • Less rework and do-overs
  • Ability to generate greater business value
  • Happier users
  • Happier developers


  • Users/stakeholders engage in open communication on important topics regarding their needs; the discussion is analytical and focused on problem solving (Major Boost)
  • Users/stakeholders will occasionally engage in open communication on important topics and attempt to engage in analytical and problem solving discussions (Boost)
  • Users/stakeholders meet on important topics but don’t apply critical thinking skills (Significant Setback)
  • Users/stakeholders rarely interact with development teams and only judge end results (Disaster)


✓ Critical ❑ Helpful ❑ Experimental

Adoption Experiment

First steps to create this habit:


  1. Developers and users schedule a demo of latest working, tested features


  1. Developers present the demo, showing what new, what’s improved, what’s fixed, etc
  2. Users ask questions, clarify, and point out potential issues (see the template for feedback below)
  3. Developers ask questions, clarify, and point out potential issues (see the template for feedback below)

Evaluate Feedback

Was communication successful? Do the developers understand what users are saying, are users able to communicate their wishes to developers successfully? One way to check is like this:

  1. After explaining a problem or a concept, have the other party repeat it back to you. Correct any misunderstandings right there

What Does it Look like?

Hello users and stakeholders, now that we’re alone, we have an important bit of information for you:

Developers typically focus on technology and logic.They don’t start with a strong knowledge of your business processes or language. The words you use that have very specific meanings to you may mean nothing to them, or mean something else entirely different.

Developers have invested hours, days, even months to create the software they are showing you now. If it’s not quite right or worse, you are effectively telling them they have wasted all that time.

We want to keep that from happening. And we’re not alone: it’s not easy to give constructive feedback in a highly technical, creative endeavor such as software development. It’s not easy with high-budget films, either. Pixar has long been praised for their working environment as they handle these and other issues. Their rules for feedback include:1

  • Feedback must be constructive
  • Criticize the project, not the people
  • When accepting feedback, do not be defensive or take it personally
  • Comments are suggestions, not prescriptions
  • Candid feedback should not be a “gotcha,” there’s nothing to prove

When in doubt as to how to provide feedback, it might be helpful to start with a formulaic approach. Here’s a simple recipe you can follow:

  1. State what you observed
  2. Explain what it means to you
  3. Describe why this is significant, why it matters
  4. Ask if they can make it better

For example, start off by stating what you observed, perhaps “Screen layout doesn’t match data/work flow” and “Too many mouse clicks.” Then explain what that means to you: “I have to learn to shuffle stuff mentally as the incoming data doesn’t match the layout.” Why does that matter, what’s the significance? “It takes me extra time to do my job. There’s a possibility of lost/garbled data. Extra clicking aggravates my carpel tunnel syndrome.” Finally, ask if the developers can make it better—and explain what “better” means in this context. “It would work better for me if…”

It is helpful to consider that developers don’t make software for users, they make software with users. Sometimes we’ll all get it right, and often we won’t. But failure or error is not the end of the world. In fact, it’s just the opposite. Identifying a problem is the critical first step in fixing it. Pixar’s CEO puts it this way:

“To disentangle the good and bad parts of failure, we have to recognize both the reality of the pain and the benefit of the resulting growth. …We need to understand failure not as something to fear or try to avoid, but as a natural part of learning and exploration.”—Ed Catmull, Pixar

The GROWS Method® is all about learning, exploration and growth. That means that discovering an error isn’t about keeping score or proving you’re smarter than someone else, it’s about learning what the software should do in order to be more valuable.

Remember, it’s not that important to get it right the first time. It’s critically important to get it right the last time. Use the MustBePresent habit to help get it right.

Warning Signs

  • The development teams you work with are isolated or afraid to share information for fear of reprisal
  • Meetings are unproductive and invoke emotional reactions rather than critical thinking
  • “Keeping score” is more important than collaboration
  • People are generally not open to new information and seem to be stuck in place, rather than continually learning and growing capabilities

How To Fail Spectacularly

  • Don’t allow developers to talk to users or stakeholders
  • Say the first thing that comes to mind when you hear something that doesn’t conform to what you expected to hear
  • Create an atmosphere of fear
  • Wait and show the users working tested features only at the very end of the project

  ←Prev (Must Be Present)(ClearBugReporting.txt) Next→

  1. Cited in [(Edmondson, 2019)

Follow @growsmethod in the Fediverse, or subscribe to our mailing list:

Sign up for more information on how you can participate and use the GROWS Method®. We will not use your email for any other purpose.