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

51–60 of 223 posts

Re: Do Things that Don't Scale

#51

Post by Patrick_Devine »

Even though PG didn't say it, a lot of ideas in this essay reminded me of Eric Reis / Lean Startup thinking. Getting off your ass and giving your customers rock star treatment is essentially the same as the "Genchi Genbutsu" philosophy that ER goes on about. The idea of an initial "manual" service like which Stripe provided is the same thing as a "Concierge MVP".

I have to say, as someone who left a big Fortune 500 company (which was a start-up when I joined it) just one week ago to start my own company, it's pretty refreshing to read articles such as this one. It's completely antithetical to being stuck in a large software group where you're trying desperately to have any contact whatsoever with customers to try and figure out what they want.

EDIT: spelling

Re: Do Things that Don't Scale

#52

Post by DanielRibeiro »

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…

we function exactly the opposite of how this essay suggests

Not sure if that is the case, but pg wrote last year[1]:

A YC partner wrote:

My feeling with the bad groups is that coming into office hours, they've already decided what they're going to do and everything I say is being put through an internal process in their heads, which either desperately tries to munge what I've said into something that conforms with their decision or just outright dismisses it and creates a rationalization for doing so ...

[1] http://paulgraham.com/word.html

Re: Do Things that Don't Scale

#53

Post by derefr »

pg wrote: post #13
sriramk wrote: post #7

I can think of quite a few startups that used a big bang launch with press with success. Off the top of my head - Instagram (MG's series of pieces on Techcrunch), Mailbox, Flipboard, Square, Path. I get where PG is coming from but press can help bootstrap a network effect if you have none.

One of the reasons I wrote "there may be a handful that just grew by themselves" is that every time I learn the story behind one of these apparent instant successes, it turns out it wasn't so instant. I don't know the stories of all these companies, but I do know that Instagram's launch was preceded by a lot of manual recruitment of influential users.

Would you recommend that strategy--having a quiet, unmemorable, word-of-mouth-driven initial launch (which you can call a "beta period"), and then, once you've already got some hooks into the press and a good userbase, a follow-on publicity stunt (which you can call a "launch")?

Re: Do Things that Don't Scale

#54

Post by lmm »

scribu wrote: post #33
Jd wrote: 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.

It felt like the main difference from most essays is that this one give lots of concrete examples of everything he talks about.

I'm in two minds about this. It makes it more accessible, but seems like it could divert attention away from the general point to the specific companies.

Re: Do Things that Don't Scale

#56

Post by johns »

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

"Let's try it for a few days and find out. I'll answer the calls."

Re: Do Things that Don't Scale

#57

Post by [deleted] »

scribu wrote: post #33
Jd wrote: 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.

[deleted]

Re: Do Things that Don't Scale

#58

Post by guynamedloren »

johns wrote: post #56
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." "Let's try it for a few days and find out. I'll answer the calls."

You wouldn't believe how often I've attempted to make myself available to other areas of the company that have needed help. But I was hired to write code, so I should just focus on that. ;-)

Re: Do Things that Don't Scale

#59

Post by ggreer »

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 expect an experience similar to Comcast or Verizon: Listening to on-hold muzak interrupted by advertisements. Forced to enter obscure info such as an account number on a billing statement. Getting handed between people in various departments, each time repeating answers to the same set of questions.

To your users, it's as if they called Comcast and a cable modem firmware developer picked up the phone.

Could you imagine how much you would love Comcast if that happened to you? You'd still love it if the person said, "Oh sorry, that's a bug in our firmware. We'll probably have it fixed by tomorrow. I'll contact you with an update then."

That sort of support is impossible in a larger company. It makes your users outrageously happy. Many of them will praise you publicly and tell their friends how great you are.

1. Modulo standard disclaimers, working at a small startup, etc. I also think everyone should be in the on-call rotation, but that's another can of worms.

Re: Do Things that Don't Scale

#60

Post by davidw »

> I have never once seen a startup lured down a blind alley by trying too hard to make their initial users happy.

Aren't lots of service companies killed this way? Bending over backward for some client? Maybe they are small companies rather than startups...

Guess I'm being picky though: pg's point is an excellent one.

Post reply on HN