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.
Not sure if that is the case, but pg wrote last year:
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 ...
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.
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).
"Let's try it for a few days and find out. I'll answer the calls."
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.
"Hey, the company would be a lot better off if I spent some time on X, instead of my usual responsibility Y."
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.
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.
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.
I probably would have been majorly bummed out at that moment.
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.
I think it's what PG calls schlep, 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. ;-)
Would you mind sharing with us what you think had caused your product to fail?
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.
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
Agree. Post mortem. Air crash investigation. More than just a lunch I would go for at least a dinner and learn from it.
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.
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.
"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?
Real traction isn't something you can buy, so if you find it, stick to it and grow it.
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.
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.
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.