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

Key is to position the product evolution from this point as a journey, with discrete steps/periods on a quasi-roadmap, and make it clear to them that they as users/clients will help shape that journey.

So picture a slide with 4 steps/phases enumerated, and a talk track like: "Today, we're at Phase 1 which provides the most important feature XYZ but has some constraints around diction; next, in Phase 2, the algorithms will allow for even mediocre diction and feature ABC will also come online deliver 123 value; in Phase 3, we'll have enough data that diction is a non-issue, and features DEF and FGI are planned".

So the core question is - does Phase 1 have enough value? Is that journey/roadmap worth it for the customer putting up with limited value today?

You might be surprised either way. If even the limited experience is still super valuable, great! Or you may find that you DON'T have an MVP yet since it's not usable in its current form regardless of the journey from here.

They won't mind obvious issues as long as you can show progress towards solving their pain point.

In 2010 I worked on a 3D audio mixing software. The first beta crashed every 30-60 minutes, losing any unsaved data. People truly hated that. But mixing for 22 speakers + 2 LFE by hand was still an order of magnitude more painful than dealing with our buggy beta.

So our customers were (rightfully!) complaining all the time. Yet none of them was willing to wait for the first stable release. After trying the beta, they were hooked.

If you want to se the ultimate MVP demo of a product look no further than the 2007 introduction of the Apple iPhone - https://youtu.be/MnrJzXM7a6o

It was not a finished product and the dev team was terrified that the system would crash. In fact you could argue that the first iPhone was an MVP released to the public.

These would help:

- Be upfront that this is an MVP. Do not try to sell it as a product that is a finished product

- Create a script that shows the core working functionality

- rehearse the script and make sure the feature list demonstrated and that you can run through the script

- In your case, is it possible that you can dictate (you need to control the variables)?

- Ask for feed back. Listen. Do not try to defend the product.

Hope this helps

That's traditionally called a "demo."

The time-honored way to do demos, is to show a lashed-up, duct-tape-and-baling-wire abomination, in a carefully controlled setting.

I have seen companies plant shills in the audience, to generate those "random questions."

The best was when I attended the "Longhorn" demo, at Microsoft (Longhorn became Vista).

The marketing person gave this great demo of all the eye-candy UI, and kept saying "This is live code."

Then, at the end of the demo, you could actually see him, closing the Director show. The rest of the demos did not have the eye candy.

Vista turned out great!

I'm not really a fan of MVPs, but I understand why they are so attractive.

I have long "beta" periods, if I need the same thing.

In the end, I feel that we need to take risks, just like any other product manufacturer. Our product may be a hit, or it may be a flop, but I'm not a fan of officially releasing lashups.

Use a recording in your presentations instead of a live demo A video usually feels "real" enough to an audience, but you can avoid crashers or unexpected inputs.

As a general rule, smoke and mirrors anywhere there are rough edges. In your case, if your demo does not work under less-than-ideal speech recognition conditions, I would not let them speak to the prototype. You could ask the audience for queries and speak them yourself.

First, determine exactly what the goal of your demo is. There are lots of reasons to show someone an MVP - maybe your product has a fair deal of complexity, so you believe that a demo of functionality will help people understand. In turn, that understanding will allow them to better answer business questions ("Does this seem like it would solve x need for you?"). Maybe you have some basic UX mechanisms planned, and you want to test whether they're intuitive.

Once you know what you're looking to get out of it, focus the entire experience on answering the important questions. If there are parts of the product that are important to see for background but aren't critical to actually have the user try out in order to answer your questions, you might be able to film videos of those parts instead of building the functionality.

In your case, if you need people with good diction/utterance, just try to recruit those people. If you're trying to answer the question of whether your software solves a problem under ideal conditions, create those conditions. If it turns out the answer is yes, then you can work on solving for non-ideal conditions later and run user testing with people who have heavy accents later.

The key is transparency make sure you front load your presentation with a lot of this is still in development, its early days but we think this has a lot of potential. Make the presentation about your key value add don't get side tracked with what you want it to do when its 100%.

Make sure you are the one demoing it as soon as the client touches it they will brake it and you will panic. If it brakes the worst thing you can do is panic it looks like its a big fuckup just laugh it off and cary on with what you can show the client will realise you know its early days and understand you are still working on it.

Then focus on business explain you have a solid start that needs a good bit of polish and are starting to build out the business explain your business value and how you intend to work with them around any issues. Explain that getting in at the ground level will allow them to take part in the development and shaping the final product to meet their business needs exactly.

Finally talk about your business plan / critical path where you are now, known issues and where you want the project to be in the future, don't lead with this.

