Do Things that Don't Scale

http://paulgraham.com/ds.html

by allang • 13 years ago

1275 207 13 years ago

paulgraham.com

aaronbrethorst• 13 years ago

stephengillie• 13 years ago

Who wants to start a user-acquisition startup?

Felix21• 13 years ago

Acquiring users for other startups? Is that the business model you envision?

dangrossman• 13 years ago

https://elasticsales.com/

pg4• 13 years ago

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.

dominotw• 13 years ago

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.

Nimi• 13 years ago

I'm wondering: Maybe a consultancy is a possible solution?

omegant3• 13 years ago

It sounds more like a consulting company than a startup. Then, I suppose it would end being an startup..

petercooper• 13 years ago

Upon seeing those words, I realized that's what a lot of media startups are. For example, my companies runs a variety of e-mail newsletters and most of our advertisers are other companies looking to acquire users/customers. We've had advertisers run a single ad with us and pick up 1000 e-mail addresses on their landing pages, etc. That seems quite close to a practical user-acquisition startup even if the intent isn't there.. It does give me some ideas on extra ways to sell the value to potential advertisers though(!) :)

krmmalik• 13 years ago

The elasticsales link looks interesting. I've heard alot of people have had good results from betali.st

Though i submitted my startup over 2 months ago and havent heard anything back.

anandkulkarni• 13 years ago

https://www.leadgeni.us

jayzalowitz• 13 years ago

PG: Do you see any other things founders typically think are going to scale and don't? (not-quite-unlike conferences)

sriramk3• 13 years ago

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.

tptacek• 13 years ago

Almost anything can help "bootstrap a network effect"; if you have a real network effect offering, every user you gain, no matter how laboriously and no matter how marginally, helps the snowball get bigger.

The point the piece is making is the difference between the actual value of launch publicity (marginal) measured against the typical founder conception of the value of that publicity (enormous).

I've "launched" a bunch of stuff in my career and that part of Graham's piece rang especially true to me.

sriramk3• 13 years ago

How do you measure that difference or, rather, how do you challenge the founder, who is arguably the best person to measure that? I've seen several founders attribute success to some critical piece of launch PR (often a big publication article).

Here's an esoteric example (I have a few more of these) - Qik's founders believe many years later Scoble's coverage of them was the reason for their launch being successful. http://techcrunch.com/2012/11/03/qik-started-in-a-garage-dis...

Or the Warby Parker guys attributing their launch success to Vogue covering them (something I know they deeply believe to be true) http://mashable.com/2013/03/07/toasting-success-warby-parker...

pg4• 13 years ago

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.

sriramk3• 13 years ago

Agreed - I don't think any of these should be used in isolation. But Kevin Systrom would tell you that recruiting photographers and influencers helped with launch because when that TC piece hit, everyone saw influencers/early adopters were already on the app, leading to a feedback loop with more 'influencers'.

derefr2• 13 years ago

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")?

ronilan• 13 years ago

When asked if he would like condensed milk or honey on his bread - Winnie the Pooh said "Both, but never mind the bread".

Dropbox went to YC and to TC 50 and did "double-sided affiliation" and has a great product and and and... etc.

chubot• 13 years ago

But the TechCrunch pieces aren't the reason Instagram suceeded. There are plenty of companies who got TechCrunch coverage that failed (most of them).

I read stories about the Instagram founder doing a "bar test". He would show people his app in a noisy bar, with half of their attention. If they couldn't figure it out, then the app was too complicated or too hard to explain.

