Hacker News new | comments | show | ask | jobs | submit login
Early Startup Time Wasters (talkfast.org)
152 points by icey 1905 days ago | hide | past | web | 42 comments | favorite

I've had the opposite experience with working at home vs working in a shared space. I was much, much more productive working at home (having a 'home office', aka a room with a desk and no tv was key) but I am far happier working out of a shared space where I have other humans to bond with (and whom I have become close friends with). On balance, moving into a shared space has been a great decision but I do sometimes miss the ruthless productivity that came from having absolutely zero distractions.

I came on here to say basically this. Some days, especially when I've had too much of the same atmosphere, I find that going home and working from there via remote desktop can increase my productivity, if it's maintained for a day or two. Then, when I return to my normal office, I'm similarly productive -- and both of these are more productive than the day before that I didn't work from home.

The "work from home" is definitely a "your mileage may vary"

Above all else, a commute to the office will suck all the creative juices straight from your cranium. Spending 30+ minutes schlepping through traffic each way makes the whole day a waste.

Don't drive yourself then? You chose where you live, if daily commute factored so low, well, that was your choice. I walk or get the bus depending on mood/weather. Great way to start the day.

This comment is smug rather than constructive or helpful. It might be useful the next time the poster decides to move, but it's certainly not useful right now.

I think that in a way, your comment actually proves the parent's point. As you said, "the next time the poster decides to move".

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.

But it might be useful to other people currently contemplating a move. People tend, when selecting a place to live, to underestimate how much a long daily drive will damage their quality of life.

Living and working in your parents' basement (or other ways of bootstrapping) week after week, year after year will also wear on you. And knowing how projects can fork pivot and drag on, a change of scenery is a good way to start fresh (plenty of research on how habits bad and good are triggered by environmental cues).

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.

Really? I usually design parts of the architecture in my head while driving and then go and just write them out.

That's easy to do if it's a long way on the open highway. But driving through gridlocked traffic in cities or during rush hour that isn't possible... at least for my limited brainpower :)

You could try listening to podcasts - when I was 'commuting' (i was actually walking) to work, I'd listen to something informative and interesting, so I'd arrive at work inspired every day. For example, TED talks, or web tech stuff: http://5by5.tv/webahead

I've read that at Microsoft they promote changing working place (from one office to another), because it increases productivity.

Of course, everyone's mileage varies. There are many items on that list that should be universal, though:

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.

TechCrunch is a really neat cap-feather, but it mostly just pulls in a lot of non-real-user inbound interest in my experience (VCs, potential partners) - and if you're not close to ready or even interested in funding/partnerships, all that inbound interest wastes a lot of time, too - so you might as well get closer to a point where you're ready and willing to handle the inbound queries (i.e., capture your users, make them happy first), and then get the coverage.

"Lookie-loos," "window shoppers," etc.

I have to agree with the first point of the article regarding 'Invite Only' - this has been one of the biggest headaches in all of the projects I've been involved in. It seems there is little to gain in preventing people to sign up with your app. It doesn't seem to increase interest for users and, in all reality, denying access when the visitor is ready to sign up is just not smart. Numbers count; 10,000 potential users doesn't seem to be as strong a number as 1,000 actual users.

It started with the original GMail invites and became somewhat of a mythical buzz-producing technique that really only worked for a limited number of sites. Turntable.fm is the last one that I remember learning about in a way that seemed to generate more interest.

I've been wondering that myself. I just wrote my website so that once I turn it on, people can just sign up and start using it. It just seems weird that virtually no startup does it this way.

Completely agree. On websites that are "invite only" either don't bother entering my email to get on the list, or I enter my email, get the invite five weeks later when I've lost interest (sometimes don't even know what the site is about), and delete it.

I tend to be much more productive on days when I work from home, but after a 1.5 year stretch with an out of state company I found it harder to stay focused at home.

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.

I enjoyed this post quite a lot. I'd like to see a companion post on specifically engineering time-wasters - e.g. did you find that evaluating new technologies to solve problems to be an unnecessary risk, or a pleasant surprise that ended up saving time and effort in the long run? What about the tension between "one size fits all" tools and tools that are so specialized that you need a tool to select the right tool?

Developing general solutions to specific problems is an engineering timewaster, in my experience.

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.

The way I see it, the time cost/benefit curve of evaluating new technologies and other research-like activities is considerably risky. But there's also a definite big fat tail of rewards, however elusive..

There's 2 big ones:

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

That sounds good on paper but in reality writing code for new product is based on faith. You don't know what will work and figuring that is both the most risky part of writing software as well as most lucrative (when solved).

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?

You don't have to actually have a product before you sell it, or build something to see if it will sell... It's called vaporware : a computer-related product that has been widely advertised but has not and may never become available

Don't hate peeps.

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.

It maybe worked for him but I found it hard that it can be applied to every startups

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.

6. Techcrunch 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.


I do have to say that he's talking about learning the ropes of your business, not 'time-wasters'.

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

Great advice. I know better now, but I often wonder how much time we would have saved our first few years if I auto-deleted anything that included the text "jump on a call."

This is really interesting. I'm planning my own limited invite-only beta rollout. However, this isn't the first time I heard it's a time-waster.

Does anyone else have opinions on this?

Do you really think you're going to be overwhelmed with sign ups?

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?


Don't over-engineer.

The only thing is that this is not a free service, so I want just a couple users to flesh things out and get some new opinions, before releasing something that flops and gets a bad rap.

Make a signup page to be part of the beta, include the disclaimer that it's free during the beta but once the service is publicly available it will be charged for and the fees are waived during the beta in exchange for bug reports, possible issues/downtime, etc. Then, whenever someone signs up, just automatically send them an invite. You don't limit the people who want to use it in the beta and can provide valuable feedback and you set expectations appropriately for leaving free status and to the state of the application. And if you think that you may get a bad rap for being in "beta" and it not being as good as Google's beta, just call it "alpha" instead.

How are people going to magically discover said service? Or the signup page?

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.

> This is really interesting. I'm planning my own limited invite-only beta rollout. However, this isn't the first time I heard it's a time-waster. Does anyone else have opinions on this?

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.

> 1. Invite-only access.

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.

Great list. I really like that idea of shot selection. 1000 options of what you can do...which one will yield the best results? What a tough question.

Love this post, I definitely focus on TC too much. Love seeing how to maximize press outlets.

6. TechCrunch


Thats a great list to avoid... but why not partnerships? Specially when working on a B2B platform, I believe its important to build relationships from the get go.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact