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.
My suspicion is that you don't want generic users. You want users who are going to stick with your product for a while and not jump from one train to another. Without them thinking that your product stands out changes are pretty low that they are going to talk with somebody else about it.
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(!) :)
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.
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.
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).
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.
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'.
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")?
We had a couple "soft launches" - one where we put up our first email-collecting landing page and invited some people we knew to use the service (Sept '12). Another where we turned on self-signup on our website and invited more people (Nov '12).
Then after a couple months we had some solid active users and a small number of customers, we were also able to get 2-3 good press articles in the same week, which we now consider our official launch (Jan '13).
I think it's good advice to just keep "launching" until somebody notices :)
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.
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
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.
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.
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.
PG, can you give a couple examples of enterprise startups that took the "consulting" approach to establishing successful (largely productized) businesses?
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
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.
At least one example is http://rjmetrics.com/ - I saw the founder speak for a class I was in a few years ago. Their story is basically that they went to small companies offering analytics services and shaped their services based on what these companies asked for.
"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/
"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.
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.
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.
I think you read it correctly. The opening song in the Painting Coconuts video is one of my favorites currently. This bodes well :)
Thanks for more inspiring videos. The man who plants trees was amazingly apropos because of my recent departure from a promised life in the woods. However, inspiration is always valuable.
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.
"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.
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.)
“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)
> 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 mi...
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.
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)
(C) it is too long and could have been edited down a bit more
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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..
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..
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?
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.
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.
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.
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?
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.
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.
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.
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!
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.
222 comments
[ 8.1 ms ] story [ 378 ms ] threadEssentially, every startup is a user-acquisition startup in its own domain, and it's hard to beat the good ones at their specialty.
Though i submitted my startup over 2 months ago and havent heard anything back.
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.
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...
We had a couple "soft launches" - one where we put up our first email-collecting landing page and invited some people we knew to use the service (Sept '12). Another where we turned on self-signup on our website and invited more people (Nov '12).
Then after a couple months we had some solid active users and a small number of customers, we were also able to get 2-3 good press articles in the same week, which we now consider our official launch (Jan '13).
I think it's good advice to just keep "launching" until somebody notices :)
Dropbox went to YC and to TC 50 and did "double-sided affiliation" and has a great product and and and... etc.
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.
I really wish I could remember the name of the company, but theyr were acquired very quickly for a stupidly large sum of money.
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.
I believe tumblr was a side project as well while the founder was consulting
I would also be interested of examples
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/
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.
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...
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.
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
Thanks for more inspiring videos. The man who plants trees was amazingly apropos because of my recent departure from a promised life in the woods. However, inspiration is always valuable.
EDIT: Here is a piece about the guy http://www.walkaboutchef.com.au/home/9-walkaboutchef/50.html
Every band is a complex business that has to get really good at managing multiple moving parts while entertaining people with great songs.
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.
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.)
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)
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 mi...
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.
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)
(C) it is too long and could have been edited down a bit more
I didn't find it particularly long, though. It would be great if more top links on HN were as in-depth as this.
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.
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.
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.
So, there's a lot of work for us to do yet.
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.
Many businesses that you see as "mass scale" may have began life as "small scale" ones. Check your assumptions.
http://www.paulgraham.com/growth.html
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/
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!
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.