Survey was part of our life, but I was not aware of its importance till I read the book "Hacking Growth" and learnt about AARRR model. The book suggests that survey will not only help us to understand what our product should improve, but may also promote the product as a "side effect".
In comparison to user experimentation(that I mentioned in "Gain and retain users for your project with user experimentation"), user survey could get more people involved, more sets of data, yet not certainly helpful information.
One of my first few trials was surveying both our front-end developers and the backend developers about the backend API integration experiences. Our team was facing the pain of working with multiple backend teams reporting to different managers and not applying the same practices.
The survey aimed to:
- collecting the data and expectations of API integration from both sides;
- providing actionable and convincible suggestions based on data;
- finding out the common patterns and providing tools base on them;
- advertise some existing practices and benefits of adopting them.
With above goals in mind, I carefully designed the questions and options, distributed with the helps from each sub-team PICs. As a result, I gain over 70% response rates from FEs, and responses from all the BE teams we were working with.
The data I collected and summarized helped me to clarify the situation, and helped others to make some technical decisions(like what kind of API schema should internal tools relates to API integration adopt). However, the result of "side effect" was not obvious in a short term, as it was designed to be conducted periodically to reflect the situation.
The other interesting survey I tried was altering a regular feedback form for a team sharing activity. I found the feedback collected from that form was not helpful in improving my sharing or the project I shared. Therefore, I carefully chose questions to keep the form short, provided options to reduce effort on answering open questions, and altered words to make audience think of more helpful information. Yet I was still too greedy and asked too much. And I only got less answers. The trial was a failure.
Then I further simplified the form, and saved some engagement.🙈
Here is the lesson I have learnt along my try-error journey.
When designing a survey:
- Be clear about the goal of the survey, so you won't ask unhelpful questions;
- Target to single group of people, and only ask related questions;
- Keep the survey as short as possible, so you may get more answers.
- Choose words carefully so you could get more helpful information. One example here is changing question like "What do you think xxx need to improve?" to "What made you want to leave xxx?".
- Less open questions, more selections, and the questions become easier to answer.
When conducting a survey:
- Choose the way to request answers. You may expect only few answers if you request for answers by volunteer, though the message could be received by more people. Or you may get more answers if you request each survey target.
- Set deadline and keep sending reminders. People may miss your message or simply forgot the survey.
- Analyze result and summarize to simple conclusions for an easier understanding.
- Share and discuss the results with the related parties, plan for actionable.
- Follow up the actionable regularly to ensure your effort is not wasted.
Top comments (0)