What questions do you ask your users?

My understanding is that many of you with launched products and services are in direct communication with at least some of your users. If you are in touch with them, what questions do you ask them? Are you asking open ended questions, or specific yes/no/maybe kind of questions? What questions have you received the most useful responses to?

What topics do you focus on? Are you asking generally about what they think needs improvement? Specific questions about how they use your product or service, or about a specific feature’s functionality?

If you aren’t in touch with these users, what questions would you ask if you were? Is there a reason you aren’t in closer communication with your users? I know for iOS apps developers often might not have contact info, but are there other reasons too?

Sorry for packing nine different questions into a single post, I’m hoping to launch fairly soon and I want to make the most from my early adopters (assuming I get some!). Thanks in advance.

One of the best ways I have found to initiate a conversation is to send out a welcome email with details about their account and a note at the bottom that if they want to chat about the site, all they have to do is hit reply. I don’t ask anything specific here (“What do you think of feature X?”) because it is too easy to ask leading questions, and I am looking to get the general pulse of my users and see what is important to them. I get a tons of great feedback this way: bug reports, feature requests, nice words that I can put up as quotes on the website, etc. Also I respond to every single one of these emails, even if it is just a few sentences.

I have also done an online survey, and gained quite a bit of information from that. The survey was more to validate my assumptions around possible revenue streams and site usage, and to get a feel for which new features my users want most. I don’t necessarily build whatever has the most votes, but it is very useful to be able to look at the data and see if power users are requesting different features than regular users, for example.

Good luck with your launch!

Great topic. I’m assuming you mean questions to validate the market before building a product.

In my case, the product is already done, so it’s more a case of the users asking me questions about the basic operation of the software they just bought. What I (re) discovered is that nobody reads the manual, so there’s almost no point writing one. Instead, I’m preparing a set of short videos on various subjects covering the questions I have received.

Some users have come up with suggested features, but I have to remind them that I won’t be able to get to those for a while. Making the app easier to use is my top priority for now. Create value + Reduce friction.

@grokcode Good stuff, thanks for the info. I get what you’re saying about staying general and keeping away from leading questions. Makes a lot of sense. Thanks!

@anon3850446 I’m actually thinking less about pre-planning validation and more about honing the product in the MVP stage. From the feedback I’ve received so far there is a pain that my product will help alleviate, but the specific details (e.g., what would make the app “easier to use”? what marketing language best fits with my users’ mental model of my product/speaks to the problem I’m solving?) could still use tweaking. Does that make sense?


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. :smiley:

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!


1 Like

@sansmagicc Thank you so much for this! I’ve only had time to read through it once so far, but it’s really packed with useful info. I’m going to go through it more in-depth and give it more thought, but I just wanted to thank you for taking the time to craft such a thoughtful and valuable answer.

I’ve had great success in following @patio11’s life cycle e-mail structure. I’ve got a 15 day trial for my software so the e-mail life cycle currently goes:

  • Sign up - immediate welcome e-mail is instructions on getting started
  • 3 days in - e-mail saying “how are you getting on?” (slightly more elaborate, but a short two liner)
  • 14 days - coming to an end, plugging the software features etc.

Replies to the e-mails come straight to me (1st and 3rd say that, since, in fairness, they do look automated…) as Patrick suggests, and particularly the 2nd e-mail has lead to a number of interesting discussions. I don’t have any figures I can readily share (must get around to that sometime…) but I’ve seen a good up tick in conversations and discussions since adding the middle e-mail. Worth having a read through the article and Patrick’s video on his own site if you haven’t yet.



@theallan Ah, great suggestion. I’ve read a good deal of @patio11’s stuff (I expect everyone on this forum has) and watched some of his videos, but I haven’t seen this particular article. I’ll take a closer look at it and give it some thought. Thanks!


Thank you, this is very nice of you to say! I’d really happy if I managed to help you in some way.

I know it’s a lot to take in. It’s really a condensed version of what I’ve learned about the process so far. Each point could be expanded. You just asked a lot of questions, hence the long reply :slight_smile:

Try out different strategies, optimize and iterate. I guess this is valid for any problem.

Thanks Allan, always great to hear when my advice actually works for folks. :wink: