Exactly. But a time when you can take it at face value is when the question is something along of the lines of "will you sign a purchase order for this right now?" or the like.
And to tie back to what someone in another post here said about validation: one of the best way to validate that your solution is real, and will actually sell to the customer (which is the only thing that matters, from a certain point of view) is exactly to ask your customer "will you buy this, right now?" or a close variant. If the answer is "yes, send the bill and get the order underway" then you've validated something. If you get hemming and hawing and "well, maybe, let me talk to the purchasing committee" or whatever, you're still just thrashing around.
And even if you don't go for the actual sale yet (maybe the product isn't ready yet) you can take the approach Steve Blank[1] talks about, and work up to a questions of the form "would you pay a million dollars for this right now" and "well, how much would you pay for it then?" and "if I offered this to you FOR FREE right now, would you start rolling it out immediately" etc. Those answers will really tell you something about where you really stand in your customer's eyes vis-à-vis actually selling your thing.
[1]: https://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/09...
[1]: https://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/09...
The story here gives the origin of one his most critical 'Epiphanies'... "Get out of the building".
"The Four Steps to the Epiphany" [1] and "The Startup Owner's Manual" [2]
[1] https://www.amazon.com/gp/product/0989200507/ref=as_li_tf_tl...
[2] https://www.amazon.com/gp/product/0984999302/ref=as_li_tf_tl...
That process is definitely different in an enterprise market. For whole-hog adoption, giant companies will want a mature solution. So instead you find ways to derisk it. Maybe it's a pilot program with a larger player. Maybe it's proving out the technology in an SMB context. Maybe you just find one mom-and-pop hotel who pays you not in money but in their time and data. Maybe you start with a single floor or even a single hotel room into which you preferentially book people who you think will be early adopters.
The M in MVP is for Minimum, and that applies not just to the product, but to the context of use. You start as small as possible, just enough to test your hypotheses. The smaller your tests, the faster you learn.
He makes another rookie mistake here: "I still need to buy the same number of tablets to rent to hotels, and can’t even really discount the product that much." Lean Startups are not cheap startups. It cost Toyota millions to build the first Prius, but they did not sell it for millions. That's fine, because the point of your early MVPs is not to cover the expenses. It's to learn things, including about what people will pay. In Lean thinking you price based on value, not cost, and then work hard to minimize costs while maintaining value.
[1] https://en.wikipedia.org/wiki/Crossing_the_Chasm
[2] https://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/09...
I'd suggest you consider reading The Art of the Start[1] by Guy Kawasaki, The Four Steps To The Epiphany[2] by Steve Blank, and High Tech Startup[3] by John Nesheim. Between those, they cover a big chunk of the basic stuff you need to know.
The Founder's Dilemmas: Anticipating and Avoiding the Pitfalls That Can Sink a Startup[4] also has a good reputation, but I haven't had time to read it yet, so I can't give a personal endorsement. But it sounds like it might be worthwhile.
FWIW, though, I can tell you what we did at Fogbeam[5]: The company is organized as a legal entity, but we are an LLC right now, not a Corporation. I would not necessarily recommend doing that to anybody else though... while it is possible to build a big company as an LLC, practically speaking, if the intent is to build a scalable startup, the kind that's going to seek VC money and that you ultimately hope to IPO, you need to be a corporation. VC's essentially will never invest in an LLC (there are technical reasons why) and LLC's have serious limits if you need more than a hundred or so "shareholders" (I forget the exact number, but it's a pretty small number). The reason we are an LLC is a historical coincidence, rooted in weird shit that happened back when I was planning to start a consulting company, before deciding to do a product. Fortunately the prevailing wisdom is that it's fairly straightforward to convert from an LLC to a C Corporation. When they day comes that we need to do it, we'll switch.
As far as equity distribution, we have been operating on a handshake agreement between the founders. Technically speaking, I own 100% of the company "on paper" since I'm the only Member listed in the LLC operating papers. But that is, again, only a historical legacy. I created the company and worked alone for the first year before inviting the first co-founder onboard. It would be easy enough to amend the papers to update the equity split, but we've basically taken the approach that "well do that when we convert to a C corp, or there's a specific need to" (like, if we get an acquisition offer). So, yeah, we are operating on trust at the moment. A lot of people will recommend against doing that sort of thing for various reasons (see: The Social Network for example), and I have known friends who got screwed by co-founder disputes because things weren't put into writing up-front. If I had to advise somebody, I'd probably advise you to decide on the equity splits, intellectual property assignments, etc. up-front, and formalize everything from the beginning just to be on the safe side. The downside to that is, it costs a little bit of money and time. shrug
As for YC... nothing against them, but I'd never make a decision based on "what YC wants". But I look at all accelerators / incubators / etc. as "something that might be nice to do, but we'll succeed with or without them." Being that we are an East Coast startup with constraints that would limit out ability to move to CA in order to do YC, we've never even applied and probably never will. If doing YC is super important to you, then maybe you should treat this a bit differently. It's up to you.
Design document? Meh... I mean, yeah, but no. Not exactly. You need to know something about what you're building, but as a rule, you probably won't know exactly what you really need to build to achieve "product / market fit"[6] right away. So no sense spending months on an elaborate BDUF design doc. Sketch out the high level design, and IF you wind up subcontracting any work, then you'll have to formalize a spec for the contractor. But don't spend months and months designing something nobody wants. "Get out of the building" as they say, talk to customers, and iterate the design as you learn what people want/need.
[1]: http://www.amazon.com/Art-Start-Time-Tested-Battle-Hardened-...
[2]: http://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/098...
[3]: http://www.amazon.com/High-Tech-Start-Revised-Updated/dp/068...
[4]: http://www.amazon.com/The-Founders-Dilemmas-Anticipating-Ent...
[6]: http://www.stanford.edu/class/ee204/ProductMarketFit.html
I am kind of surprised to see Steve Blank's "The Four Steps to the Epiphany" (http://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/098...) omitted. Is that one that everyone mentions, but nobody reads?
There are a lot of variables, and luck does play a big role. But with that said, there is something very akin to a "formula" at the high level. That being Steve Blank's "Customer Development" methodology, as laid out in The Four Steps to the Epiphany.[1]
[1]: https://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/09...