I made it to the end of the book. God I love Beeminder so much!
Here are my notes:
- There are no small changes. Everything affects everything else, including documentation and support. The work involved in actually changing the code is the tip of the iceberg.
- Getting some functionality for free is like getting a free pet, ie, expensive.
- Beware the fre-cently bias (overweighting things you hear frequently or heard recently). I.e., discount the whims of a small sample of vocal users.
- (Plenty of obvious things like not doing trendy shit.)
- Sprinkle some Quick Wins in your roadmap so there are never long periods where customers feel the application has been abandoned. (Could call it the Anti-Cobweb Principle? See Trevor Blackwell’s footnote in our UVI blog post. This is a way bigger deal than people appreciate, in my opinion.)
- They make a pretty good, if self-serving, argument for in-app messaging – the time when users care about new features and tips and such is when they’re using your app.
- Don’t be afraid to say no to feature requests or even to kill existing features.
There’s obviously more than that in the 60-page book but I think a lot of it was not advice I needed (or needed so badly that I didn’t recognize it?). So, if you’re sufficiently like me, then hopefully I have saved you a lot of time by distilling the book into those 7 points!