It's worth noting that "things knowable from third parties" and "an aggregation of all your things knowable from third parties" are very different risk profiles, if that's the deciding factor for anyone.
More are urban than non-urban, so the national average isn't a particularly useful number either.
Here's a relevant page by the Bureau of Labor Statistics. If you scroll down a bit past the state-level charts, they start showing metropolitan areas. "San Jose-Sunnyvale-Santa Clara" has a fairly good compromise between volume and density, but it's not at the top of either chart.
Have the best person answer the question, even if that means one person does 90% of the talking. Marketing question? Tech question? Maybe different people answer those. You're there to get your best answers across, not to show off how well you can take turns speaking.
If one person is visibly moderating your side's responses by directing it to the correct person, that's not a bad thing either, re: "Who is the CEO?"
"What features should I add" is another trap question. Avoid this.
You want to study the people & problems you're targeting to the point that you become the expert they're trusting for advice about the problem. This is hard, but not that hard - minimum viable expertise is a thing as well.
For example, not everyone who uses email as part of their hiring process has spent an enormous amount of time studying how to improve contact-to-interview conversion rates. Specializing on this & studying across N people who are a close match for your target customer can quickly give you working expertise on the problem, because everyone else is worrying about 10 other things at the same time when working with it, while you can go deep on that one thing.
Then based on your understanding of their workflow & what ought to generate value (as obtained by talking to those people in a learner mode vs. a sales mode), you generate a hypothesis and test it. If it actually helps deliver value, and the problem actually matters, and you actually understand these people well enough to get them to trust you...congratulations, you might have yourself a viable product.
For the above example, you need exactly zero unique software to pull this off. You can start as a completely manual service with direct sales only against the people who you think will be most likely to buy. Give yourself the easiest win conditions you possibly can, requiring the least time and investment. Then, build on that, add automation as appropriate and test that the value is still delivered, try to scale, etc. - but start with the scaleless version, it ships easily and then you have actual customers who are paying you.
> How many startups fail because their MVP is too minimal?
None.
They fail because they didn't talk to customers, didn't do sales, didn't do marketing, or failed to find a viable service model after all that.
MVP is shorthand for "do the least work customers will pay you for." Customers are shorthand for "people you can find who will pay you."
MVP is quite often abused to mean "here's a thing I made." If you don't have customers, and you can't find customers ... then it's not viable yet, is it?
Here's a thing you can do:
You have a hypothesis that [service you can provide] will be valuable to [people you can find]. Okay, so go check that you can actually find those people. Then talk to them about what they do.
You are not allowed to sell, or ask "would you buy this." Facebook surveys are also right out. You need targeted customers, not a bunch of random people with few common characteristics besides being bored enough to respond to Facebook surveys.
Your objective is to learn about these people. How do you find them? How do they talk about the problem? How do you tell them apart from people who really don't give a shit about the problem?
Once you've got a target customer validated at the talking-to-people level, then you can try building stuff. Start with the least work that you think will get people to pay you. It's probably much smaller than you think, and may involve no code.
You don't need to solve everything that anyone told you about the problem, you just need to do enough to make their corner of the world a little better.
Then, go back and try to do sales. Face-to-face sales is the highest conversion rate condition you're ever going to have access to. It doesn't have to scale to infinity million dollars of revenue. It's validation. (Although it's also quite possible to get to stability on boot sales alone, if you charge enough. Which is the only time I ever want to hear that "with no marketing" meme.)
If you can't sell when the deck is stacked in your favor, you don't understand your customers, or you're working on something they don't actually care about.
Treat stuff as a hypothesis. Then test it. Don't just throw code at the wall either. Code without a customer is not a product, it's just some thing you made. Figure out who the customers are and aren't. Then try to find them & talk to them. Learn about them. Then build.
Nobody failed because their MVP was too minimal. They failed because they didn't have customers & didn't do the work to fix their understanding of the world.
Yup. Small multiples of price inefficiency mostly don't bear thinking about until they group together in large batches. The time it takes your engineers to work out the difference is rarely worth it.
"False positive" has a precise meaning in statistical analysis. The second thing you're talking about is useful to know, but calling it the false positive rate is just wrong.
"Out of 1000 positive tests, 50 were false positives, 950 were true positives" - valid statement.
"The false positive rate was 50 out of 1000" - abuses a common technical term in a way that sounds valid on the face of it, but which is potentially VERY misleading.
We can't even calculate a valid false positive rate from the above data, since that requires taking the ratio vs. all tests and not just positive tests.
I'm not surprised at all...the whole point for Amazon is ebook sales, they want install base, it's nice if you upgrade your device but many people will keep paying for books regardless of device version.
Throwing a few engineering headcount at keeping updates going as needed is more than worth it, and a more exact "when do we stop supporting this" trade-off can easily be calculated against usage and purchasing data since they have vertical integration to that degree.
If you tell me what your thing does, I can probably get a working prototype together within six months, even absent any more technical detail than "applying deep learning to audio processing." That's the nature of the thing. Once you show people that something can be done, they can probably figure out a way to do it themselves. If they really wanted to, they could probably even toss a bunch of patents in your direction and work out the specific details later.
So while I would avoid spelling everything out & focus on practical / business details...you're mostly worrying about the wrong stuff.