Bug reports and feedback from the people who use your product become work on your product. When the fix for a problem someone reported has shipped, that person hears about it, in an email that says so in plain words.
What you get
You get a loop that closes with the person who opened it.
Most products have a quiet gap between the user who reports a problem and the team that fixes it. Someone takes the trouble to describe what went wrong. The report is read, the fix is made, the release goes out. Then nothing. The person who found the problem never learns that their message mattered. Next time something breaks, they shrug instead of reporting it, or they quietly look elsewhere.
Here is what changes:
- Your users’ words reach the work. Bug reports and feedback from your product’s own users become work on your product, instead of waiting somewhere for someone to get to them.
- The person who reported it hears the ending. When the fix for a problem has shipped, they get an email that names the problem they reported and tells them the fix has shipped.
- You keep the say over what ships. You decide what ships. Nothing reaches your users without your approval. A fix your user asked for goes out on the same terms as any other change, so the email describes something they can already see.
The direction stays yours as well. You set the direction. We carry the work through to shipped software. Your users’ reports add to what you know about your product; they do not take the course out of your hands.
What it looks like in practice
Suppose a customer of yours reports that the “Download invoice” button on their account page does nothing. They describe it in a sentence, a little annoyed, and expect to hear no more about it.
The report becomes work on your product. The work lands in your own code repository, where your team can read the change that repairs the button. You approve it, and it ships.
Then the person who reported the broken button gets an email. It names the problem they reported and tells them the fix has shipped. They open their account page, press the button, and the invoice downloads. The next time something looks wrong, they report it again, because last time somebody listened.
For a product leader, this keeps the voice of your users close to the product without turning you into a switchboard. For an engineering leader, a reported bug has a visible end: the fix ships, and the person who found it knows. For a founder, early users who hear back have a reason to keep telling you what they see, and that candour is hard to come by any other way.
Where to start
Start with a small first piece: take one problem a user has reported, and judge what it is like when the fix ships and the person who found it hears back.
