Hacker News Reader

Comment by sampl | Hacker News Reader

1. Just get something out there—without obsessing over getting it exactly right the first time

2. When something does go sideways: own up to it, make it right with customers, and learn how to fix your mistake for the future

Seems like a lot of founders get one of these right, but not both. Either they’re comfortable charging ahead into the unknown, but struggle to be reliable—or they get caught up on small details and launch far too late.

View on HN

re: just get something out there

That depends entirely on your market and how big/serious your screw up is/can be.

There are many, many, many, many companies that take an enormous reputation hit or die completely, because their initial product offering was shit.

True, but that's all the more reason to "get something out there" without a lot of QA--just do it as a private beta, internal test, prototype, one-off for a single client, etc.

If you can't afford to have a bad product at launch, then don't let your launch be the first time your customers try your product, you know?

There’s a difference between early adopter types who you might already know and the wider market. “Launching” means making your thing available to the second group, not the first—but the first group is the group you should be trying to please first.

If you think like a customer, then the launch and the first-time-customers-use-the-product are the same thing. But if you’ve got your PM hat on, the launch is the END of a long process of learning, building, shipping, validating with a smaller group that’s representative of the wider market.

#1 is OK if and only if your customers are made aware of what they are getting into. They should know that what they are buying is a "beta" product. Otherwise you are being disingenuous.

Either that or do the Minecraft model and sell the alpha for less than the final product.

I almost forgot that they did this. Unfortunately this doesn't work with these kinds of "artisan" projects because the material/startup costs tend to be high, and actually come down as the product gets more popular due to economies of scale. That's why you have group buys, and companies like Kickstarter. You need the money up-front, and you need some early adopters who are willing to go in deep on it.

AFAICT it tends to be the opposite for software as long as you can ship an MVP really early: there's no need to chase bugs and run tech support if you're writing code that only 10 people will depend on. It's a big time sink, but these kinds of things tend to be labors of love in the first place.

You have to have an idea if you have the ability to make it right with your customers. For some products if you ship a bunch of faulty ones it will be very expensive to replace them.

If you've got a high growth rate and you're improving process quickly enough, this is essentially an ethical Ponzi scheme.

Previous_gen_users << current_gen_users

Ergo, take a one-time charge to upgrade your previous gen users to current, with the revenue from your current gen growth.

Key points here are probably: (1) that it's unexpected & doesn't create an expectation (unsustainable), & (2) that it's unannounced & properly timed (manage the Osborne effect & avoid screwing customers who choose to pay to upgrade themselves ASAP)

It won't fit all business models / products but seems practical in most cases.

Why is it ethical to ship a low quality product to generation one customers? I think you're breaching ethics anytime you aren't providing a decent quality of product.

Some products are a great fit for releasing something quick and fixing it later, like a free website. Other products, especially physical goods (car parts, medical equipment, etc) this is obviously a terrible strategy.

Because, from the article, you never know you're shipping a low quality product at the time you ship it.

Failure modes are complicated. It's not as simple as "Ah, this thing will obviously fall apart in a few months."

Reply on news.ycombinator.com