One factor that determines the success of product development is how much value customers get from the product being built. This is why I’m a proponent of surveying customers before, during, after product development.
Customer feedback must inform active product development. Product owners can quickly gather timely information during the development process. This feedback can be used to validate assumptions, provide direction on which features to build, and help understand market fit.
The Value of Quick-and-Dirty Surveys
During product development, a product owner often needs to see current information about her users right away. For instance, let’s imagine that I’m working on requirements for building an app for tablet users. I need to know the most frequently-used device sizes of my target customer segment so that I can give those specifications to the development team.
To find this information, I can look within Atomic Object to see if we’ve gathered information like this before. Also, I can search for existing information from secondary sources such as industry analysts, trade publications, and the like. But secondary information has a shelf life, and it doesn’t necessarily tell me about my specific users.
In this case, I can probably learn what I need from the client by conducting a quick-and-dirty user survey. This type of survey is a good choice for those times when I know exactly what I’m trying to learn, and I need customer data quickly.
Three Misconceptions about Customer Surveys
Before you stop reading, consider these responses to the three most common reasons for not surveying customers.
“We already send too many customer surveys.”
Before I came to Atomic, I heard this argument from colleagues in sales and marketing, and I’ve heard it from clients at Atomic, too. The fear behind the statement is that customers are getting annoyed or tired of hearing from us. Most product owners and managers do not want to run the risk of bothering customers unnecessarily. This reason often trumps the need to collect user information, and the discussion stops there.
However, my response has been to ask when the last survey was sent and to whom it was sent. Many companies keep a customer outreach plan that includes the survey schedule and other customer touchpoints. Usually, after some discussion, it becomes clear that either the exact schedule isn’t known or that the last survey was sent months ago. Therefore, it may not be the case that you’re sending too many surveys.
If, in fact, users have been flooded with surveys, look for ways to minimize their potential annoyance. For example, narrow down the recipients list to the minimum number and type of users whose input you really need. You can also pare down the questionnaire to the absolute basic questions you must ask to learn what you need.
Finally, consider tapping into existing customer advisory boards (CABs) instead of sending them to a broad group. CABs consist of key customers who have agreed to provide feedback on products and the company. They are usually willing to be contacted frequently to provide feedback that will guide product development. If a CAB doesn’t exist, then consider reaching out to some “outspoken customers” who speak candidly and are often early adopters of new features.
“There’s not enough time in the development schedule for a survey.”
A quick-and-dirty survey is meant to be quick to write, answer, and analyze.
Once you know exactly what you want to learn, it should not take long to write the questions. For example, in my introduction I mentioned the need to know the size of tablet devices that my targeted customers use. Learning this information may take as few as two simple multiple choice questions, such as:
- Which of the following mobile device(s) do you own?
- If you own a mobile device, what type do you own?
Underneath both questions, insert a list of options. Include a text box for “Other”. In the list for Question #1, include “None.”
Some survey tools offer a question builder within the application, which can save you some time. Basically, it’s a library of pre-written questions that you can use as-is or customize to fit your goals. A question builder feature can speed up the process of actually writing the questions.
For situations where you need text translated into other languages (such as instructions and survey messages) to reach more of your audience, many survey tools offer multiple language translations.
This doesn’t have to take a lot of time. In the past, I’ve written quick-and-dirty surveys, sent them, and analyzed the results all in one day. Obviously, it’s better to give respondents an ample amount of time to answer the survey questions. But in a pinch, you can do it quickly and still yield useful data for the product development team.
“Our customers tell us they hate surveys.”
To this objection, I respond with: Don’t write bad surveys.
Two of the most common traps for product owners are including too many questions and using leading questions. These two things combined are usually the reason why customers dislike answering surveys.
Sending a survey is not an excuse to throw in a few “other” questions about something indirectly related. It’s tempting to maximize this opportunity by getting customer feedback on something else you have in mind. However, avoid the temptation to add questions because the longer the survey, the higher the risk is of users abandoning the survey.
Secondly, do not create leading questions that nudge a respondent to answer in a certain way. For example, asking, “Wouldn’t you agree that the new design is easier to use?” leads the user to answer, “Yes.” Instead, use neutral language when crafting questions.
If writing surveys isn’t in your wheelhouse, check out some of the many free online sources about good survey design. Also, many of the survey tools available will provide guidance about good design. Check out Capterra’s list of survey software to find a tool that offers assistance with design.
Using quick-and-dirty surveys to gather customer information is a low-cost and relatively quick way to learn more about users. Don’t let faulty assumptions or misinformed reasons keep you from reaching out to customers during the development process.