The "work from home" is definitely a "your mileage may vary"
The operative part there is that it is the poster's decision. I think most of us who have the resources to begin a startup or afford renting a coworking space also have the ability to be somewhat mobile within our local geographic area. Americans in particular are known for moving quite often.
To conclude, I think that considering a walkable or bikeable commute or the availability of public transit is great advice for anyone who is planning on moving within the next five years — which is nearly 75% of the US population.
As for schlepping through traffic, that wouldn't bother me so much if I wasn't trying to get to the office on a strict time schedule. Flexible office hours with work-from-home days sounds comparatively paradisal.
Invite-only access (pisses me off as an interested user all the time), go-nowhere "partnership" promises from other companies (I too wasted a lot of time on these dubious proposals during my startup time) and, the closely related point: "quick" meetings with people who do nothing but serve their own [and often times underwhelming] agenda.
Working from home on the other hand is probably a personal thing - some people think it's great, for others it doesn't seem to work out at all. Personally, I prefer a mixture. At home I do get a lot of things done that require concentration.
Startups are an acute instance of "too much to do, too little time". Good task prioritization might be the SINGLE MOST IMPORTANT skill that a startup founder needs to develop.
Not all failures are time wasters though -- some of the items in that list seem reasonable enough (techcrunch amazon affiliate links).
DHH said something like "If you're not working on your single best idea, you're doing it wrong". He was talking about startups, but I think that could be applied to your to do list as well.
I've found lately that occasionally varying my work location – maybe 3 days in the office, 2 at home or at a quiet cafe – is refreshing and helps me avoid the slump.
Using complicated tools and tooling where simpler tooling would cover your actual needs with less effort.
Developing a solution that attempts to meet all needs with a lot of effort, instead of developing a product that meets the needs that can be effectively addressed.
I'm guilty of the last one, so what I do is develop two solutions:
1. a solution that actually "solves" the problem with engineering (the "right" way to do it), and
2. a second approach that is an order of magnitude (sometimes a few orders) easier to implement that partially solves the problem, but requires a bit of management to stay "solved" over time.
Engineers seem to prefer engineering solutions (go figure), but especially in business, a combination of engineering and management is usually the most cost-effective approach.
1. Writing code.
2. Not committing.
You should never write a single line of code until you have a customer lined up. Not in theory, in reality. Not a friend that says it's a great idea, and they'd use your software. A list of verifiable people that you don't know that want to pay you money. Someone that can write a check at BigCo. Someone that is beta testing your product live.
On commitment, cue the joke about pig & chicken opening a ham & eggs restaurant: The pig says no thanks, he'd be committed, the chicken would merely be involved. This kind of ties in with #1... If you don't have an actual paying customer lined up, it's really easy to get involved in "side" activities... I'll just bust out this contract real quick... Sounds like a cool company, I'll go interview (especially bad when it involves samples).
And the only way to find out if something will sell is to build and try to sell. The method you advocate (get sales before you have a product) just doesn't work.
"A list of verifiable people that you don't know that want to pay you money"
How do you propose to "verify", or even find, people that you don't know?
"Someone that can write a check at BigCo."
Would you write a check for something that doesn't yet exist? How do you know, from just a description of the product, whether it's going to be moral equivalent of Vista (a massive flop by Windows standards) or 7 (a massive success)?
You don't, which is why no one pays for ideas or description of future products.
"Someone that is beta testing your product live."
That does require that code has already been written, doesn't it?
It's called "Minimum Viable Product" now, but 15 years ago we called it vaporware.
The canonical MVP strategy for a web application is to create a mock website for the product and purchase online advertising to direct traffic to the site. The mock website may consist of a marketing landing page with a link for more information or purchase. The link is not connected to a purchasing system, instead clicks are recorded and measure customer interest.
That is how you get sales before you have a product... Or at least know that you'll get sales.
1. Invite-Only Access. Depending the service your startup offer ( Storage & bandwidth heavy ), you will have to offer to do invite only because you can't just spend all the money you don't have on this. Invites will allow you to control the cost of it all.
2. & 3. Real-time traffic measurement & User admin dashboard
Those are the only one I agree :)
4. Experimenting with ads too early.
Using ads early can be a really asset. For example, It can allow you to A/B test some new messages or value proposition. It can also help you see if you product can appeal to a certain niche by hyper targeting your ads ( Does 20-25 old people living in New jersey and who likes Soccer and BBQ will be interested in my product? )
5. Amazon Affiliate links
I think its great he took the time to try it out. The goal is not to make loads of $$ with "a few thousands uniques/day" It's to see the conversion rate. It didn't work out in his case so that "business model idea" he can write off of his list.
TC offer you so much more than traffic & SEO. It will be let the world you exist to important people ( angels, VC, etc )
7. One-off partnership projects.
His experience isn't a good one. Probably didn't negotiate hard enough with his partner. BizDev / Partnership can bring tremendous traction to your startup if done right. Just don't get screwed up by the other guy and don't waste time "building a prototype" for him without a signed contract.
8. coffee Meetings
Sure the productivity can take a hit if you do it "too much". But think about the social aspect of it. Wether it with coworker or external people to network. it will help build a strong relationship.
9.Excessive side projects
As a manager you have the duty to keep everyone happy and productive. The coders will always have side project. Better to have them work on a side project for your company and under your supervision than to pissed them off and make them work on the side project during the Weekend.
10. Working from home
Working in an open space can be a pain in the ass for some people. Because people will interrupt them all the time because of a bugs / ideas / whatever. If they are to introvert to say no, their productivity will go down the drain. So better for them to work some times from home to be truly focus on their work.
An example for me would be that we have one area of business where we organize events. In order to attract attendees, we tried Google Ads, Facebook ads, email blasts, flyers in popular locations/stores, newsletter ads. None of it worked, or it barely worked. By year two we figured out that for our market, postal mailers worked like crazy. Sending a letter to the prospects home gave us super ROI.
Do I wish I'd known that at the beginning? Yes. But it took going through all of those other methods to hit on the one that worked, which gave our company domain knowledge.
This is really just a version of the business axiom 'Fail faster.'
Does anyone else have opinions on this?
Simple beta: Add 'we're in beta' to your sign up page.
Invite-only: don't link the signup page to the rest of the site. Add it to the ignore in robots.
Anyone who finds it, well they just wanted it enough. Too many sign ups? Take the page away. Get rid of the template page, whatever. It takes about 10 secs to kill a page in most languages without a redeploy.
Writing lots of extra code?
You seriously don't have to worry. And if your service is so amazing and wonderful that people are frantically sharing your signup then you have a very good problem to deal with.
Even then you can shut it down in an instant and even (shock, horror) email the people who you don't know and tell them you're really sorry but you're disabling their account because it's a private beta. And you'll let them know as soon as it's live. And they can get immediate access then.
Because if you're sending out invites you know who you sent them out to right?
As for it being a paid service, make it clear on the signup page it's free now but you'll be charging for it as soon as you're out of beta. No-one;s going to complain. Give a rough price if you feel like it, but make it clear it's rough.
You're making a mountain out of a molehill here.
Yes. Don't do it.
One of the biggest problems you're going to have at the get-go is finding people who actually give a shit about your product/service. Adopting an invite-only system attaches a huge negative filter to this problem: you are making it more difficult for prospective users to discover and use the product.
There's one very important caveat to this:
If you are relatively well-known and already have a large number of people following your blog, twitter or other web presence a invite-only system can make sense. Google can do invite-only because they can command millions of eyeballs through a simple press release. You are probably not Google.
When you are a somebody an invite-only system feels like an exclusive club that can create buzz & desire. When you are a nobody an invite-only system feels arbitrary and frustrating. You are probably a nobody.
I did not have invite-only access but I did promise beta access on https://linkpeek.com
I spent a bunch of engineering time writing beta only code. Offering beta did give me some extra exposure and a pretty large list of email addresses. I think a "tell me when you are ready" textarea might have been more worthwhile and would have better turn over.
The programming logic to support beta (free) users adds to the complexity of the website's codebase.
In short, for me it seems like a time-waster. I didn't need testers after all, my software and service was pretty solid.