Live data from Hacker News

Do Things that Don't Scale

paulgraham.com

31–40 of 223 posts

Re: Do Things that Don't Scale

#31
post #11

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.

But the domains can be divided into general classes of users. If jawbone can recruit me for it UP band then withings can also recruit me for its body analyzer. Not all startups in health segment have do its own health conscious user recruiting. There is a lot of overlap between products and I am sure there is some market for a generic user recruitment.

Re: Do Things that Don't Scale

#33
post #24

TLDR: Startups that try to focus on big launches are generally lazy. Success comes from putting in extraordinary effort to putting your customer first. This means you get super-enthusiastic users. This works by the principle of compound growth as users tell their friends. Somewhat ironically I am of the opinion that: (A) this is one of pg's best and most useful essays ever (B) it is partially more useful because it i…

I agree that it's one of his most useful essays ever.

I didn't find it particularly long, though. It would be great if more top links on HN were as in-depth as this.

Re: Do Things that Don't Scale

#35
I've been thinking about this "narrow focus" idea, and I'm not sure how to or whether I should apply it to my own idea. I'm working on building a tool that's supposed to provide a free-form way to record and organize ideas. I think it could be especially useful to writers, and I use my prototype for task tracking. But if I target it to any specific group, I'm afraid it will get pigeon-holed as a "writer's tool" or "task tracking tool" or whatever, and it will be hard to generalize from there, especially once I start adding domain-specific features. How does one usually make the transition between niche and general markets?

Re: Do Things that Don't Scale

#36
Took a lot from this essay. I've a pretty short attention span and usually drop out half way through essays this long but I read this to the end. As someone preparing to launch in a few weeks and trying to get some customers signed up for launch there was some great advice here on acquiring customers and treating them right. Thanks PG.

Re: Do Things that Don't Scale

#37
I'd be curious to know good ways to balance these various things that don't scale. I speak from a position of inexperience, but I can't imagine a fragile startup could possibly max out any of them. Given that, what are some heuristics for allocating focus across several unscalable efforts? Put another way, what are cues to focus more on one thing than another?

Re: Do Things that Don't Scale

#38

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…

“customer service is not part of the training of engineers.“

There's a huge cultural issue, its not just education. I'm not agreeing with this, but I'm going to tell it like it is, ignoring the problem isn't going to make it go away. So, that disclaimer said, "Engineering is for the smart kids, the ones smart enough not to end up working $8/hr until their call center gets offshored." "You better spend 80 hour weeks on your own time learning (trendy language of the week) or you'll end up in a call center at $8/hr until your job is offshored." "If I wanted to tell people which key is the 'any' key then I wouldn't have wasted all the time and money going to university." "I would never date someone working in the call center" "Sure its a call center, but sometimes we promote people out if they're any good" That's just real world modern business culture, and it needs to be addressed completely not "well, if we add a seminar to the engineering curriculum that'll surely take care of it"

At all companies I've work at, pretty much everyone thought customer service was the lowest possible level of humanity. Which is too bad; a mere job shouldn't define someones (self) worth as a human.

Places that claim to prioritize CS are usually just marketing, and certainly don't really mean it. If they did, their employment policies and wages would reflect it. They never do.

(edited to note, obviously this is a huge wedge a startup can take advantage of. Having someone who can speak English and expects to be rewarded financially is going to result in somewhat better service than modern international megacorp inc (bad) script readers)

Re: Do Things that Don't Scale

#39
I'm sure a lot of this is not new for some of you. I'm working on a product [1] and had all sorts of assumptions that I am revisiting after reading this.

I should mention one sort of initial tactic that usually doesn't work: the Big Launch.

This set me right. I have been obsessing over the big launch. I laughed at myself after reading this.

And on a tuesday, of course, since they read somewhere that's the optimum day to launch something.

Yep, that's me. I'm anticipating ridicule from my friends.

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.

I kept thinking that adding features was the way to keep getting more customers. My minimum viable product was a build system + share-new-version-with-beta-users. The laborious things I needed to do to acquire new customers I thought were adding new features: add a package manager, add test integration feature, add a code review tool, add iOS support, and so on. It just dawned on me that I haven't thought about the other laborious things I need to pay attention to: meet with the numerous mobile developers I know, do demos at local meetups, and constantly talk to people about my product.

[1] https://appramp.io/

Re: Do Things that Don't Scale

#40
Thanks, I needed that.

Since I haven't launched yet, I have a big file system directory (a folder) of articles on how to get initial publicity and users. While there is a lot good in that collection, it has looked to me like in total it wouldn't be good enough to get my little airplane off the ground.

For an example of the contrast, PG's essay had essentially no mention of an important role for publicity -- e.g., contact a writer at C|NET, TechCrunch, etc. for an article. Instead the essay had something that a founder could do on day one -- contact people they know and ask them to try it. Or try it for them and give them the results. And find a way to get feedback and then tweak the functionality. Good.

The essay just went to the top of my stack of how to launch. Best face validity with also the best author credibility, experience, and background of anything I've got on how to launch.

Sounds good. Write a little more software and then launch, one user at a time -- people in the family, people I knew at school, neighbors on my street, the guy I buy pizza from, the guy who repairs my car, etc.

Maybe I'll print up a supply of business cards that invite people to connect to the URL and then use the e-mail address there to give feedback!

Heck, maybe I will even be able to get some useful feedback from some VCs!

Post reply on HN