Depending on what you do, I would say this is natural. I don't care what Henry Ford says (8 hours a day is different for some types of work than it is for others.) I can't go into "super focus" mode for much more than 4 hours per day. I can do my half day of being "wired in" and then take care of lighter tasks for another couple of hours.
There are days when working on an exciting project that I can code for 12+ hours for a few days, but not all of those hours are productive. Typically on these sorts of days I can run into a problem which I bang my head on for a couple of hours and then fix it within 5 minutes the next day after a refreshing sleep.
Maybe part of the problem is that that these places should shorten the work day (but keep payment the same.)
But I can see where your coming from. After certain set (~5) of being super-productive, you burn out. And you just can't take it any more.
At these times it is best to take a break and do something different. I've found that these breaks (~1 to 2 hours) tend to make you more productive in your next chunk. (Rather than being burn out and weary.) It gives you time to think and churn ideas for what you will do next.
Lastly I want to add; knowing what you want to do next makes a difference. When you know exactly what you want to do (the spec), you naturally are about implementing it - when not knowing the spec, you're figuring things our as you go and that slows you down. In addition it's always better to sit down and gives additional exclusive time to thinking of your program rather than figuring things out as you go.
The act of banging your head on a problem for several hours might help to kick the problem into your unconscious mind (your big brain), where the real horsepower is. And while you sleep, your mind sorts it out. That may be why you are able to fix it within 5 minutes the next day.
Rich Hickey talks about this in his talk on "Hammock Driven Development" (http://blip.tv/clojure/hammock-driven-development-4475586).
It seems to me that the idea of hyper-specialized employees is often the root of the problem. The brain needs variety.
The equation is all about maximizing user interest so that the startup acquires new one, and lowering the barrier to income. Google's business model is a reference example on this.
Regarding the difficulty to induce adoption of a new product, there is a known energy barrier for people to change their habit, even if they know their current habit is not good or optimal. This means the startup needs a strategy to overcome this initial bump. There are many. Once overcome, things get much easier.
One of the strategy is to exploit people's natural tendency to be helpful and the positive perception of generosity (kickstarter). This strategy is used in called calls. Ask for advice or help (beta user program), once in a welcomed helpful and generous mood, they'll more easily open their purse or help spread the word (dropbox).
At a regular 9-5 job, especially if you havent worked anywhere else before, you can fool yourself into believing that you create value by doing 1-2 hours of work a day (I know lots of people like this).
This is also the reason why people such a huge (harsh) change going from job to startup. You realize you werent really doing that much in your job!
Value isn't just the magnitude of the work you do. It's that multiplied by the importance of the direction you're going in. Companies are good at pointing your work in a direction that's already known to create value. One of the hard parts of a start up is figuring out a new such direction.
In a big company the machine to create value is already present and the company will create value whether you input value or not. If you quit your job, your company will carry on fine.
So essentially your value is small and by definition limited and replaceable (unless your in a small company).
In a startup the magnitude and expanse of value that you create is just so much bigger. You need to create value in different unrelated spaces - creating sales, writing code, hiring etc.
Its like comparing a rocket to a firework or better an engine to one of the cogs in its engine.
If it's just a PSA about the fact that startups are hard work, I'm not sure what new information it is we're getting here or why this post is being upvoted to be honest.
What makes something insightful isn't whether it has new information, but whether that information is connected in a new way. This qualifies because he's done a good job expressing the connection between a couple different ideas that are very important in their own right but that one wouldn't necessarily think of as being connected. (Think Euler's identity.) Granted other people have made this connection before, but what makes this a great post is that he's done it in a very simple and easy to remember way, one that provides a solid foundation for slotting other ideas into also.
I've seen developers work hard on cool features that no one needs, or are too hard to use, or meet a need better met elsewhere. These mistakes are due to not seeing from the user's perspective - and yes, I'd classify doing so as a business skill.
They won't communicate why it's worth using, see how it fits in with what people want to do, allow it to be difficult to try out (download, install, get started, learn). An easy way to address all these is ensure you yourself are a user (and representive of a sufficiently large segment of users).
I believe that if you really know what you're doing, you don't need to work very hard, placing focussed leverage on just the right point to make everything happen (caveats: 1. if you want enormous success, there'll be competition and you'll have to work hard; 2. the big problem is that we don't know what we're doing - in a sense, finding out the actual work of a start-up).
1. failure to act; inaction or neglect: They lost their best client by sheer default.
2. failure to meet financial obligations.
3. Law. failure to perform an act or obligation legally required, especially to appear in court or to plead at a time assigned.
4. Sports. failure to arrive in time for, participate in, or complete a scheduled match.
5. lack; want; absence.
I had just been thinking about how we use the word "default" so differently in programming from its traditional meaning. In programming, we think of a "default value" or a "default state", and there's really no negative connotation to the word at all.
But in many other parts of life, at least with these traditional meanings, the word "default" has a much more negative meaning. I know I often forget that.
I'm sorry I didn't say something about this instead of just posting the definition.
1. fail to fulfil an obligation: some had defaulted on student loans, declare (a party) in default and give judgement against that party.
2. (default to) revert automatically to (a preselected option).
Maybe some people don't find sitting in meetings all day to be all that satisifying. But they are stuck in it due to family expenses. Maybe they would prefer something more stimulating, if they could have the chance.
The default state of the startup should be: _fun_.
More fun than you would have by being required to show up and remain for eight or more hours each day at a corporate campus where you can clearly see people are not getting much done, but are relying on their position as a source of corporate-sponsored welfare.
To work on a startup should be a privilege for anyone who has worked in a corporate setting for any length of time.
Riding on the success of a large corporation is easy. In many cases all you need to do is show up. But that doesn't always mean you were "a success" or a part of the reason for the company's success. You may have come along after they had already succeeded, looking for an easy payout. Some people make a career out of this. They never join early stage companies. Again, there are family expenses and these motivate people's decisions.
Working on a startup is a way to be able to take full credit for whatever happens. It might be credit for failure. It might be for success. But at least you know you were responsible, and not riding on someone else's coattails.