Ask HN: How to show a not “so perfect” MVP to potential customers?
52 comments
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.
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.
Many insightful comments here in this thread, thank you all very much. I'm really afraid we can't solve a "mediocre diction" problem. The problem is that speech to text still is a open subject where noise and diction could ruin many tools, but in the ideal world (no noise and good diction), accuracy is around 80-100%.
> 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'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).
> 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).
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.
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.
General rant incoming:
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
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
[deleted]
This ^
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.
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.
What about clients who "want that one feature that isn't present currently but you show your future roadmap does so they will wait till you get there? "
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" ?
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" ?
"I would buy if you had this feature..." is one of the most deceptive ways of saying "No thanks, I'm not interested."
This!! I worked for a startup and we were always chasing the "I would buy if you had this feature..." feature for every company who didn't yet buy the product. It was a total mess. And worst of all most companies didn't buy the product once we implemented the exact feature they wanted.
This is great example of setting expectations. Plus I think getting the answer to "does Phase 1 have enough value?" is super important early on, even if the answer is no.
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.
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.
> 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.
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.
> There are only two kinds of programming languages: the ones people complain about and the ones nobody uses.
Now replace programming languages with products.
Now replace programming languages with products.
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
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.
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 traditionally called a "demo."
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".
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".
> 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.
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.
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.
> Vista turned out great!
That's debatable.
That's debatable.
It was at least a step up cosmetically!
It was a joke. Forgot the /s
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.
Adding to this if voice recognition is just the first part of a process can you eliminate it? Can you show them an example of how to use it based on text? For example “type your command/query” instead of speaking it.
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.
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.
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
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.
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.
In this context wouldn't MVP mean minimal viable product?
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.
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.
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.
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.
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.
People want a product that works for MVP in most cases. If you are a brand new tech that no one has ever done, okay. But if there is even 1 competitor that kinda works, a mock-up is worth 0. So I think depends on the market for the product.
i disagree here! Not because i think you could not be right, but because there is much more room in one space.
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.
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.
Is you goal to get VC funding, or is your goal to sell to a client?
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.
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.
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.
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 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.
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.
> 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...
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...
Don't show the product, show the end result.
For instance, you could shot AI generate content, images, text, etc.
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.
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?