Live data from Hacker News

Ask HN: How to show a not “so perfect” MVP to potential customers?

news.ycombinator.com

51–53 of 53 posts

Re: Ask HN: How to show a not “so perfect” MVP to potential customers?

#51
You want to prove that X can solve their problem. You might not have X, but you can prove that you've tackled the riskiest challenges to producing X.

This is what's called a prototype, not a product. A product works as is and should probably handle whatever diction the customer throws at them. Prototypes are proof of concept.

However, people have always put up with lower quality products as long as it solves the problem. Look at the early decades of computers. What UX? Look at AWS or the average CRM. If they can't improve the user experience, just offer training to the product operators.

Re: Ask HN: How to show a not “so perfect” MVP to potential customers?

#52
post #23

Earlier quoted context omitted.

Sorry, and yes you're right. So the question is: how to present a product that will always have some kind of limitation? It will solve a problem but under certain circumstances. But I think the answers here still apply.

Be fully honest. At least with me, it adds points if a supplier communicates limitations well, even without me asking for it. Being promised the end to all problems raises my skepticism 10fold.

Yes fully agree here — a rachet screwdriver is very useful without being an electric screwdriver.

But if you sell me something as an electric screwdriver and then I need to use it manually, you've set me up for disappointment.

Re: Ask HN: How to show a not “so perfect” MVP to potential customers?

#53

Like I said on another thread: Instead, every "MVP" project I've been on has ended up as the final shipped product. Often with no further improvements at all, let alone anything the user asked for. Big Agile really has poisoned the industry. Basically you need to be very careful. Like another comment said it could even be just mock-ups which are much easier to change.

In our case, I've found our customers just aren't very good at imagining things that aren't in the user interface or actions that aren't implemented. After all they're not developers, so likely aren't used to imagining user interfaces and interactions. Regardless, the result is that if what we show them ain't pretty close to how it'll look and work, they won't get it and will have a hard time understanding how it wil…

> Since we have several decades of combined domain expertise inhouse

Honestly this sounds pretty much like a luxury and as far as I can tell pretty rare. Maybe it's a country thing but in the UK many tech companies seem to have a "product team" with a collective memory of no more than a few months leading every decision. We don't have any BA's or anyone that can get requirements from customers. Seems to just be "here is the feature we decided you need" and then they wonder why the customer doesn't like it...

Post reply on HN