“How satisfied are you with our product?”, asks a tiny popup on your screen. It is a survey to find out if the customer is satisfied with the product or not. You’d think, that is probably the easiest part of someone’s job. I used to think that too. Until one day, I found myself in a lengthy discussion with a Product Designer and a UX (User Experience) Researcher talking about the right questions for a survey.

I was always interested in doing User Research. Although, I don’t have any formal training in User Research, I acquired the knowledge from online courses, Youtube videos and conversations with UX researchers.

However, this particular instance stuck out for me, because like everyone else, I thought, I could do this in 30 minutes; it’s easy. Well, it was easy but not without the collaboration of my colleagues.

Let’s unpack the story.

I wanted to run a survey for our customers with an objective to understand their satisfaction level. While we had indicators on customer’s satisfaction, we did not have a quantitative measure in place.

Before approaching my colleagues, I drafted the questions for the survey, believing it to be my best work. I sent it to my colleagues, a Product Designer and a UX Researcher. They came back with feedback that I was not ready for. Of course, my colleagues had provided the feedback in a highly constructive manner. But honestly, my first draft sucked.

I knew this was the time to collaborate.

We created a Slack channel between the three and jumped into brainstorming session. Later, we setup a meeting to ideate further.

We asked multiple questions in our discussion:

• Why are we running the survey? And why now?
• What do we hope to achieve from the survey?
• What type of survey should it be? Binary input? 5-point scale? 10-point scale?
• How many questions should we ask?
• Should there be an action for the user at the end of the survey?
• How long should we run the survey for?
• What if no one responds? What if too many people respond (we are dreamy, that way)?
• What is the target response rate?
• What do we expect to impact after the survey ends?

Each of those questions had detailed discussion on separate tangents. In the interest of not lengthening this blog any further, I will not delve deep into the answers.

In our discussion, I provided the hypothesis, the goal and the expectations for the survey. This was the most crucial part before we went to the questions. We refined our approach based on the hypothesis. We realised a single question will not suffice for our goal and customised it to our context.

At the end of the survey, we had added a booking link for a meeting, just in case customers were interested in talking to us (it totally worked, by the way 🚀).

Based on the past surveys, we understood that very few people actually respond to our in-app surveys. It was still the best option available for us to start. We used Hotjar tool for survey. We ran the survey inside the app for 4 weeks.

During this time, I kept my team constantly engaged. I connected Hotjar and Slack to receive notification for every single response. Each day, I would login to Slack and check if we received any responses. Our mood of the day was dictated by the recent survey response. 🙂

After 2 weeks, I initiated the evaluation of the responses. Thanks to my colleague who spent time analysing and visualising the responses. He created a document and we shared with our team.

After 4 weeks, we re-evaluated our survey and changed questions based on our prior performance.

Fun fact: Compared to our past surveys in the company, this survey received highest number of responses. 🔥

As a Product Manager, my role was to take ownership and drive the team. I relied on the expertise of the team for most things. The UX researcher directed the correct approach for this survey. The Designer helped in creating the survey and presenting the results.

I initiated the ideation phase, followed up on their work, prepared my proposal drafts with goal and hypothesis for ideation, kept the team engaged when survey was live, iterated on the survey questions and published the results to the teams.

A Product Manager learns to leverage the cross-functional team’s strengths. Taking full ownership of the work is what you bring to the table daily.

I have summarised this in the most practical way:

1. Choose a tool. If you don’t have it then explore the tool.
2. Draft a proposal document with the objective (why do you need this survey).
3. Create your first version of survey questions. Don’t worry about polishing the content. Just write.
4. Share this with your Designer/UX researcher and request a discussion. You can do this async or sync, it doesn’t matter. Now, if you don’t have those people in your team, you may have to go to someone who wears those hats.
5. You can revise the questions. Simultaneously, refine the document; keep it updated.
6. Create a plan with your team by using the above questions.
7. Once it is ready, create the survey and run it.
8. When the survey is active, analyse responses and constantly seek feedback from colleagues on the performance of the survey.
9. Present the results to the team and include what customers are telling you about the product. Share the good, the bad and the ugly.
10. Identify and document the changes required for next iteration.

---

Check out the Designer and the UX researcher mentioned above. I am grateful to them.