He also had some very unscalable experience at previous Stanford company (don't remember the name now).

The press can only explain the a product -- it doesn't make the product fit the market.

danmaz74• 13 years ago

But how many of those were really "initial" launches vs. a big launch after you already did a lot of legwork (while in closed beta, for example) and the planets were already well aligned?starting to wonder

pseut• 13 years ago

IIRC mailbox was a pivot from "orchestra todo," an iphone collaborative todo app that won awards on its own. You might want to check that your other "big bang launch" examples really fit that description.

thejteam• 13 years ago

I was watching a presentation the other day and heard a relevant story. It was about one of the early internet companies during the first dotcom boom. It was a change of address service. You would input your information and the services you needed to cancel and/or change the address for and it would handle it for you. This was in the early days of the consumer web, so none of these companies had APIs for this company to call or even thier own web forms. This company processed its early orders using old ladies at typewriters and fax machines.

I really wish I could remember the name of the company, but theyr were acquired very quickly for a stupidly large sum of money.

fbuilesv• 13 years ago

This reminded me about Joel Spolsky's Strategy Letter III (http://www.joelonsoftware.com/articles/fog0000000052.html), where he talks about a company called PayMyBills. PayMyBills would handle the user's bills and send them electronic reports of the bills each month.

Their strategy required the user to manually call each service provider to change the physical address to PayMyBills' so they would receive all the paper and process it. This created huge barrier of entry (who wants to call every single provider to change their address?). At the same time, if you end up signing up you're likely to stay in because of the time it took you to go service by service to change your address again.

FWIW I don't know what happened to PayMyBills but today their site redirect's to one of Intuit's service.

sethbannon• 13 years ago

PG, can you give a couple examples of enterprise startups that took the "consulting" approach to establishing successful (largely productized) businesses?

slaxman• 13 years ago

37signals is one of them. They were in the software consulting business and built applications for in house use to manage their projects. They later realized that their clients need those applications as well.

I believe tumblr was a side project as well while the founder was consulting

jorde• 13 years ago

I think this isn't what Seth meant: there's a lot of consultancies turned into product companies but it's different to start running a startup and then to work with your clients to find product market fit etc.

I would also be interested of examples

peteforde4• 13 years ago

"The Perfect Store" is a book about the early days of eBay. The primary takeaway for me was how they deliberately went to swap meets, flea markets and garage sales all over America — especially the rural flyover states — and talked to people. They identified the key influencers and flew many of them to California to be given VIP treatment. Those folks returned to their communities as true believers and encouraged their flock to get on the train. 15 years later that investment paid off more than any of them could have hoped.

That said, I suspect that there are many founders who would be open to taking the show on the road. It's incredibly daunting to know what that looks like, or where to start. I feel like it's not laziness, just unknowable to people used to tech communities and test suites.

To that end, my friend Ted and I think we've figured out how to help these founders take the leap and get in front of real people. Those people might be clients, developers or community leaders.

If you're interested in what we're doing, let me know. I'm happy to answer any questions you have, here.

And if you need help with hard problems, you should definitely call Ted: http://usistwo.com/

cpursley2• 13 years ago

"I suspect that there are many founders who would be open to taking the show on the road."

I think this should be taken literally by many startups with national scope. Get the hell out of California, buy a used RV, stick the team in it and travel city to city while you build the startup. It's cheaper and you'll be able to meet more customers.

peteforde4• 13 years ago

Well, yes: exactly.

I guess you could say that my current "startup" is helping founders do exactly this. Specifically, the exact part that happens right after you concede that it's a potentially great idea and right before you have any idea how to make it happen.

Where to go, who to talk to, and why.

You can follow the origin of the idea starting here: http://reedwordsinamerica.squarespace.com/blog/2012/12/17/th...

forsaken2• 13 years ago

Thanks for this comment. It led me to read the entire website that you linked. On a page I found a link to The Man Who Planted Trees.

I was walking across the country recently on the Pacific Crest Trail, and I had to come off the trail because of an injury. I have been looking around listlessly at the world, and trying to figure out what to do.

This video has struck me in an interesting way. It shows someone who is true of heart can find happiness in profound ways. It has also helped me re-imagine art, as the man painted the landscape and changed the feeling of a region.

It is a beautiful example of the change a single person can make.

Earlier today, I was tempted to tweet "What would a present day John Muir look like?" -- Interestingly I found an answer by another avenue.

peteforde4• 13 years ago

I keep a short list of videos about inspiring creatives. I might be mis-reading your comment, but I will share them, anyhow:

Painting Coconuts: http://www.youtube.com/watch?v=XQxOKtCWEGE

The Knife Maker: https://vimeo.com/31455885

The Inverted Bike Shop: https://vimeo.com/36258512

Pins and Needles: https://vimeo.com/57247225

The New Wave of Barber Shops: http://www.youtube.com/watch?v=7gpm54WIyZk

jfoster2• 13 years ago

It's almost like going from writing code all day to running a political campaign, isn't it?

peteforde4• 13 years ago

I'd say it's much more like going from jamming on weekends with your friends to writing and recording an album, then taking it out on tour. You have to line up radio promotion, online fan community building, potentially a video or three, magazine interviews, contests, backline... you can't just do one thing and expect everything else to fall into place.

Every band is a complex business that has to get really good at managing multiple moving parts while entertaining people with great songs.

akshat• 13 years ago

"But (like other ways of bestowing one's favors liberally) it's safe to do it so long as you're not being paid to."

We at blogVault love the above line. We often have our customers ask us for help with things completely unrelated to what we do. However, we always refuse to be paid for it. We always tell them that we are in the business of backups. Everything else we will help out but could not accept any payments for. It ensures that we don't have to commit to deadlines etc.

PanMan• 13 years ago

Great article. I also like Dereck Sivers post on manual work: http://sivers.org/hi doing things that don't scale

cpursley2• 13 years ago

Yep, a classic.

blankenship• 13 years ago

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 hyperbolic to say doing things that don’t scale runs counter-intuitive to an engineering mindset? (I’m a left-brained, analytical, systems-minded designer, so I’m definitely not trying to throw stones at my peers.)

VLM• 13 years ago

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

derefr2• 13 years ago

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.

There's a specific discipline within Engineering, of people who put together technology with employee training manuals, company policies, and sometimes even incentive structures which bring into existence entire markets, to make sure a process is carried out. These people are called Systems Engineers.

A typical Systems Engineering problem: design a satellite launch mission. Piece out the work, the calculations, the part sourcing, the safety checks, etc., so no part (human or computer) will malfunction or "jam" without a redundant backup being ready to take over. Make sure all work and outputs have been checked. Make sure all people, parts, and processes for doing the checking have been checked, and are regularly maintained. And make sure all relevant processes are adaptable to changing demands in the future, so this mission design can be reused to build and launch another satellite, later, even if we don't have the same companies to source parts from, or the same employees, or even the same satellite. Make sure all this making sure continues to happen after you're gone, without anyone in particular needing to keep the whole thing in their head--because that's way above tolerance for an average human "part" in your System.

A Systems Engineer's work, especially at the prototyping phase, involves just as much talking to and convincing customers and partners, providing training and walking through use-cases, as it does writing code or doing calculations or building models.

You might have guessed where I was going with this. Start-ups are indeed Systems Engineering problems, and really, they need Systems Engineers to build them. I would say it's a shame that we consider someone an Engineer at all without training in Systems Engineering; it really is the holistic body of training tying all the other Engineering disciplines together. A Civic Engineer could model a bridge, but a Civic Engneer with Systems Engineering training can model the structure of the maintenance contracts required to upkeep the bridge, and find the most cost-effective incentive to encourage people to avoid trying to take their oversized cargo boats through the pass. In a way, Systems Enigneering has a lot in common with Game Design--just with the proviso that the "game" is played by real people as an aspect of their real, every-day lives, instead of writhin a voluntary Magic Circle of play.

I should note, though, that as a Systems Engineering problem, "starting a start-up" has a unique property--rather than being built and then launched, start-ups are launched, and then built. A startup is basically a partially-designed seed System, which has just enough utility to "live" (it's Minimally Viable!), and which will then require more Systems Engineering to be done "in-flight" (customer discovery/pivoting) to keep them viable. This necessitates a Systems Engineer actually be a component of the seed System, as architected, at least until the System reaches a state of maturity (which is precisely defined as the point at which a Systems Engineer is no longer needed for the System to avoid "running down."

If you'll indulge me in a metaphor, a start-up is like a modern fighter plane. It used to be that, having lost power, a plane could simply continue to glide toward its current (ballistic) trajectory, because it had static stability. However, it turned out that statically-stable designs had weaknesses (warping under sufficient torsional forces, for example) and to increase manouverability past a certain point, static stability would have to be sacrificed. In a modern jet fighter, then, we have a plane constantly tending toward shaking itself apart--and a set of electronics giving it continuous micro-adjustments so it won't. In other words, we have a System that can only function as long as there is an intelligent agent adjusting and tuning it from within.

--where the parallel breaks down, of course, is that a fighter plane flown for long enough doesn't continue to grow until it becomes a Boeing. But then, if they had aviation control electronics as intelligent as a Systems Engineer, I don't see how getting a fighter plane to pick up parts, join them to itself, and expand out until it could fly passengers five days a weeks would be an intrinsically harder problem than turning an idea in your head into AirBnB.

One thing you should be able to notice from my description above: there's no reason the Systems Engineer running a start-up, has to be the one who designed the start-up's seed System in the first place. I would say that the whole point of a start-up "incubator" like YCombinator is to do most of the Systems Engineering work in constructing viable seeds--including picking good teams of Systems Engineers to run them. That the people executing on their Systems are frequently the ones to suggest the initial idea for the seed System they end up working on is more an artefact of human-nature+ than anything to do with YC's business model as such. I would flip the role terminology around: YC engineers the seeds; then the founders--part of the constructed seed System--incubate it, until it no longer needs continuous System Engineering for its ensured viability. (At which point the founders either give up on being Systems Engineers, or leave to start something else.

Another fun analogy: a start-up requires the care of its founders in the same way a fortis requires the environment of the womb. This would make YC an IVF clinic--though with some aspects of a pre-natal care facility as well. :)

+ Less cynically, YC can be said to just be making the capitalist assumption that knowledge of what the economy wants is distributed among the people on the ground in each domain. That's assuming the founders have knowledge of their domain...

danhodgins• 13 years ago

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.

Jd• 13 years ago

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 is longer and more experience driven than some of his other "classic" essays (i.e. the theory behind why blub is bad and lisp is great)

scribu• 13 years ago

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.

lmm• 13 years ago

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.

dmoney• 13 years ago

It's long, but at least PG gets to the point. So many articles have a title like "Why x is y", and then start like "The cool evening air smelled of honeysuckle in <place that, initially, would seem to have nothing to do with x or y>", and are multiple pages long even though having a web page be more than one page long makes no sense.

mojuba• 13 years ago

Somehow many of his essays look "the best ever" when they just come out ;) Take for example Startup = Growth which did have an impact back in the day, but already feels somewhat outdated.

