[guynamedloren]

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]

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

[k__]

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

[seanmcdirmid]

I.e. confirmation bias and cognitive dissonance?

[po]

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]

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

[johns]

"People would be calling us constantly."

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

[guynamedloren]

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

[guiambros]

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]

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.

[jeffasinger]

I wouldn't ever want to work in a company, or run a company where it's unacceptable for an employee to say:

"Hey, the company would be a lot better off if I spent some time on X, instead of my usual responsibility Y."

[bennyg]

Exactly. A discussion between manager/employee needs to happen there. Either it's actually a good idea to do X and the employee can rationalize why or it's a better idea to do Y, and the manager can rationalize why.

[guiambros]

I have no doubt it does happen. I saw it myself several times. Heck, maybe I have done it, when I was a first time entrepreneur.

But as I said, if I were ever in this position, I'd just pack and go. It's hard to build a successful startup; even harder if the CEO thinks he/she has all the answers and is not open to collaboration and sharing the burden of the key early decisions.

This is particularly true when the company is small; not so much when you get to triple-digit headcounts.

[larrys]

(This is in response to the comment below "find a place").

Like airbnb:

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.

[johns]

You should find a company that values your talents. All of them.

[agilord]

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

"People would be calling us constantly".

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

[da02]

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]

> 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]

I am sorry that your product failed.

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

[guynamedloren]

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]

> 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

[larrys]

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

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.

[jfarmer]

The idea behind the "fail fast" mantra is that folks over-emphasize getting every decision correct. This is a problem because you don't really learn until your idea meets reality, including what's important to focus on and what's not important to focus on.

The goal is to learn new things as fast as possible. Since most people dither, "fail fast" serves as good, rough advice. With no extra information it's more likely someone is going to be shipping too slowly than shipping recklessly and pointlessly.

However, if you "fail fast" but also fail to internalize any lessons from that failure, it's little different from never having done it in the first place. You're committing the complementary sin to those folks who spend hours, days, and weeks tinkering until the product is "just right", except in this case it's the other half of the learning loop that's broken.

[jfarmer]

@jchrisa: Sometimes the HN comment timeout doesn't make sense. Hah! This is my reply.

"When you have traction, you'll know it. Traction is what allows you to learn. Then you might wanna try not failing, or at least, let features fail fast, but keep the overall ball rolling.

Real traction isn't something you can buy, so if you find it, stick to it and grow it."

This is true, but if step #1 is "getting traction" then there's a learning loop there, too. I'm not sure if what you're proposing is a process that looks like "try lots of things until you get traction and then worry about focused iterations."

If you are then I think when that approach works it works by accident. It's true you'll have a hard time coming by lots of quantitative data before you get traction, but that's only the strictest kind of learning. On the other hand, if each failure results in a complete product/market reboot, that's not learning -- that's guessing. :)

It sounds like this is what the OP's company was doing, though.

If your product didn't get traction, why not? What will you do differently next time? Will our product work, but not for the customers we thought it would work for? Is our first market too big, too small, too ill-defined? How will we know when we're succeeding or not, pre-traction?

etc. etc.

[jchrisa]

When you have traction, you'll know it. Traction is what allows you to learn. Then you might wanna try not failing, or at least, let features fail fast, but keep the overall ball rolling.

Real traction isn't something you can buy, so if you find it, stick to it and grow it.

[victorf]

> We also spent enormous amounts of time and resources tweaking the app design to perfection (pre-launch)

Not only are you right, it sounds like in this case they failed slow. I've been in a situation like that before, it's incredibly frustrating and demoralizing.

[shin_lao]

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]

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

[rdl]

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.

[cortesoft]

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.

[zby]

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

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]

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

[Spooky23]

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