Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do Things that Don't Scale

paulgraham.com

Post reply on HN
Print view View original

171–180 of 223 posts

Re: Do Things that Don't Scale

#171

Post by danhodgins »

blankenship wrote: post #23

PG’s point about a lot of startup founders having an engineering background is hugely relevant to this, beyond his assertion that “customer service is not part of the training of engineers.“ Systems that don’t scale, or that are reliant on the grunt work of humans, are not part of the training of engineers either. For so many engineers, an unscalable, human-dependant system is a bug, not a feature. Is it too hyperbol…

Remember, it's people who pull out credit cards to buy your product, not borgs.

People have hundreds of things they want from you and/or your company. Your product is just one of those things. That leaves 99 other things you could provide that have the potential to absolutely delight them.

In other words, what are the 99 ways BESIDES your product that you could delight your customers or make them more awesome?

Paul is right - consulting doesn't scale if you're paid to do it. But man does it make people happy if you share your time and creativity generously.

Happy people are more likely to have a higher customer lifetime value. And you can take that straight to the bank.

Re: Do Things that Don't Scale

#172

Post by tempestn »

The point about paying extreme attention to a single user's needs reminded me very much of Stop Developing for the 90% Use Case: http://gist.io/5561992, which came up here a couple months back.

Basically it demonstrates the problem with aiming for the best ratio of user satisfaction to effort in each feature of your product. If each part of what you build covers 90% of users' needs, that sounds pretty good. But if your product has X main features, the percentage of users who will be entirely satisfied is 90%^X, which gets low very quickly.

You need to focus on servicing all of someone's needs, not most of everyone's, but consequently all of no one's.

Re: Do Things that Don't Scale

#173

Post by jakobe »

redguava wrote: post #145
ggreer wrote: post #59

You should take extraordinary measures not just to acquire users, but also to make them happy. I'd like to elaborate on this point, because it's probably the most valuable thing I learned while working at Cloudkick. Similar to how every Marine is a rifleman, I think every developer should be tech support[1]. It's an incredibly easy way to please users. Many customers don't realize how small your company is. They expe…

I disagree with having developers do tech support. In fact I think it's insulting to those that are great at tech support. Tech support is a skill in itself, not just a place to let developers play. If you really care about support, you'll have people with that expertise doing it. Also, developing is really something where being in the zone gets the most productivity, and support is usually an intermittent and sporad…

We are talking about early stage startups here. I don't think it's a good idea to hire dedicated tech support people at an early stage startup.

Hiring tech support staff is for later, when the product is solid, and the developers can't handle the flood of support requests any more.

Re: Do Things that Don't Scale

#174

Post by vacri »

zby wrote: post #170
guynamedloren wrote: post #46

This bums me out. Majorly. I work at a YC startup (which will remain nameless), and we function exactly the opposite of how this essay suggests. We aren't huge by any means, but we focus heavily on scale, and suppress ideas that do not scale. Automate everything. Nothing should be manual . I'm an engineer, but I recognize the importance of fantastic customer service. While building an iPhone app, I suggested that use…

"People would be calling us constantly". Would people call if they did not have a problem with your service? This is either very pessimistic or it means "lets kill the messenger".

Having worked in support for a long time, yes. If you set too low a bar on ease of access for support, people will call you for imagined problems that could have been sorted if they spent all of 5-10 seconds thinking about it. Support is expensive. It's certainly a necessity, unless you have unimaginable resources, but you need to temper access to it. This goes double if your target audience is the general public rather than a niche market.

One classic mistake I've seen made time and time again by all sorts of companies is to think that support is free or cheap. It really isn't. It's a product unto itself.

Re: Do Things that Don't Scale

#175

Post by rahoulb »

gjm11 wrote: post #169
aw3c2 wrote: post #167

Earlier quoted context omitted.

Sorry, it was meant as constructive criticism. I guess I should have made that clear. Writing it out might help unsuspecting people like me figure out what it is all about. I could also imagine it to be beneficial for search engines. My comment taught you that I had no idea what LSAT meant and that I thought it should be explained. Now look at yours for a moment.

Here's the constructive-criticism version of your comment: "For the benefit of anyone like me who never heard of the LSAT before: it's the Law School Admission Test, a half-day test of reading comprehension, logic and verbal reasoning used by law schools in the US, Canada, and elsewhere." (More work? Maybe. But all the information there is also in the first paragraph of the Wikipedia article on the LSAT, which you sa…

I disagree; the criticism isn't about the term itself, it's that the term isn't readily explained on the site.

If, as explained, the term is widely understood by the target market, then this criticism is invalid (but caused by the poster not knowing the target market). If the criticism was valid, and the target market didn't understand the term, then the site owner knows that he/she should add an explanation.

The actual definition is sort-of irrelevant.

Re: Do Things that Don't Scale

#177

Post by edanm »

This is a great essay. But since it's long, I suspect some people won't get to the last few paragraphs, which are IMO the most important:

"The need to do something unscalably laborious to get started is so nearly universal that it might be a good idea to stop thinking of startup ideas as scalars. Instead we should try thinking of them as pairs of what you're going to build, plus the unscalable thing(s) you're going to do initially to get the company going."

As someone in the "Startup Scene" for many years, and especially as a Software Consultant, I've talked with hundreds of people about their startups. And this is probably the number one insight I wish more people had - startups are not just "having an idea" (what people used to think), they're also not just "idea * execution" (which is a great concept but incomplete). Rather, the fundamental building blocks of a startup is "what are you doing" and "how are you getting users". Almost everything else can be missing in the high level discussion, but not those two. It's taken me many years to understand this, and PG just put it in a very succint form.

Re: Do Things that Don't Scale

#178

Post by unimpressive »

dschiptsov wrote: post #163
gruseom wrote: post #144

Earlier quoted context omitted.

Fred Wilson said something similar about obsession, though in very different language: https://news.ycombinator.com/item?id=2721767 . I like that quote very much. What (if anything) are you obsessed with?

Probably it is that very Russian obsession with the naive notion that most things in the world are "not right".)

>naive notion

But aren't they?

Re: Do Things that Don't Scale

#180

Post by Nimi »

pg wrote: post #11
stephengillie wrote: post #3

Who wants to start a user-acquisition startup?

We've funded several startups doing components of that. It's hard to do in the general case. Essentially, every startup is a user-acquisition startup in its own domain, and it's hard to beat the good ones at their specialty.

I'm wondering: Maybe a consultancy is a possible solution?
Post reply on HN