A big part of the reason some of my open source projects were successful was that I was unreasonably responsive. I used to respond to new issues within a few hours, ideally with a fix if they were bug reports.

In fact, for react-boilerplate, I spent hours answering questions on how to use React and other tools included in the boilerplate—even if those questions had nothing to do with the boilerplate specifically.

At the time, I did this just because I enjoyed doing it. Only in hindsight, after react-boilerplate’s success, did I realize how beneficial it was—and since then, I’ve done it intentionally.

The two virtuous cycles of being unreasonably responsive

I noticed that being unreasonably responsive causes two virtuous cycles that enabled me to learn more and thus build much better solutions than anybody else. (or framed another way, get more tracers for my bullets)

1) It builds trust and thus retains users

Even if a solution isn’t perfect for their use case yet, responding quickly builds up the user’s trust that the solution will keep improving. So, despite whatever rough edges they might be hitting, there is a higher chance they will keep using it since they believe it will keep getting better.

As a great example, this HackerNews thread shows how, by simply responding quickly to GitHub issues, Wez turned two users into superfans who are publicly recommending his terminal to others on HN 🤯

2) It makes users give more feedback

If users hear their current feedback being considered (whether or not it’s acted upon!), they are much more likely to keep giving more. That, multiplied by a whole user base, means that the creators who respond quickly get much more feedback.

In react-boilerplate’s case, this was a major key to its success. Other boilerplates represented the sole opinions of their creators; react-boilerplate represented the combined opinion of every single person I spoke to about React, and I ended up speaking to a lot of them.

”Responsive” doesn’t mean you have to act on it!

Notably, “responding” doesn’t mean “acting on.” People often misunderstand this and think they have to implement everything anybody says really quickly. Nothing could be further from the truth.

Not all feedback is worth acting on, and that’s fine. You just have to respond to it with an actual human acknowledgment of the feedback. For example, these responses are great and don’t involve immediately acting on the feedback:

1. Dismissal: “Actually, the reason the feature works this way and not that way is X. Have you tried doing it this way?”

2. Postponing: “Thanks for the bug report. I’ve added it to our backlog and we’ll get to it later.”

   1. Important: when you do this, followup later once you did actually get to it.

Example: Raphael Schaad and Erik Kuebler at Cron

Cron was a new calendar app I was trying. I liked the initial version but had some feedback, so in true vigorous feedback style, I sent a bunch of it in, and both Raphael, the founder, and Erik, the PM, were incredibly responsive. Here is just one example email thread:

The result of their responsiveness? I sent in more and more feedback because I knew they were listening:

Every single one of those threads looks something like the one above:

1. A rapid, thoughtful acknowledgment of the feedback

2. A specific next step (if they were going to take one eventually)

3. A follow-up once that next step was completed

And, undoubtedly as a result of being so good at listening to (and thus getting more) feedback, Cron became the best calendar app I’ve ever used and ended up being acquired by Notion and turning into Notion Calendar—which I still use to this day.