Ask HN: We need to launch but our service works 1/4 of the time, what do we do? | Hacker News Reader

Ask HN: We need to launch but our service works 1/4 of the time, what do we do?

3 pointsflounderfounder11 comments

A few friends and myself started building a virtual reality application for the medical industry a few years ago to help with surgery planning and practice for residents. All of us have been putting in time on the side of our day jobs and can’t be full time until we get revenue or investment.

We shopped it around when it was still just a pretotype and our target market loved it and wanted it immediately.

Fast forward to this weekend and we were planning on sending the big launch announcement out on Tuesday to the folks who expressed interest (~100). Unfortunately it has been issue after issue with the UI/UX, rendering not loading consistently and navigation throwing problems.

We have some serious investors that we have been negotiating term sheets with and they all seem ready to sign as soon as we launch but not before. We even have a meeting this week to talk through our term sheet with an Angel group’s board.

I know the "just ship it" mantra and all that but I feel like if we do, we will kill our customer base out of frustration with the product and they will just abandon it. It feels like time is running out and either investors are going to walk or someone is going to scoop the product and market if we don't release soon.

Do we push a broken product to our (~100) interested users or do we wait till it is consistently working and then launch?

Does 100 users represent a small or a large portion of the total addressable market? If it's small, just ship it. If it's a large portion of your addressable market, then choose 5-10 of them and give them early access.

Either way, be up front about all the known issues and your plan to solve them over time. Keep in close contact with your users and gauge their reactions. If the pain point that you're addressing is large enough, there's a good chance that a product that works 25% of the time is better than no product at all. If, on the other hand, you learn that the product is too frustrating for them to use, at worst you've only burned through a small fraction of your addressable market. And honestly, you can probably gain a good percentage of those back once you do perfect the product.

I also wouldn't be too worried about someone else coming along, scooping the product and beating you to market. You've been working on it for years and you still haven't perfected it. That suggests a certain degree of technical aptitude is required to build the product so I doubt anyone can swoop in at the last moment and steal your thunder. The only way for that to happen would be if there's another team already building a product similar to yours in which case, yes they might beat you to market. But unless there's a network effect involved, the better product of the two will likely win out in the end regardless.

It's actually a tiny portion of the total market but does seem to represent some big players within it.

I think you are right with not being as concerned with the overall impact as we are. We aren't really worried about someone scooping the idea, there are other players in the field who could implement our same technology and we are trying to make sure we capture a bigger market before they offer anything.

Thanks!

Launch in closed Beta. Be upfront with the customers that you accept in your Beta program. They can be extremely forgiving with bugs as long as you inform them before hand and especially if there is no alternative to your service.

Choose the best 10 customers for a Beta 1 - and go through a rapid phase of issue fixing. Then increase the number of customers for Beta 2 by another 10. Continue in this fashion till all your issues have been fixed.

Is it really broken for the users or broken is your definition of broken because that's your baby and your dreams etc etc etc? If this 25% working part represents something that users could actually use, and you are all under pressure (for whatever reason), than ship it but ship it with a plan. E.g. let the users know what's missing and what's your plan to ship the rest of the service, and possibly show them a milestones timeline so they see this is not the crappy final version of the whole thing and that you are working hard on the other 75%. That will also help with the thing about your investors by the way, I guess. Of course, that's only a very personal opinion. I have never shipped a service or product like that but as a paying user/customer I would appreciate this approach.

>Is it really broken for the users or broken is your definition of broken because that's your baby and your dreams etc etc etc?

That is a part of it certainly but when we are doing our unit tests about 1/2 to 3/4 of the time the service doesn't do what it should and the user has to reload all their data from scratch (takes about 15-20 minutes).

>let the users know what's missing and what's your plan to ship the rest of the service, and possibly show them a milestones timeline so they see this is not the crappy final version of the whole thing and that you are working hard on the other 75%.

I like that approach - largely because all of our first customers have been really enthusiastic and engaged in the product development. Thanks.

I may be able to help you fix it.

If you're interested send me an email, my contact info is in my profile. Please indicate what technologies you are using (ie. OS, language(s), 3D API, any major dependencies, etc.)

It sounds like you're budget constrained, equity-only is a possibility.

Thanks I will be in touch.

Ship it and iterate. As long as there isn't a crippling series of bugs that prevent the users from going through A > Z, then you should be fine.

MVP FTW

Strip it down to the bare minimum you can have working in a hurry and hide the other features till they're ready.

The thing is, we don't have any extra features because we wanted to nail down getting our core service right. So the key process that is the primary feature is the thing that only works about 25-50% of the time right now.

Identify one simple reason why it fails, fix it and put in a unit test (or something in your build process or whatever) so it doesn't happen again.

Reply on news.ycombinator.com