Maker Story: Why I delivered Password Reset Flow only after 5 months?
Hi
I'm Stefan, Maker of Full-Stack Developer Job and Resume Board ( https://fullstackjob.com ).
I started my project on February 19. You can read a bit more about here: https://dev.to/golangch/omg-i-love-to-develop-software-how-i-built-fullstackjobcom-with-go-vue-a2i
All started with a simple listing of Full-Stack Developer Jobs. A second step was a simple Job Newsletter Subscription.
After I did some improvements I saw/got from User Feedback, Usage Analyses, etc, like better Filter Options, improved Job aggregation etc.
Then about a month ago, I release the Online Resume Builder for Candidates, also with following improvements, like privacy Settings, Contact possibility via Form for Recruiters etc. You can see a bit of the status from back then in this video: https://www.youtube.com/watch?v=QmipWffbhao
So you can see, I deliver continuously new features for the user and improve on backend side things, which I see make sense to automate.
End of last week I released an advanced Job Alert and Newsletter Feature, where Candidates for Full-Stack Developer Jobs can define multiple Filter based Subscriptions for daily/weekly Job Newsletters and Job Alerts, send as soon a new Job is added to the board.
Now... What I did only over this weekend is a "Password Reset" Feature.
Ok, there are frameworks where you have this together with Auth, etc out of the box. I use Go and no framework and do this all on my own, mainly for flexibility reasons and it's good learning.
But why I did it so late? Well. Makers do things then when they are bringing some value for the product and the users who use it. As long as I did not have so much registered users, there was just no need for this. If a User forgot his PW, I set him a new one manually (or I could, it just never happened).
But now, with the new features, I have over 200 Users and growing, so I want to give this feature out to the users and also make my life potentially easier. :-)
disclaimer:
The point is NOT to let security or other important stuff left behind, but features, which are not that important to a user or not bringing any other gain to the product. So in the mentioned case of "Password Reset Flow", this does NOT mean, that passwords are not stored securely, but there were no UI and API endpoints to do so.
Cheers
Stefan, Maker of Full-Stack Developer Jobs and Resume Builder
Stefan, good job on acquiring your user base! Passwords in general seem to be a more industry issue. I work for a medium sized business that has millions of users and you want to know their number 1 complaint? Either they cannot remember their password or cannot figure out how to reset it. Coupled with the fact that this particular industry requires two factor authentication, it's like throwing a wrench into a running motor... disastrous. Long story short, waiting to implement features because of user feedback is a great approach. You don't want to build something people don't actually want. Obviously password reset is a key feature for any account management tools but implementing a poor password reset flow could more or less frustrate users and cause them to bounce (we've seen it happen multiple times). Anything to make your users lives easier and well thought out user experiences will go a long way to both impress and keep your current user base.
Thanks for your great feedback.
Can only agree... In the company I work for as PO, doing SaaS for Telco's this is also one of the top issues with support. :-)
Sounds like the right approach to adding features