krisc• 13 years ago

It's like what he's writing seems so obvious, and the essay puts this seemingly obvious information out there for everyone to know.

larrys4• 13 years ago

Agree but not "c".

Target of this essay has the time to read something this long.

I'm saying that as someone that doesn't even need the info but yet I found it good enough (don't always agree with PG or anyone for that matter "just because") to read. I may read it again (ok I skimmed quickly first time because I have to get somewhere).

Lots of similarities between what I've done, what I've seen (in the traditional non "pg startup" business world) and what was written here.

6cxs2hd6• 13 years ago

His essay nails it.

This is priceless advice. For free. If you could follow it without coaching hep, you wouldn't need YC (except maybe for the connections and networking).

The tricky part is that the wisdom is utterly simple. [1]

So if you say it concisely, it sounds like a fortune cookie. A lot of people won't believe it. They'll ignore it. Or they'll twist it into something unnecessarily complicated, and/or remap it into what they want to hear.

Maybe you could drop some Zen koan on their asses to stop them cold, a sort of mental slap to the face. Or more realistically, you could do what pg did -- write a somewhat long but clear essay. Hang enough flesh on the skeleton to get people to consider it.

- - -

[1] Simple is the sense of "not complicated". But not in the sense of "easy". It's hard work. On the other hand, it's gratifying work when you're getting feedback from real people and acting on it. Running that loop is energizing. But you need the energy because it's incessant.

stcredzero• 13 years ago

In other words, the only new markets that will be available will be the ones that are protected by some sort of "potential barrier." Otherwise, they would already be actively exploited.

ph0rque2• 13 years ago

PG, thanks for this essay, it is such an encouragement for us, giving us a plan for how to approach our startup (http://automicrofarm.com/) growth for the next few months.

jacquesm• 13 years ago

I totally love the concept you guys are working on.

ph0rque2• 13 years ago

Thanks, most people do. However, I'm afraid the concept is a bit too "puppies and rainbows". It won't be an easy road to get to the point that our products resemble the concept. In the meantime, we've gotten back some feedback (mostly from the aquaponics subreddit) that our existing prototype ( http://blog.automicrofarm.com/post/48893635647/autonanofarm-... ) is too expensive and not high-enough quality.

So, there's a lot of work for us to do yet.

gwu782• 13 years ago

I like this essay a lot.

In the early days of Apple, the founders placed minimum orders for parts on 30-day credit, then built the computers in 10 days and sold them before the payment for the parts came due. There wasn't any sexy software at that point. Apple was a hardware startup.

Web startups are in general probably more attractive to VC, but I'm excited about hardware startups.

wslh3• 13 years ago

I am excited too but since it is a mass scale business I think it is important to focus on machines/robots to build the hardware.

gwu782• 13 years ago

But at what stage do you adopt this focus? From Day 1? The point of the anecdote about Apple is that they began their startup by doing something unscalable. Not only was building computers by hand unscalable, but the financial risk they took was unreasonable. What if they failed to sell enough of their computers to cover the cost of the parts?

Many businesses that you see as "mass scale" may have began life as "small scale" ones. Check your assumptions.

_xhok• 13 years ago

It's interesting that what pg writes in this essay is implicit in the word scale. If you think about what it means to scale, it means your level of automation grows as your number of users grows. If you don't have many users, it doesn't make sense to automate too much.

genn843• 13 years ago

It's not about whether it makes sense to automate or not... it is about how vital for a young startup it is to do things that a big company wouldn't do (hence cannot scale) to make the client feel special: e.g. sending the client a hand-written note from the CEO. The article is really great and I think it really makes the point that such seemingly unnecessary actions can make the difference. Great read!

omegant3• 13 years ago

Thank you PG!, this post it's perfectly timed for us. And I was a bit lost on how to begin looking for users. Not much better now but at least with a general direction to follow..

omegant3• 13 years ago

Thank you PG!, this post it's perfectly timed for us. I was a bit lost on how to begin looking for users. Not much better now but at least with a general direction to follow..

andrewflnr3• 13 years ago

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?

mjmahone17• 13 years ago

From someone who's never actually done the startup thing: when you feel like your product is good enough to stand alone, outside of the specific domain you originally targeted for, you likely have to have a second round of "initial" user acquisition, where you cater to, and iterate on, the needs of more general users you recruit.

andrewflnr3• 13 years ago

But if you try too hard to get that one domain, you may not reach a point where it's "good enough to stand alone, outside..." because, while your execution was good, you moved in the wrong direction.

k-mcgrady• 13 years ago

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.

kevinalexbrown• 13 years ago

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?

andrewcamel• 13 years ago

I totally agree and think this is an important line to draw. If it's anything having to do with offsetting the core unit economics of the business, I'd get worried. E.g. Not correctly determining the cost of delivery as Instacart b/c the founders do runs sometimes too.

pg4• 13 years ago

See the section labelled "Compass" here:

http://www.paulgraham.com/growth.html

rattray• 13 years ago

Thanks for posting this here. May even be worth mentioning in a footnote of this essay, as it provides a terrific bit of context.

jfoster2• 13 years ago

Imagine that airbnb got the door slammed in their faces at first. If so, they should keep trying and adapting their approach. Once some X% would convert (where X is acceptable), but they can't reach enough doors, the problem has changed, so they need to start scaling better.

danial• 13 years ago

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/

graycat• 13 years ago

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!

kyro• 13 years ago

The initial grind is a part of the startup fairytale that I feel is so often overlooked, yet is often the most interesting.

It shows just how the founders built their engine, the pieces they had to forge, parts that needed to be jammed together in some way to just barely function, components that were thrown out for costing too much and working too little. Every successful startup has their own engine. Some may be exact replicas of others. They work because the problems they tackle have been well explored. And others are bespoke, tailored specifically to handle truly difficult problems, and which require an immense amount of exploration, experimentation, failure, and restarts. That's why an Instagram can take off with less refinement and horsepower than an Airbnb -- we've developed the tools and built the maps to tread on one terrain, but not the other.

tteam• 13 years ago

We gotta say this. We have never been a fan of pg's essays.

BUT THIS ONE IS GEM. Probably the Best. Also remember, even after doing all this there is no guarantee that your startup will succeed. But this one has all the optimal paths.

guynamedloren4• 13 years ago

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 users should have easy access to our hotline at every step of the purchase and post-purchase flow in case they ran into issues. The founder rejected this. Why? "People would be calling us constantly". We also spent enormous amounts of time and resources tweaking the app design to perfection (pre-launch), and attempted a massive press launch with exclusive blog posts/coverage while turning our noses at any sort of manual user acquisition.

Fast forward 6 months. That product failed.

DanielRibeiro• 13 years ago

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

seanmcdirmid3• 13 years ago

I.e. confirmation bias and cognitive dissonance?

k__• 13 years ago

If this happens too often, the person with the ideas is probably the problem, not the "bad" groups

johns2• 13 years ago

"People would be calling us constantly."

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

guynamedloren4• 13 years ago

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

da02• 13 years ago

How would you define "manual user acquisition"?

Thanks for posting this. I hope you and others write more on failed products/companies. They are very enlightening, despite the details left out for privacy/embarrassment.

guynamedloren4• 13 years ago

How would you define "manual user acquisition"?

I think it's what PG calls schlep[1], or at least similar. Tasks like talking to users (not just your family and friends), scouring internet forums, reading everything you can to learn as much as possible about your demographic / target users and what makes them tick, going door to door (in the case of airbnb), being active on social media, etc. It's doing the stuff that nobody whats to do, because it's not glamorous, and it's not necessarily the most exciting. It's constant, it's draining (on every level), it's time consuming and its tough.

It may be easier to understand by looking at the opposite end of the spectrum - some sort of automated user acquisition: the expectation that a user acquisition plan can be conceived and launched, which will trigger loads of users knocking at your door, all requiring little to no maintenance afterwards. A strategy like this may include press releases about a new product and a giant paid marketing budget. Just flip the switch on those and the users start rolling in, then we can get back to building. ;-)

[1] http://www.paulgraham.com/schlep.html

mandeepj• 13 years ago

I am sorry that your product failed.

Would you mind sharing with us what you think had caused your product to fail?

guynamedloren4• 13 years ago

I would love to - there's a lot to be learned from such experiences. Unfortunately, I would not feel comfortable doing so without approval from the founders - even remaining nameless.

Internally, we have been reluctant to admit that the product has failed (despite it being shut down and pulled from the app store). We have not discussed the product since we shut it down. We have not looked at what worked and what didn't work. We have not analyzed why it failed. Instead, we've chosen to blaze forward, focusing on our next launch.

agilord• 13 years ago

"Automate everything. Nothing should be manual."

This mindset seems to miss the point of technology (and software development). It is the business impact, not the automation for its own sake.

E.g. we can automate the hell out of the office arrangements or whatever, if it does not have a business impact, we are just wasting our time.

rlu2• 13 years ago

"People would be calling us constantly".

I probably would have been majorly bummed out at that moment.

Spooky232• 13 years ago

Dogma can be a real bitch. I always tell people working for me to keep the religion at church and get something done.

po• 13 years ago

Automate everything. Nothing should be manual.

If you can even get close to doing that then you either have the world's best development team or you aren't trying to do enough. In a perfect world we would have time to automate everything, but time pressure makes us go for the minimal thing that will work.

A large part of this is essay is premised on the idea that developer time is expensive and slow relative to the manual process (which can even be done by someone non-technical in a pinch). If you're not 100% sure it's a necessary feature then it is a waste. In your case, throwing a phone number on the page was a very quick way to provide good support relative to an automated support system and/or a flawless well-tuned experience.

XorNot• 13 years ago

Non-technical people don't know what normal is in your process, what should be noted when it's happening (Warning's may actually be important if non-fatal) and when they should seek advice. They're liable to ask you about every tiny thing, but then miss something really important altogether. Basically - I strongly disagree that you can often put a non-technical person onto a repetitive task involving technology.

It really depends what process you're talking about, but its a worthwhile consideration that unskilled (but intelligent) labor is not cheap either (i.e. Foxconn has to be massive and in another country to leverage it the way they do).

zby2• 13 years ago

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

vacri• 13 years ago

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.

shin_lao• 13 years ago

I think pg is saying that as long as you're not sure of what your product is doing and/or how much profitable it can be you should have a craftsman approach and once you get traction you go into the industrial/scaling phase.

If you try to scale/automate everything it's a recipe for a lot of wasted efforts. Make money first. Scale second.

In other words, scaling too early is premature optimization.

mathattack• 13 years ago

It seems like this is really the vector concept. Everything for the long term must be scalable (what your founders are getting right) versus everything for the short term (what you seem to be doing wrong) can be fungible. Perhaps the issue is in presentation? The real concern that your cofounders have is an enormous mass of manual work in the future. This is a real concern. But it's also to say, "We'll drop this backbreaking level of service once we get X users, at which point they'll be coming to us."

cortesoft• 13 years ago

I had a really similar experience at my last startup. We were so focused on scaling and making sure our API could handle 10,000 requests/second that we never made sure we could even get enough users to generate 1 request a second. Before you scale, make sure you are going to have to.

rdl2• 13 years ago

You might as well be as forward as possible about your concerns with the founders; it's not like it would take you more than an hour to get another job (including plenty of YC companies). It's reasonable if the founders think otherwise about these issues and are able to convince you of their viewpoint, but it shouldn't just be un-analyzed.

aylons• 13 years ago

I am so glad to read something about hardware startups here. As a engaged hardware engineer who aims to build my own company soon, I miss reading more about hardware startups.

Funny thing, I read the whole OP thinking about how all these ideas would work in a hardware startup, and came to conclusions similar to his before reaching the point about it in the article.

Crowdfunding brought some fresh air to this world, but I still miss an active community as the software startup one is. Maybe I am missing something?

graeme7• 13 years ago

I saw this on a miniature scale when I created a new subreddit (http://reddit.com/r/LSAT)

I spent about two weeks creating quality articles for the sidebar, personally replying to every submission/comment, manually recruiting anyone who mentioned the LSAT, and reaching out to moderators of related subreddits for links.

Mercifully, a subreddit is a small thing to launch, and after two weeks the place became self-sustaining and grew to 1500 subscribers.

I'm seeing the same thing again with a website I just launched (http://lsathacks.com), which has free LSAT explanations.

Very positive initial comments, but just letting people know about it hasn't resulted in a surge of traffic. Instead, I'm going to have to manually recruit people. Only then will I know if it's worthwhile.

My point is that this doesn't apply just to high growth startups. Almost anything new requires initial unscaleable effort.

Edit: The LSAT is the Law School Admission Test, a logic test required for admission to North American law schools.

vidar• 13 years ago

Thats a great way to practice user acquisition.

graeme7• 13 years ago

For anyone interested in using a subreddit to practice acquiring users:

Metareddit lets you track all mentions of keywords or phrases across Reddit. It let me find literally everyone who commented about the LSAT.

http://metareddit.com

rlu2• 13 years ago

Yep. Reminds me a lot of when it was fairly common to start your own forum back in the early/mid 2000s. (phpbb, vBulletin, IPB, etc.)

aw3c22• 13 years ago

Both links say LSAT everywhere but I could not find any mention of what the acronym means! I had to check Wikipedia.

graeme7• 13 years ago

Oh yeah. Everyone in the target market knows what it is, otherwise it's pretty obscure.

It's a logic test required for admission to law school in North America, highly competitive.

wozniacki2• 13 years ago

Give it a thought for a second.

Does the degree of inconvenience caused to you - in requiring you to figure out what LSAT means - necessarily require that you record your disapproval here?

The test for substance is a lot like it is for links. Does your comment teach us anything? There are two ways to do that: by pointing out some consideration that hadn't previously been mentioned, and by giving more information about the topic, perhaps from personal experience. Whereas comments like "LOL!" or worse still, "That's retarded!" teach us nothing.

Source:

http://ycombinator.com/newswelcome.html

Tyrannosaurs• 13 years ago

Interestingly from questions on their Meta sites StackExchange found that this sort of "priming the pump" didn't really work for them when it came to building on-line communities.

Their attitude (having tried it) is now if the community doesn't build itself it won't sustain itself. If you've got a working community then you can promote it but this sort of work won't work to build a community that's not already there.

Not saying that what PG says isn't true for start-ups which are obviously different, but it may be relevant in your case.

damarquis• 13 years ago

I love some of the SO sites but they have a lot of communities that have been lingering in beta limbo for ages.

I would be interested in more detail on how they reached the conclusion that pump priming is not useful. Do you have a link?

graeme7• 13 years ago

That's an interesting result. Do you have a link where they explain how they came to their conclusion?

Because I did build a community entirely by priming the pump. There was no community there. So it absolutely worked in my case.

However, Reddit was an easy place to build a community, as I just had to tell existing Redditors who studied for the LSAT that there was now a subreddit for that. It was an easy sell.

bsaul• 13 years ago

thanks for the advice. I was thinking abiut hosting and scaling architecture before trying to sell my product, but this piece convinced me it's going to be ok if my first customers run on some dedicated server with everything on it. i'll have plenty of time to think about VMs and load balancer later.

Most useful post i've read from pg as well.

Patrick_Devine• 13 years ago

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

kyle_martin1• 13 years ago

Holy shit. This is exactly what I've been doing and it's working incredibly well. For PG to confirm everything I've been doing...I'm on cloud nine.

ggreer• 13 years ago

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.

redguava• 13 years ago

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 sporadic distraction, it can be a real productivity killer.

I see why people say this in pricinple, I just don't think it's a good idea in practice.

kragen• 13 years ago

Tech support is a skill in itself, but it's also a crucial feedback channel for learning how users use your software. Empathy with users is what lets you distinguish a good programming decision from a bad programming decision when it comes to the software. Distinguishing good programming decisions from bad ones is what programmers do all day.

It's possible for tech support to work out as a disruptive distraction, but it doesn't always have to be that way. And yes, there are programming things where being in the zone is crucial, but there are usually programming things where it isn't, too.

jakobe• 13 years ago

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.

davidw• 13 years ago

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.

arigoi• 13 years ago

I interpret "bending over backwards" as compromising the business model, which does have the potential to kill the business. However, I believe pg is alluding to good customer service.

amac• 13 years ago

Excellent read and dead-on. It's something I'm working on every day since launch and will be a good point of reference should I need reminding.

asah• 13 years ago

This is brilliant, easily a top-10 of PGs.

re: consulting-- one advanced technique is to put the consulting "into a box" i.e. define precisely what the consulting package is, and offer this standard service at a standard price. If investors/etc. give you flak, tell them that your customers need this anyway, and at least your getting paid for the trouble. FYI I'm doing this now: many of our customers are young companies that need advice, and instead of taking an hour+ to give it free, we take a few hours and charge them. The actual work can be delivered by a number of people, so it scales fine.

adam (6 startups, 3 IPOs - #7 takes this advice to a whole new level and we're winning big, in spite of concern from my friends in tech, who exactly fall into the trap PG is talking about)

johnrob2• 13 years ago

If you're willing to do whatever it takes, you can probably round up a group of early users (unless your idea is terrible). I think few founders really doubt their ability to do this. What the founders are really looking for is some validation that the users will eventually grow to a large number. But if the mentality is to compare your early startup with the early version of Pinterest, it will be very hard to find any evidence that yours won't find similar success. A startup is thus an inevitable leap of faith.

In a way, this essay deflates the concept of 'proof' in the lean startup mentality. There is no way to prove that an idea will be a good one (although you can probably filter out particularly bad ones).

nowarninglabel• 13 years ago

It's still easy to mess up this process though, at least, that's how I feel about RepairPal. I got an e-mail from my credit union suggesting them, and it was perfect timing cause I had just bought a used car that needed some repairs. So, I signed up, put in the info, and...nothing. No response whatsoever. But then, their marketing team sent me a semi-personalized e-mail requesting feedback. Awesome, so I wrote about the service not providing me with anything, and stating that I wanted to still use the service, I just hadn't been provided any response. And...again...nothing.

Now, I'll never use RepairPal. They've wasted my time twice. So, if you're going to take the time to reach out to users manually, make sure to actually follow up on the responses you receive.

johnrob2• 13 years ago

Unfortunately, a billion minus one is still a large number. Thus, the penalty for annoying individual users is pretty much nothing unless it turns into bad PR.

artag• 13 years ago

I am curious - what were you trying to get done through RepairPal? I was under the impression that they just provide repair estimate and shop listings...

gfodor• 13 years ago

A great article. One major point that I think would have been worth including though is that if you are not interacting regularly with happy customers, and making unhappy customers happy, you are denying yourself probably the single most motivating factor when doing a startup. A single positive review on the App Store or through e-mail can get me through an entire day of grinding out bugs. If you don't have the humility and empathy required to genuinely enjoy providing customer service for a product you have developed, then you are probably in the wrong game.

EGreg• 13 years ago

This is great advice. But I wanted to briefly mention an alternative perspective. We did things very differently.

Now two years later we have 250,000 monthly users, and we're getting ready to roll out our technology to them in a few months.

When you are building an app for people, businesses, or whoever, you have to go where they congregate. Pick an existing social network with a messaging channel that people haven't grown apathetic to. Then you have to have an onboarding process that's simple. Then you have to develop a sales process and maybe even incentivize your existing users to sign up others. Viral coefficients decrease your user acquisition cost. And so forth.

That's why we built our framework. We spent two years solving the problem of "how do you build the next generation of successful, useful apps? And soon we will see if we were right.

I wrote this back in 2008: http://luckyapps.com/blog/?p=12

wslh3• 13 years ago

I remember the cofounder of Dropbox also talking about this in an Stanford video. He was talking about promoting it, with ads, in Reddit. I think this kind of advice is the one where we need to put more focus instead of dev issues.

6thSigma• 13 years ago

PG, I'm curious if you have any data among your startups that tests user recruitment methods. For instance, maybe you've seen that Reddit is great for gaining users in consumer startups but cold calling is great for B2B startups.

I think the biggest difficulty non-"famous" hackers face in user recruitment is it's hard to figure out where and how to successfully do it.

larrys4• 13 years ago

"There are two reasons founders resist going out and recruiting users individually. One is a combination of shyness and laziness. They'd rather sit at home writing code than go out and talk to a bunch of strangers and probably be rejected by most of them. But for a startup to succeed, at least one founder (usually the CEO) will have to spend a lot of time on sales and marketing."

Mike Arrington, before he was of Techcrunch fame, recruited us personally for the new company he had been hired as CEO/President of, Pool.com. Lest anyone thinks he does not know how to hustle he does. He can and was very persistent and determined with anything I threw at him. That ended up being a great relationship lasting many many years after Mike left the company. I feel fairly certain that a regular biz dev guy would have given up with what I threw at Mike. You may not have heard of Pool.com but they made a ton of money and were very successful.

chacham15• 13 years ago

And except in domains with big penalties for making mistakes, it's often better not to aim for perfection initially.

I feel like this exception is another potential pitfall because it is so easy to think e.g. "if this doesnt look polished, users will think that we arent professional" and that is a big hit.

Although that is a more clear case, there are more ambiguous ones: imagine that your startup is doing encrypted email. What level of encryption/protection do you go with at launch? Do you go with the best practices as good as the founders know of or do you get an audit from tptacek? The latter is probably wayy out of your price range as a startup, but if your security takes a hit people wont know if they can trust you with their important information. What is the right line to go with here?

jmtame• 13 years ago

This is probably my favorite PG essay to date, something I've spent a lot of time thinking about as well.

I think what separates novice investors from good ones is that a novice investor will start asking questions that only make sense at a later stage. They're committing a cardinal crime in startups: premature optimization. For some reason, even though they explicitly say they invest at the seed stage, they're looking at it from a warped lens of "let me think about how this works, in your current implementation, at enormous degree of scale." And of course the implementation will change, so the logic immediately breaks down on itself because you're assuming the thing you see now will be the same in 5 or 10 years. The baby analogy seems perfect for this reason. A baby will arguably have little to no resemblance to itself in 5 or 10 years, everything about it will have changed significantly.

The nice thing is you don't have to explain these things to the investors that "get it." It just clicks instantly, and I think this happens even before the meeting--it probably goes all the way back to the introduction that someone else makes for you. Good investors at a seed stage understand there's some degree of risk in a small yet still fragile startup that has at least some degree of promise to it. From the top tier people I've spoken to in the past, they focus less on the specific numbers and metrics, and more on the "does this fundamentally solve a problem in the market right now? Is there a real need for this thing to exist, and what's better about this than everything else out there?" They look at similar companies in different spaces and draw interesting comparisons. "You guys are like this other company, which started out much like you did, and you're applying a very similar solution. I think this will work!"

The really good investors don't try and evaluate your company as a Series D investment, they look at where you are right now at the seed stage and see it for what it is, and what it could be. I suppose this all sounds obvious, but the real world is full of surprises that contradict assumptions.

pixelmonkey• 13 years ago

Loved this essay, but I'm a little confused by this footnote.

"[5] If you're building something for which you can't easily get a small set of users to observe—e.g. enterprise software—and in a domain where you have no connections, you'll have to rely on cold calls and introductions. But should you even be working on such an idea?"

When pg says, "Should you even be working on such an idea?" -- is he saying that he questions any startup that is focusing on enterprise and which cannot be sold to fellow founders in a YC batch?

He once wrote "enterprise software companies sell bad software for huge amounts of money", so I suppose he doesn't love enterprise software that doesn't have a long tail customer base.

But, wouldn't this exclude a lot of interesting ideas in education, healthcare, government, finance, etc.?

davidcann• 13 years ago

Presumably, you enter YC with pre-existing domain knowledge and/or network or you have a way to gain those quickly.

mkeung• 13 years ago

My interpretation: this is just saying your success is likely to be higher if you work with what you are familiar with.

If you deal with enterprise problems and enterprise software, go for it. If you haven't ever dealt with enterprise problems, what are you doing making a start up for what you don't understand well.

soneca3• 13 years ago

No, he questions founders of enterprise startups on a field they don't have deep knowledge.

If I found a startup that wants to improve how car dealers sell cars, but I never worked selling cars, nor I know car dealers, why I am founding this.

Spooky232• 13 years ago

You need to understand the secret handshakes and domain trivia in a particular enterprise space to be successful.

I have worked in government IT for years. When some breathless sales dude tells me that he has some sort of amazing solution for X that allowed Goldman Sachs to cure the common cold, I'm intrigued. When the sales dude doesn't know what a government procurement contract is, I just shake my head, because we probably wasted an hour or more talking about it. Worst case scenario, the sales dude captures the imagination of some big shot and gets fired because instead of selling stuff, he wasted 6 months filling out forms and missed his quota.

The guys who sell to my vertical already know how I'm going to buy the product, and sell to the attributes of the product that matter to us.

dschiptsov3• 13 years ago

One more important thing to understand about Jobs "miracle" is that he was allowed to do what he was obsessed with. No idiotic "manager" or board member intervene with ideas of "cutting costs" on packaging or materials or any other fast-food technologies to reduce the product to the mix of cheapest and crapest ingredients imaginable. No idiots insisted that it is much more "effective" to just add a "theme" to and old code, to make it look like touch-capable (hi Symbian, WinCE) etc. No one said that re-implementing from scratch, because everything else is crap is costly and time-consuming, and so on.

There are lots of people with good taste, sense of style and quality (read Pirsig's book) and enough self-discipline to follow do what one is preaching, but it is an extreme rare situation when such people have enough influence to make things their own way.

I guess a half of YC business is about trying to spot an employ such obsessed individuals, no matter what exactly they want to accomplish. Early funding of even one of such guys worth waiting and funding hundreds of mediocre, especially if one has connections to channel or sell them off.)

Igor Sysoev was obsessed with efficiency (in that time c10k problem was actual), so src/core and src/os/unix should be taught in colleges (btw, the module system is already an over-engineered mess).

There are many other examples, but the big idea is simple - spot the right people, all that numerous micro-optimizations, while valuable, are superficial.

gruseom• 13 years ago

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?

dschiptsov3• 13 years ago

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

pshin45• 13 years ago

I find it fascinating that, with YC and HN, PG has essentially created a "business school for hackers" that is free, open to anyone, and makes it faster and easier for any hacker to gain a solid understanding of business and marketing principles.

And yet on the flip side, I see no one in the MBA/business world who is effectively doing the opposite i.e. creating a forum and/or institution in the mold of YC/HN for "business guys" to develop a fundamental understanding of (and respect for) technical leadership and software engineering concepts. I wonder why... Is it because it's more difficult, or more because business people just don't care and never will?

People often say that YC changed the VC industry, but in a way I think the YC and HN models together are slowly but surely disrupting the "business education industry" as well.

Thoughts?

bickfordb• 13 years ago

My experience is that many product managers (who often are originally software engineers / in technical roles) end up in MBA programs

cm2012• 13 years ago

A lot of "business people" read HN.

soneca3• 13 years ago

I had an odd way to follow this advice. I am learning to code and in 4 months I went from no knowledge at all to learning basic CSS/Html to basic C# to basic MVC to be able to launch and start selling a useful enough SaaS to acquire a few paying customers. I am just not a good enough developer to automate everything, I can't even code properly without Visual Studio helping me.

I am not dangerous, but I now know enough to be useful. I am trying to make my customers happy. The first feature I added after launch was something my first paying customer asked.

My product helps senior citizens to control their medications (what, when and how many pills they must take, which days, and alert when they need to buy more pills). I will start to put handouts on drugstores. Better than hoping elderly internet users know their way through google ads.

I spent 3 hours watching the first prospect to ever use my product taking a look at it for the first time (that would be my father). I left with literally 50 notes of what I should do immediately and some more thoughts of future features.

I am not a hacker, but I guess this helped me thinking more about what people want, because there was not much I could do from my own ideas and knowledge.

deepGem• 13 years ago

Speaking from personal experience, it's easier to pick up the traits of customer development/leadership/design with an engineering background. On the contrary, I've seen some of the smartest non engineer MBAs give up on programming. Not sure why.

soneca3• 13 years ago

I am not particularly smart, nor a MBA, or a McKinsey. I am learning to code to be useful, to build something useful, not build something great.

I would say that smart MBA try to learn to code to build something great, the next Dropbox, something that match their ambitions. When patio11 is your reference, not Bill Gates, or Zuckerberg, it is easier to keep your motivation. (Please, don't read this as me saying patio11 is not a great engineer, i couldnt know, just to illustrate the difference of ambition)

eli• 13 years ago

Totally agree.

It's been discussed on HN before, but here's another concrete example of this sort of thinking: killing the no-reply address. IMHO, there is no reason your startup should use no-reply for any emails, ever. Yes, it's a hassle to sort through all the out of office replies, but it's worth it.

Even if you tell people not to, they will reply to your newsletter or order confirmation or forgotten password message. And -- better yet -- they're often complaints! I like reading complaints. It's easy to find people to tell you you're doing great; I want to hear more about how we can improve. At my startup we make a point to reply to just about every message someone sends us (customer or not), but that's especially true of complaints. More than once I've gotten back replies like, "Wow I didn't expect anyone to read [my rant about how the site doesn't work on an Android 1.6 tablet]. Thanks for getting back to me!"

pg4• 13 years ago

Yes, that's a great example.

laureny• 13 years ago

It's cute that even though pg is an Internet veteran, he still doesn't understand how HTML (and the web in general) works and he hardcodes br tags in his text at 80 columns.

sambe• 13 years ago

I think a key thing here is "plan to systematically do something that doesn't scale if the rewards are big enough". And the common bias is thinking that the rewards are not as big as they are. If it's in your top 3 problems and manual work is a path to scaling automatically, you should probably do it.

However, at some point short-term velocity is also contributing speed bumps that are barriers for reaching the next level. I certainly wouldn't want to be doing this ad-hoc or without consideration.

patkai• 13 years ago

What does the Scotty vs. Kirk comment imply? I don't watch much TV and I'm not a native speaker so I don't get it.

btilly• 13 years ago

Scotty was in charge of the engines that made the ship go. Kirk was in charge of the ship, the mission, and interacting with whatever weird things they ran into.

marcamillion2• 13 years ago

Whoa....this footnote flies in the face of the 'charge early' crowd:

[8] If you have to choose between the subset that will sign up quickest and those that will pay the most, it's usually best to pick the former, because those are probably the early adopters. They'll have a better influence on your product, and they won't make you expend as much effort on sales. And though they have less money, you don't need that much to maintain your target growth rate early on.

Very interesting perspective.

31reasons• 13 years ago

Note that is probably written for the Startup goes VC route. It may be different for the Bootstrappers.

marcamillion2• 13 years ago

True. Either way...a famous refrain is to charge as quickly as possible.

rmorrison• 13 years ago

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.

This is probably the most important thing a new entrepreneur needs to realize. Envisioning a world where everybody is using your product isn't enough. You need to figure out how to get to that world from this one, and that is where many entrepreneurs don't have a strategy, and subsequently fail.

sinzone• 13 years ago

PS: Brian Chesky of Airbnb came out first with advisig people in doing things that don't scale.

jamesrcole• 13 years ago

Good article. One small thing that wasn't clear to me is

The feedback you get from engaging directly with your earliest users will be the best you ever get. When you're so big you have to resort to focus groups, you'll wish you could go over to your users' homes and offices and watch them use your stuff like you did when there were only a handful of them.

Why can't you do that once the company gets to a certain size? I don't have any experience with these things, so it's not clear to me. Surely there must be some better alternative than focus groups.

arkades• 13 years ago

Sample error.

When you had 100 users, it was feasible to get detailed feedback on 90 out of 100 users. When you have 1.5m users, you cannot get detailed feedback on 1.35m users. Dealing with much smaller fractions of your user base, sampling error grows into larger and larger an issue. That's not to say there aren't wonderful statisticians working on sampling issues, but fundamentally it's not the same as actually interacting with the vast majority of your user base.

gadders• 13 years ago

I realise this is sacrilege but the impression I get from a PG essay is that you could make the same points in 1/3 the length.

tempestn• 13 years ago

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.

edanm• 13 years ago

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.

al1x• 13 years ago

Does anyone want to summarize this novel?

wodow• 13 years ago

So the question is: what's the equivalent of an electric starter motor for businesses/startups?

dominik• 13 years ago

Excellent essay. Good detail. I like the longer format.

Reminded me of, all people, Mother Teresa. She started in Calcutta in 1948. People mocked her: What difference do you think taking care of one poor person will make? But that was her focus: One person at a time. "Do small things with great love."

So too in the quite different field of technology startups.

ashayh• 13 years ago

Your analogy is accurate in theory.

However, Teresa and those like her are a total fraud.

spinachthrow• 13 years ago

So the general idea is that lack of scalability within a domain is a barrier to entry? If so, then the real barrier to entry is finding the domain, not the actual schlep - big companies can schlep pretty well, right?

wslh3• 13 years ago

I think this is the best PG essay because it talks about the human being of flesh and bones. Probably only this subject deserves a site to fill with real stories.

wildermuthm• 13 years ago

Great essay. But I'm surprised PG didn't mention Pretotyping. Here's the Pretotyping PDF that hammers the point: make sure you are building the right IT before you actually build IT:

https://docs.google.com/file/d/0B0QztbuDlKs_ZTk2M2RhZWItYzk3...

alexjv89• 13 years ago

I read this article 2 days ago in the night and that night I stayed awake all night. This is one killer article that made a lot of sense to me. As a freshly graduate engineer trying to startup, I am making the exact mistakes as mentioned in this article. I did try to automate tasks so that I can handle 1000's of users, when there is barely 2 people knocking at the door. What is even worse is that I do not even consider talking to these 2 people knocking on the door - I am an engineer, I am too busy trying to automate the process that I dont have the time to spend time with the customers, my code will. I cant believe how accurate the article is.

The reason for not talking to customers - I am hesitant - I am an engineer, I design stuff, I dont talk to people, that is not my job. I guess the problem and automate the system do that 100s of thousands of people can use it.

After reading the article, for the last 2 days I was very restless, maybe I still am. I was hesitant. But today I took the courage to take the product to the user and sat with him, showed the product and tried to solve just his problem, in a non scalable manner.

For those who might want to know exactly with respect what I am talking about. I launched a crowdfunding campaign for a hardware product - www.indiegogo.com/projects/tangle . The project is still live. The reason for doing the crowdfunding campaign was it because I was shy going around selling the product door to door. I did take feedback from friends but it I wanted to put it up on a platform and let things happen by itself. After launching the campaign, I realize how much people hustle to get the product to work on a crowdfunding campaign. Now I am taking the product offline and trying to sell it to customers directly.

This post is kickass... It just injected a lot of sense into me.

rdl2• 13 years ago

This is pg's best essay to date.

Do Things that Don't Scale

Related Stories