Hacker News new | comments | show | ask | jobs | submit login

Fair critique. I didn't write about the time we spent contacting our users and enabling the shares to happen. The key is that they expected the site to automate the process, and were always disappointed when they received a manual email from us. We have the relationship, but it's one that starts with an apology instead of a "How can I help you?"

I don't understand. As pointed out, the whole idea is that you're doing everything that code would do, maybe even better. The only possible disadvantage is the speed of handling requests. Why would customers be disappointed with that?

I cannot defend the reaction of users, they just often expressed disappointment with a "broken" system.

Like going to an ATM and then getting a phone call saying, "Hi! I'm your bank teller processing the check you just deposited into our ATM" It's a strange experience and they expressed disappointment while referring to it as broken.

I think this aspect is often overlooked in the MVP discussion. Customers are trained to have certain expectations fulfilled and when they're not met they perceive things as broken, as you observe.

I think the examples of MVPs that have worked best appear to be targeting other startups or folks in the industry with a high degree of tolerance for failure and understanding of how this all works (and therefore patience with the process).

But most real-world customers end up disappointed with this kind of thing. So far as I can tell a lot of MVP-driven startups just accept that they'll lose a percentage of their early adopters over this.

Worse, and I have some experience of this with a startup of my own, often MVPs come with the need for investment $$ to make them truly viable. So what to do? Well get 10,000+ folks signing up and using your system, in just a few weeks, and showing it's got great demand (that was a big number for the space). Yet the more you ramp up early adopters the bigger the cliff when you still hear crickets on the funding trail and never manage to afford to give those customers - many of whom have invested a lot of time and energy in your product - what you promised them.

Many folks are okay with this. There's something almost sociopathic about many young inexperienced entrepreneurs who don't appear to think about the real world consequences of abandoning their early adopters (and their efforts and data).

> I think the examples of MVPs that have worked best appear to be targeting [...] folks [...] with a high degree of tolerance for failure

Yes. This is true for almost any groundbreaking product. The book Crossing the Chasm is the classic work on the topic. Almost any startup should seek out an early-adopter audience of people who need the product so much that they're willing to put up with flaws.

One thing more startups should do is narrow their marketing to the early adopter audience. Everybody else, you try to defer until you have a more solid product.

What's your company?

Current company or the one I'm referring to when in the post above (which was prior startup)?

There's a repeated language of apologizing and feeling guilty here. I think this is dangerous because it says "I have done something wrong to you, customers, and I know it" and maybe even "and I did it on purpose". It's an invitation to complain, and even to be angry. It's important to apologize when it's warranted, but really I think it might be productive to think exactly about what is "wrong" here and how to address that. Is it because features are missing? Software is never done, toughen up. Is it because they aren't getting what they were promised? As other commenters have said, you want to give them the real product, just use elbow grease instead of technology. Is it because you're taking money? Give refunds or credits as appropriate. Etc. I think there's a way you and your customers can feel good about where you are and where you're going, you just have to find it and keep moving!

You manually do what an automated system would do, so it's indistinguishable to users. You are the implementation of the specification of your system - which enables quicker iteration of the specification. If you need responses from users, you can make up a webpage form (e.g. that emails the form details to you).

I don't see why you allowed the system to feel "broken" to your users in the first place. It sounds like you asked them to do work when you could have said "we received your request and we'll get back to you" and done the work yourself.

In your ATM example that would be a deposit that takes 24 hours to appear in your account because the bank collects the checks every night and processes them manually. Not as awesome as the ATM using OCR to evaluate it on the spot but much easier to setup if you want to test if the service would be useful to ATM users.

The point of an MVP, as I understand it, is to determine if people want your idea enough that they try to get some value out of it. All the bells, whistles, and automation you could add to make it a less broken experience are a complete waste if you don't have people to use it.

The nearly hyperbolic (but unfortunately all too real) history of Webvan[1] is why MVP is important. They spent over a billion setting up oodles of infrastructure for a service that they assumed people would want... turns out they didn't (at that price point, at that time).

Had they spent a few thousand up front to roll it out in one town as an MVP, they might have failed fast enough to live to fight another day.

[1] http://en.wikipedia.org/wiki/Webvan

Why in the world did you let them know they were receiving a manual email?

We faked a ton of "automated" email notifications and nobody ever caught on. The CEO did most of the fakery and it was really beneficial for him. He got to try out a lot of things and see what worked. Once he had something stable, we actually baked it into the product.

It was especially use with matching algorithms. After doing things manually, he could say, "Well, the key factors for a good match are X". And he had actual experience to back it up, not the sort of handwavey notions these things often get built on.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact