@mattm
I know where you’re coming from. It’s great that you want to plan things ahead.
I second grokcode’s “welcome email” idea.
Please keep in mind xecretcode’s point about the manual. Don’t write manuals, write FAQs. Nobody reads the manual, because the manual is about your software. What people care about is their problems. That’s why FAQs work much better. An article called “How to do X with ProductName” solves a user’s current problem. A chapter of a manual called “A list of ProductName 200 keyboard combinations” is information that the user might need some day, in the future. It’s of no immediate value to them. That’s why this kind of information is easily overlooked and forgotten.
The specific question you’d ask depends on the type of product. Is it a SaaS? Is it a free demo + a pro version? Is it a paid-only product? Is it a mobile app? If your product is free, you are the one who has to reach out to your users. The free users will not contact you to tell you what is wrong (in 90% of the cases). They will likely move on, because they haven’t invested anything in you (other than time). If it’s a paid product, don’t worry, they will give you feedback. For example, we are currently running the MVP of a third product (paid-only) and each one of the users has contacted me. Since it’s an MVP, they have a lot of questions, find bugs, etc. And since they invested money in us, they write to support. We get our feedback, they get their fixes and improvements.
At the MVP stage, I’d focus on (1) finding out what essential functionality people are missing and (2) improving the usability of the design.
IMO, do not ever ask the “How can we improve?” question. The worst thing about it is not that it’s vague. The worst thing is that it makes people imagine problems. If you ask someone this question, they will always find something that could be improved. My advice to you would be to build upon real painful problems, not random wishes. Otherwise, you are likely to bloat your software with features that nobody needs. So, always look for problems.
I recommended questions you should ask, so far. 
Ask Yes/No questions, but don’t accept “Maybe” as an answer. People like the security of “Maybe” and many will choose it. On your end, you get no information from a “Maybe”. Make them choose between Yes or No. If you have a Yes/No question to ask, you might repurpose Zingerman’s one second email survey (Google it, I’m not allowed to post a link).
In my personal situation, I communicate with each one of the users of our MVP. I’ve asked several of them: “Could you briefly describe your workflow with ProductX?” As paying users, they are motivated to contribute with feedback. The answers were surprisingly comprehensive and useful. From their replies we figured out what features they could benefit from, some of them thought of the features they needed while describing their workflow, new problems came up and we got a better overview of how people actually used the software.
You could also ask “What is the main task that you use ProductX for?” For example, we thought that people would be using our MVP for one purpose and optimized for that, while in fact, they mainly use it for a different purpose. So, now we’re going to re-optimize. You might find yourself in a similar situation.
Another question that you can ask, if you have a free demo which promotes a paid product, is “What is the main thing that is holding you back from upgrading to the paid version?” You are indirectly asking what could be improved. But, with this question, you’re trying to pinpoint your users’ biggest problem. What is the one thing that is so important to them that, without it, they won’t purchase? Maybe they don’t need it at all? Maybe they found a better alternative? You might find this useful, in case you’re building on the “free demo” model.
what marketing language best fits with my users’ mental model of my product/speaks to the problem I’m solving?
Ahh, marketing… Find where your potential users hang out. Are they accountants? Find an accounting forum and read carefully through the first several pages. You will find what their problems are, what they care about, and you will find out what language they use. Take notes. Then, with the data of your observations, go back and re-write your marketing text. As @Andy cleverly described it: Marketing = Hacking the Human It requires a lot of thinking, if you’re going to do it right.
All this might sound overwhelming, but everything will fall into place over time.
Good luck!
—Gergana
