The point of The Lean Startup isn't to give you advice to run a successful VR/gaming company, though. It's to teach you that your assumptions are probably wrong, and you should figure out ways to test them and get feedback as quickly as possible. It's easy to run a bad test or misinterpret your results -- which is I think what you're getting at -- but it's still important to test things, and at least for me, it seemed like that was the main takeaway from the book.
I think part of why I didn't enjoy The Lean Startup was because I read it too late. By the time I read it, MVPs, "fail fast", and "make something users want" had been the motto of startups for years, and the points the book was making just seemed obvious. Maybe that wasn't obvious in 2011. (Although Paul Graham's essays have been saying this since at least 2005 and are a much better read IMO.)
But the other part was that it was just poor science, relying almost entirely on anecdotes for its claims. Which is not to say his claims are necessarily wrong, just that for any claim that isn't obviously true, there's no convincing data to back it up. There's usually just one success story where it seemed to work, and even within the story, it's hard to know if the strategy was actually successful. Like, as I mentioned before, the book passes off learning the users preferred teleporting to walking in IMVU as a success story, but it may have in reality been the inferior choice. We can't know for sure, but we do at least know other more successful virtual worlds have walking. IMVU never even tested walking. It undermines his credibility when he seems oblivious to his own possible failures. It's a lot of, "this is what we did, and I think it worked out well". Despite advocating split testing, he never split tested the techniques he advocated. There's no control - no baseline to compare to.
Or when he prefaces the chapter on small batches with a third-hand story of a father and two daughters who had to address, stuff, and seal a stack of envelopes. The daughters, aged 6 and 9, felt it would be faster to address them all first, then stuff them all, then seal them all. The father thought it would be faster to do them one at a time. So they each took half the envelopes and the father won.
I enjoy stories, but a 3rd hand anecdote about a father stuffing envelopes faster than two children is just... why? That's not going to convince anyone. He then calls back to this example several times when explaining how to apply this at a software startup (release frequent small updates, use continuous deployment). But even if one-at-a-time envelope stuffing is faster, and the startup advice is right, one does not imply the other. Just cite an actual study, or do an analysis of what was successful at other companies.