I prefer to build MLPs (minimum loveable product) instead. If your MVP is bare bones and far away from the ideal product, you are effectively working against your core business viability. You instead have proved that an unfinished product is not viable.

Show it to the users in person as soon as possible and ask for feedback if you can. I have personally carried around an iPad around an expo hall demoing an MVP multiple times.

You can also record a low budget demo of your product, and ask for user feedback. The best example of this is when Drew Houston created a demo video of what appears to be a working product. Apparently some of the video is mocked out and was edited and uses camera tricks. Even to this day, it looks like a solid working product.

https://youtu.be/7QmCUDHpNzE

If your goal is to raise money, then you has better make sure you have done your homework for the business reasons and justifications for the product or service.

The best business plans are summarized and laid out in the product or service demo.

I'm still not clear about what your definition of MVP is.

MVPs (product or service users that are loyal and passionate users or influencers) are typically used by large companies that want to generate positive marketing, spin, what have you for their product or service. You sell them, they sell others. Or, you pay them. Yada, yada, yada.

If you are writing here about a "most valuable product," then using the term MVP is silly. MVP indicates your other products are not valuable just based on the usage of that term. Avoid minimizing your products or services.

Prepare for the worst; hope for the best.

What will you do if it doesn't work on the first try? Second try? What's the backup plan? Hopefully you won't need it, but it will make you feel more confident.

Walk through a scenario where everything that could fail, fails. When do you stop trying? What do you switch to? How do you segway? Do you warn at the start of the demo, or just as you are about to do the thing you are worried about, or both? Is the audience technical, should you talk about the randomness or just say "it's somewhat random?" What are the important things to get across, even as things fail. If your brain starts going into panic mode; what are your top priorities?

The second way is to think about the positives of failing. During the on-stage Windows 98 launch party, the demo computer BSODed. Bill Gates quickly interjected with "I guess this is why we're not shipping Windows 98 yet", and everyone got a very memorable moment out of it. What are your one-liners to ease the mood and at the same time shift focus from the failure to the process of development?

Personally, I tend to say "let me try this..." right before I do something I'm not sure will work. If it doesn't do what I want, I (mostly calmly) acknowledge that it needs more work and describe what should happen in the finished product. Getting the word "finished" in there is my "not shipping yet." Then I move on to paint a picture of how the feature will be useful, and why it's worth continuing getting there.

I once saw a demo of a smoke detector. The demonstrator started talking about how much time they spent on making sure it gave no false positives. Then he took a can of fake smoke (used for testing smoke detectors, mind you) and nothing happened. He kept trying for at least a minute, but nothing. Was this a failed demo? Or did he demonstrate that there are no false positives? It's all in the framing of the recovery. I don't believe he had a recovery line, sadly, so I'm sure the part of the audience that didn't remember/listen to his initial speech had a very different take-away than did those who remembered.

I wish you the best.

Who is your ideal customer base and how large/expensive are they? I believe that matters. If you're selling b2b or similar, (infrequent but expensive contracts with a bit of back and forth) I find they tend to be okay with drawbacks like that if A) you can prove value higher than the price regardless of those drawbacks and B) you document the drawbacks well.

I haven't dealt with the opposite end of the customer spectrum, low cost sales/subscription. But from my experience as a consumer I feel like they are more hostile towards those sorts of drawbacks unless your marketing is extremely clear about them.

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.

MVP implies that you show them the most valuable feature. It can simply be a mockup too!

What you need, in my opinion, is basically your core proposition. Like if you build a killer robot, showing that it can hit any target you click on, is nice.. even though it might not be able to move.

If its a webapp, don't focus on solved problems, like Logins or SSO but rather show me what your "x for y" can do. After all the products you do actually buy are the ones, you think, will solve your problems.

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.

Don't show the product, show the end result.

For instance, you could shot AI generate content, images, text, etc.

If the MVP isn't good enough to get useful feedback from customers, you need to either 1) narrow the set of people you consider as early customers or 2) it's not an MVP yet.

You need to nail one use case really, really, really well and impress people. When they ask about other things you can then state that they are in development.

I'd always start with some UI mock ups and a powerpoint going around. Too many people think they need a MVP/product to sell (in the B2B space).

What problem does it solve for your customers? Focus on that. If it solves their problem, it wont matter that it's a work in progress.

Be honest with them and sell them on your vision.

You can just say you're early. If your vision resonates and you're solving a real problem they will be excited.

Demonstrate its success but also demonstrate how it can fail while explaining what you are doing to mitigate failure

Ask them to be design partners.

hard code the random variables so that outcome is predictable.