I would add health/physical debt. Many people discount the impact of those extra pounds gained during an unhealthy streak of eating. They not only put you on an unhealthy trajectory that requires a ton of effort to reverse, but they also have many hidden and side effects that unfortunately we can't measure/identify until later on. And that, I guess, is why we discount the health debt.
Gez you beat me to it! I just wanted to +1 this, in launching our company, one thing that has been killing me has been my health. I've put on weight, started drinking more, eating more and exercising less...
Today i went for a run, i think it'll make me more productive tomorrow. Get disciplined is the plan, but i'm not sure how easy it'll be...im going to write about this next week.
I posted a comment on the blog, but I might just as well begin the discussion here.
I'm working on a fun project with friends that we would love to see fly (We're applying for YC by Tuesday probably !). As a developers, I relate best to the technical kind of dept.
It's interesting to read about other kinds of depts that you will have to pay back when you deal with a startup, pre-launch, and post-launch.
Funnily, they all seem as important to keep track on.
Financial dept => game over.
Personal dept => burn out => game over.
Mental dept => burn out => game over.
Technical dept => quality/productivity freefall => game over.
Let's map them the to the assets of a startup.
Out of these four kinds of depts, 2 depend on the people and not the skills.
Financial depends probably equally on skills and people.
Technical dept being mostly skills related.
I think it illustrates well why having a great team synergy is so crucial to success.
I would argue that with how fast things are moving (and they are only getting faster), accumulating technical depts can lead you very quickly to lose customer (because you can't meet their expectation 'right now').
That can quickly lead to game over with the competition out there.
I like this concept of 'launch debt'. It's true. Moreover, some people seem to optimize their early process for fastest time to social gratification, and not fastest time to user adoption.
What I mean is, if you rush too much and release something that "isn't quite there", then (in my opinion) your user adoption will be lower until you work out all your bugs. The only thing you would have gained here is that you got to tell your friends and family "we've launched" and gotten lots of pats on the back. Your friends and family don't care about the missing polish, but the users sure will. End in the end, they are all that matter..
I think it's OK to release something that "isn't quite there" - in the sense that you don't expect to get too many users. Even with a small user base, you will gain vast amounts of information that you wouldn't have otherwise. From statistics and user feedback, you will learn lots more about what your product needs to do than if you're still in pre-launch development.