3 ms·

Whilst I'm building signup, I realise that I probably also need reset password functionality. If a user signs up, but then forgets their password, that's a prob

Whilst I'm building signup, I realise that I probably also need reset password functionality. If a user signs up, but then forgets their password, that's a problem. But from my perspective right now, is this a nice problem to have? Actually, yes! I have zero users, but having this problem implies I would have users, which would be great. Reset password functionality is important, and will absolutely be required eventually, but I can do it later. First, I should ship anything that's stopping me from getting users in the first place. While I'm all for building minimum viable products, I would argue that a login process that does not have a password reset function is too minimal to be viable. If you're so strapped for time that you can't build a password reset form while you're building your user sign-up form, I would ask why you're bothering with building your own sign-up functionality at all. Why not use OpenID or OAuth based logins that bypass the need for building a sign-up system at all? As a user, I would be hesitant to sign up for a product that didn't have password-reset functionality, and, if I discovered that the service I just signed up for has no way to reset a password, I would probably stop using it (since I lost my password and have no way of resetting) and disrecommend it to people who ask me about it.

davnicwil 6y ago
The password thing was just an illustrative example, it's not perfect, but the point isn't that you don't need it or that not having it won't be really bad when you have users, it's that whilst you don't have users perhaps there are other things that are higher priority to build first. When those are done, reset password might literally be the next item on your list. You might end up building and shipping it before anyone signs up anyway, but in the meantime you've at least got something out there and had the opportunity of getting any users at all.
- quanticle 6y ago
  I think your approach is underestimating the reputational cost of a half-baked product. I've seen this with a few products, most recently Roam. I see a product with an intriguing concept, I try it out, and I discover there are some fairly severe limitations. In the case of Roam, it was not having a great way to export data. I then put down the product, and, in all likelihood, I won't go back. In addition, I've pointed out this limitation to several friends of mine who had expressed interest, and at least two of them have stated that it was a deal-breaker for them, and that they were significantly less likely to use Roam as a result. To go back to your point, was "lack of export functionality" a "nice problem to have"? Arguably, yes. You don't have to worry about exporting data until you have users entering data, right? But, as Microsoft found out way back when it was building Word, users won't come to your system unless they know they can get their data back out again to share with others. [1] So just like Word's market share only really took off when it was able to write WordPerfect files, I predict that Roam will remain, at best, a curiosity until they implement an export system that allows the user to take his or her notes and use them in a different application. Instead of thinking about problems in terms of what prevents users from signing up, or what prevents users from using the product, it's better to think about problems in terms of what prevents users from accomplishing the tasks this product is supposed to help them accomplish. In the case of Roam, the lack of export functionality (which at first might seem like a triviality) is actually a big deal, because the utility of a personal knowledgebase is significantly diminished if there isn't an easy way to get all the knowledge back out of it again. As a result, lots products in that space (not just Roam) suffer from marginal adoption because while it's easy for a user to sign up, it's much less obvious that the product is worth investing any significant time or effort into learning and using. [1] https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-back/ https://www.joelonsoftware.com/2000/06/03/strategy-letter-ii...
- ggggtez 6y ago
  And data security will come exactly: never. Because security is never the most important thing. A company that runs with this mentality will always be reactive, and never prepared for threats.
  - davnicwil 6y ago
    Security is foundational. It's not something to add later. Without it, signup is not done and shouldn't be shipped. Ironically, not having the reset password functionality actually reduces security bug surface area :-)
    - afarrell 6y ago
      Which is an argument in favor of leaving off some features. Don't half-ass password reset. Wait until you have the need to whole-ass it and make things conceptually-coherent.
paul_f 6y ago
One must always consider opportunity cost. Adding password reset functionality might take time away from building features that solve true end user problems. People will wait for a password reset, they won't wait if you cannot deliver true value to them.

davnicwil 6y ago

The password thing was just an illustrative example, it's not perfect, but the point isn't that you don't need it or that not having it won't be really bad when you have users, it's that whilst you don't have users perhaps there are other things that are higher priority to build first. When those are done, reset password might literally be the next item on your list. You might end up building and shipping it before anyone signs up anyway, but in the meantime you've at least got something out there and had the opportunity of getting any users at all.

quanticle 6y ago
I think your approach is underestimating the reputational cost of a half-baked product. I've seen this with a few products, most recently Roam. I see a product with an intriguing concept, I try it out, and I discover there are some fairly severe limitations. In the case of Roam, it was not having a great way to export data. I then put down the product, and, in all likelihood, I won't go back. In addition, I've pointed out this limitation to several friends of mine who had expressed interest, and at least two of them have stated that it was a deal-breaker for them, and that they were significantly less likely to use Roam as a result. To go back to your point, was "lack of export functionality" a "nice problem to have"? Arguably, yes. You don't have to worry about exporting data until you have users entering data, right? But, as Microsoft found out way back when it was building Word, users won't come to your system unless they know they can get their data back out again to share with others. [1] So just like Word's market share only really took off when it was able to write WordPerfect files, I predict that Roam will remain, at best, a curiosity until they implement an export system that allows the user to take his or her notes and use them in a different application. Instead of thinking about problems in terms of what prevents users from signing up, or what prevents users from using the product, it's better to think about problems in terms of what prevents users from accomplishing the tasks this product is supposed to help them accomplish. In the case of Roam, the lack of export functionality (which at first might seem like a triviality) is actually a big deal, because the utility of a personal knowledgebase is significantly diminished if there isn't an easy way to get all the knowledge back out of it again. As a result, lots products in that space (not just Roam) suffer from marginal adoption because while it's easy for a user to sign up, it's much less obvious that the product is worth investing any significant time or effort into learning and using. [1] https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-back/ https://www.joelonsoftware.com/2000/06/03/strategy-letter-ii...
ggggtez 6y ago
And data security will come exactly: never. Because security is never the most important thing. A company that runs with this mentality will always be reactive, and never prepared for threats.
- davnicwil 6y ago
  Security is foundational. It's not something to add later. Without it, signup is not done and shouldn't be shipped. Ironically, not having the reset password functionality actually reduces security bug surface area :-)
  - afarrell 6y ago
    Which is an argument in favor of leaving off some features. Don't half-ass password reset. Wait until you have the need to whole-ass it and make things conceptually-coherent.

paul_f 6y ago

One must always consider opportunity cost. Adding password reset functionality might take time away from building features that solve true end user problems. People will wait for a password reset, they won't wait if you cannot deliver true value to them.