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.
> 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.
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.
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.
@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?
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.
> 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.
Would you mind sharing with us what you think had caused your product to fail?