Ask HN: How to show a not “so perfect” MVP to potential customers?
Hello.
I know that MVP is not about the finished product, but you need at least to show some reliable experience to potential customers.
I have an MVP in the AI field, but in order to have accuracy and a fully satisfactory experience, it requires some conditions, because it deals with random variables that I still don't have full control over (i.e: I need people to speak with good diction/utterance).
How can I present this to potential customers so "random variables" wouldn't discredit my product?
52 comments
[ 2.6 ms ] story [ 117 ms ] threadWhat 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 under this advisement apple never would have gone into phones. There was literally a phase were we were joking that somebody is building the "uber for X" or the "tinder for y" and im pretty sure a lot of those did get funding without having a single line of code in their names.
To get VC funding, if the market is frothy enough, you don't even need a MVP, just a power point and a fancy resume.
To sell to a client is what I was more along the lines of.
For instance, you could shot AI generate content, images, text, etc.
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.
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 will affect their workflow.
So we end up having to implement a fair part of the solution just to get some feedback that we can iterate on.
Since we have several decades of combined domain expertise inhouse, we're typically pretty good at guessing what the customer needs or wants and usually don't have to change much.
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...
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.
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.
When consulting, I could always tell which clients had serious traction: Even if their product was incomplete or buggy, customers would literally make a line at a trade show to write checks, because they wanted the product that badly.
In extreme cases, "product-market fit" just means the customers are saying "Shut up and take my money!" It's like watching a rocket-ship take off.
Not all successful startups take off like this. But the ones that do have a much easier time succeeding.
Now replace programming languages with products.
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.
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.
> I'm really afraid we can't solve a "mediocre diction" problem.
So you're not asking "How can I present my work-in-progress to potential customers so that they focus on the potential & not the missing features?".
Instead your asking "How can I present a product that has (and always will have) limitations?" and so will never have a "fully satisfactory experience". Is that right?
I think this is an important distinction (that I didn't get from reading your original post).
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.
Feedback, in the UI sense: one of the biggest annoyances for me is using Google Auto. I issue a voice command and it says "Sorry, I don't understand 'navigate home'". Clearly, the audio process was fine, clearly the voice-to-text interpretation was fine, 'navigate home' is a command it recognises, so I deduce there was some back-end error but it's not specified in the applications feedback. It seems it would be super easy to check if the phrase they're telling the user that they don't understand was in a list of common phrases that the application handles. "Our app works best in a brightly lit environment, with microphone noise filtering turned on, and a clutter-free high-contrast background".
Like, I wish computer games came with (free before you buy!) simple benchmarks; "if you score above 100 on $benchmark you should be able to run at 60fps on default settings; above 200 75fps on max". Then it's really easy to know things are working or if you need to monkey around with drivers and settings and such.
IMO if you're struggling to get good input then you should score the input against the characteristics you want to improve, like "30% for audio quality, 80% for recognised commands, 50% for gesture quality;" change the score on the fly so users can easily tell if they're doing it right?
/ranty-mc-rantface
Do customers say the thing have value at the current stage?
If yes - start charging for that value.
If no - it’s not an MVP yet.
There is a chance without revealing your roadmap, they "mught" have gone with the current version, like you make a pitch and they like it and want to buy but then you show your roadmap and they are like "oh nice. Let's wait till you reach this" ?
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.
That's debatable.
Also colloquially known as the "rigged demo".
Let's be clear, there is nothing wrong with a rigged demo. A rigged demo is no different than a magic show. Folks love magic shows.
However, there is a big difference between a rigged demo and lying to the audience. All of those slide decks, static screens with "just one button that works", "demos on rails", they're all legit. It's ok to talk hopes, dreams, future capabilities, and what it should be capable of. But you can't (shouldn't) do that and tell them that "this'll be done next week". Shouldn't give false expectations.
It's a fine line, to be sure, but it's marketing. You can have honest marketing without highlighting all the ways you currently fall short. Everyone needs to do due diligence. A rigged demo may seem like 3 Card Monty, but it's not. 3 Card Monty is designed to deceive. A rigged demo is designed to highlight and exemplify. Yes, there is a difference.
In the end, the hard questions will come, and you need to be prepared to answer them honestly. If they don't come, you should be upfront about them. Address unsaid concerns. But that doesn't disqualify the use of the "rigged demo".
Showing a video of a demo is in itself not a bad thing - that's often done when you want to show early builds or even a patchwork of work across multiple builds.
Depending on when you saw the Longhorn demo, it might be inaccurate to say that Longhorn became Vista. I worked at Microsoft (not on Windows) back then and saw some flashy demos of eye-candy UI in the 2003 timeframe that never launched, except as a beta build that was given out to external developers late 2003 at the PDC (conference). The original Longhorn, demo-ed at PDC 2003, was abandoned in mid-2004 and was pivoted to the Windows 2003 codebase. A lot of the features originally planned / demo-ed for Longhorn (new filesystem, XAML-based UI etc) never shipped.
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.
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
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
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.
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.