

1000 Days of User-Visible Improvements - dreeves
http://blog.beeminder.com/uvi/

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

[http://www.paulgraham.com/really.html](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.

------
dreeves
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!

------
dy
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.

------
phillipi
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?

~~~
bsoule
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.

------
bsoule
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.

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

~~~
dreeves
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](http://beeminder.com/meta/infra) and will
tweet those at [http://twitter.com/beeminfra](http://twitter.com/beeminfra)

