6 ms·

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 hu

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 13y 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 http://paulgraham.com/word.html
- seanmcdirmid 13y ago
  I.e. confirmation bias and cognitive dissonance?
- k__ 13y ago
  If this happens too often, the person with the ideas is probably the problem, not the "bad" groups
johns 13y ago
"People would be calling us constantly." "Let's try it for a few days and find out. I'll answer the calls."
- guynamedloren 13y 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. ;-)
  - johns 13y ago
    You should find a company that values your talents. All of them.
  - larrys 13y ago
    (This is in response to the comment below "find a place"). Like airbnb: http://lorenburton.com/ http://lorenburton.com/ But seriously Loren I think that the company that you are at now might have already marked you in a way that could limit what responsibility and opportunity they give you. Because they know you're not happy perhaps (and especially after reading your comments if they do). Personally I think you are cut out more for your own startup if you can in fact "wear many hats" than in one area like engineering.
  - guiambros 13y ago
    If you are an early employee at a startup, you were hired to make the company successful, not just to write code. If in order to succeed you need to clean the bathroom (figuratively speaking), just go do it. Go beyond the job description; it's a startup, after all. Job descriptions are worthless, until you have a decent size and need some bureaucracy to survive. If the founder is not seriously expecting you to do go beyond your comfort zone, you should seriously question his ability to lead the company to the next level.
    - klibertp 13y ago
      No, he was hired to do the job his employer want's him to do. If the founder says "stop thinking about stupid/unnecessary/other's things/jobs/responsibilities" then he HAS to do just that. It's not his role to tell the founder how bad a management this is. And yes, I saw such founders in action, it does happen... Quite often in my experience, though obviously YMMV.
da02 13y 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.
- guynamedloren 13y 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 http://www.paulgraham.com/schlep.html
mandeepj 13y ago
I am sorry that your product failed. Would you mind sharing with us what you think had caused your product to fail?
- guynamedloren 13y 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.
  - draugadrotten 13y ago
    > 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. Ahem...That sounds... ominous. Why not spend at least a lunch with a basic analysis? Use a fishbone. http://www.mindtools.com/pages/article/newTMC_03.htm http://www.mindtools.com/pages/article/newTMC_03.htm
    - larrys 13y ago
      "Ahem...That sounds." Agree. Post mortem. Air crash investigation. More than just a lunch I would go for at least a dinner and learn from it.
  - trevelyan 13y ago
    In defense of the founders, there's a lot to be said for failing fast. And while it's entirely possible you could have built a better product, it's more likely the resulting business would hardly have paid a fraction of your salary, let alone theirs. If you think the idea is really good, you should ask for permission to develop it on your own as a side business. And if you don't think so... there's no point in chiding them for agreeing that the work isn't worth your time.
agilord 13y 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.
rlu 13y ago
"People would be calling us constantly". I probably would have been majorly bummed out at that moment.
deleted 13y ago
[deleted]
Spooky23 13y 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 13y 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 13y 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).
zby 13y 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 13y 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.
  - zby 13y ago
    OK - it requires some balance - but what I have often seen is that what developers think are 'imagined problems' are nuisances that can be extinguished by spending all of 5-10 minutes thinking about it :)
shin_lao 13y 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 13y 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 13y 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.
rdl 13y 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.

DanielRibeiro 13y 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 http://paulgraham.com/word.html

seanmcdirmid 13y ago
I.e. confirmation bias and cognitive dissonance?
k__ 13y ago
If this happens too often, the person with the ideas is probably the problem, not the "bad" groups

johns 13y ago

"People would be calling us constantly." "Let's try it for a few days and find out. I'll answer the calls."

guynamedloren 13y 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. ;-)
- johns 13y ago
  You should find a company that values your talents. All of them.
- larrys 13y ago
  (This is in response to the comment below "find a place"). Like airbnb: http://lorenburton.com/ http://lorenburton.com/ But seriously Loren I think that the company that you are at now might have already marked you in a way that could limit what responsibility and opportunity they give you. Because they know you're not happy perhaps (and especially after reading your comments if they do). Personally I think you are cut out more for your own startup if you can in fact "wear many hats" than in one area like engineering.
- guiambros 13y ago
  If you are an early employee at a startup, you were hired to make the company successful, not just to write code. If in order to succeed you need to clean the bathroom (figuratively speaking), just go do it. Go beyond the job description; it's a startup, after all. Job descriptions are worthless, until you have a decent size and need some bureaucracy to survive. If the founder is not seriously expecting you to do go beyond your comfort zone, you should seriously question his ability to lead the company to the next level.
  - klibertp 13y ago
    No, he was hired to do the job his employer want's him to do. If the founder says "stop thinking about stupid/unnecessary/other's things/jobs/responsibilities" then he HAS to do just that. It's not his role to tell the founder how bad a management this is. And yes, I saw such founders in action, it does happen... Quite often in my experience, though obviously YMMV.

da02 13y 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.

guynamedloren 13y 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 http://www.paulgraham.com/schlep.html

mandeepj 13y ago

I am sorry that your product failed. Would you mind sharing with us what you think had caused your product to fail?

guynamedloren 13y 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.
- draugadrotten 13y ago
  > 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. Ahem...That sounds... ominous. Why not spend at least a lunch with a basic analysis? Use a fishbone. http://www.mindtools.com/pages/article/newTMC_03.htm http://www.mindtools.com/pages/article/newTMC_03.htm
  - larrys 13y ago
    "Ahem...That sounds." Agree. Post mortem. Air crash investigation. More than just a lunch I would go for at least a dinner and learn from it.
- trevelyan 13y ago
  In defense of the founders, there's a lot to be said for failing fast. And while it's entirely possible you could have built a better product, it's more likely the resulting business would hardly have paid a fraction of your salary, let alone theirs. If you think the idea is really good, you should ask for permission to develop it on your own as a side business. And if you don't think so... there's no point in chiding them for agreeing that the work isn't worth your time.

agilord 13y 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.

rlu 13y ago

"People would be calling us constantly". I probably would have been majorly bummed out at that moment.

deleted 13y ago

[deleted]

Spooky23 13y 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 13y 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 13y 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).

zby 13y 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 13y 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.
- zby 13y ago
  OK - it requires some balance - but what I have often seen is that what developers think are 'imagined problems' are nuisances that can be extinguished by spending all of 5-10 minutes thinking about it :)

shin_lao 13y 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 13y 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 13y 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.

rdl 13y 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.