DEV Community

loading...

On getting feedback from your users

rndmh3ro profile image rndmh3ro Originally published at zufallsheld.de on ・2 min read

Some time ago I talked with a co-worker about his internal project. He was the owner of a product that tried to provide a generalized, hardened and fully codified Jenkins instance. This was done with the help of mostly Puppet and Groovy code. I was in this project for six months to help build the product and learn something there.

After three years, one complete rewrite and countless hours put into the product, it was still not finished. The acceptance rate in the company for the product as well as the project was low.

There were several reasons why the product failed. Among these were unclear scope, feature creep and end-user complexity. But the reason we mainly talked about was missing feedback from the users of the product. The co-worker had no way to check how many users downloaded or used the product, apart from the people who developed it. The only feedback he got was when something did not work. But even this feedback was rather sparse. He claimed that this was the main reason the project failed.

I argued that receiving no direct feedback from most people is normal.

I maintain some rather small (fewer than 1000 stars) open-source repositories on Github. Checking the statistics on one of these projects I see about 9000 clones and 2000 views in the past week. Yet, there are only 70 issues and 132 pull requests (excluding mine) for the whole lifetime of the project. And that’s about for years.

So why is it like this?

My projects are certainly not so good as there are no issue or things to improve. However they must be somewhat good, otherwise they wouldn’t be downloaded. Still, I rarely get feedback.

Maybe it is because most users are just this: users of your product.

Discussion (2)

pic
Editor guide
Collapse
rndmh3ro profile image
rndmh3ro Author

Thanks for your comment, Neil!

Do you mean the "Adoption rate" instead of "Acceptance rate?" Those have slightly different meanings.

Both, actually. Adoption was rather minimal outside those people who built the project. Acceptance was small as well, however I can't remember the exact reasons behind it anymore.

Based on your description, it is not clear to me that it did fail, as I do not know what the product's success criteria were.

I should have been clearer on that. The Jenkins-project was part of a larger project. The larger projects goal was to bring automation and DevOps principles into the whole companys.

The goal of the Jenkins project was that every Jenkins used in the company (several hundred) should be a "Project-Jenkins". This goal was never reached.

As for user feedback, most of what I would say is taken pretty directly from Jessica Livingston. I have practically memorized "Jessica Livingston’s Pretty Complete List on How Not to Fail," and seems to answer the concerns you are raising better than I ever could.

Thanks for that link! I'll have to reflect on her points and see how it fits!