Hacker News new | past | comments | ask | show | jobs | submit login
1000 Days of User-Visible Improvements (beeminder.com)
25 points by dreeves on Nov 22, 2013 | hide | past | favorite | 9 comments



There's another PG essay that's relevant to this, "What Startups Are Really Like":

http://www.paulgraham.com/really.html

The URL is apt, since I parse it as "No, really, this is what it's like. So, really, you should do this".

Posting public updates, and having some way to commit to continuing to do so (whether it's Beeminder or something else that works for you) is something you should really do.


Post author here. We're quite serious that our startup would have failed if not for hard-committing to gradual daily improvement like this. The article quotes Paul Graham a lot, who basically claims (in How Not to Die) that if you do something like this your probability of success will be 90%. To us it feels like a transformative lifehack and we're keen to convince more startups to do it!


Having watched the Beeminder team for these 1000 days (and more), I've seen how powerful the commitment contract was to keeping them alive and growing.

This reminds me of a motivational quote: "We tend to overestimate what we can get done in a year and underestimate what we can accomplish in a decade." This is the perfect example of what happens when you just keep at it.


Very nice article, and makes a lot of sense. I would be interested to see how you apply this to apps that are only used infrequently but very intensely. It would seem that the user would not see the incremental improvements but rather drastic changes on the occasion that they use the application (web or mobile), so in that case do you lose some of the benefit from this strategy? In short, if they are not regular visitors / users then does this 'breadcrumb' method of improvement have as much weight?


I think you can still commit to one change per day, whether or not you deploy them in batches. It'd be exciting to see the growing list of stuff to look forward to, rather than wait in a void of information. Better for the team building it too. You could note in your changelog which ones are live and which are being alpha tested.


I'd say, yes, the value is almost as high, because it's not about the changes themselves (many of our "visible improvements" are bugfixes that only happen in weird cases) but about showing that you're constantly improving. It's basically a signal of the health of your company.


Even if you personally don't need the commitment device because you never get discouraged and always do what you say you will do, I'm pretty sure that the signaling value of this to users is immense. Startups die a lot and it is super discouraging as a user when your new favorite thing goes away. Promise them you won't go away.


If you had to start the commitment contract again, would you change any of the three parts of "{1} {user-visible improvement} per {day}"?


Great question! It's often been the case that we're spending most of our time on more substantial stuff, and drumming up some little UVI at the end of the day just to keep that graph happy. There were times, early on, when it felt like burdensome overhead to have to do that, but in retrospect it was very worth it to always have that constant pressure on the user-visible side of things.

So, no, we wouldn't change it. (And of course Beeminder is quite flexible so we could change the "1/day" part at any time -- with a one-week delay.)

We did recently decide to also commit to non-visible improvements (refactoring, upgrades, unit tests, etc). We're calling them infrahancements: http://beeminder.com/meta/infra and will tweet those at http://twitter.com/beeminfra




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: