5 ways to use customer feedback to drive your product development

Startup life can get pretty intense. Most of the time teams work in a zoomed-in mode, and it’s very easy to lose perspective and disconnect from the people you are actually building for. When real pains are replaced with your assumptions, product development can go astray. If you feel like you don’t know who’s on the other side of the screen anymore, schedule in a couple of days to talk to your users. Below I will share 5 ways in which user feedback helped us stay on track at different stages of building a startup.

In-person user testing of your first MVP

As soon as you finish building your first working prototype, get it into the hands of your first users. You should strive to validate your assumptions as early into the process as possible. Depending on what you’re building you might either want to watch them interact with your prototype and ask them questions about it as you go, or just have them test it and give you feedback afterwards.

In our case, as soon as we built the first version of Nikabot (which is a Slackbot that tracks teams’ time), we launched it internally in our Slack team (around 60 people). All our first users were already familiar with the way Nikabot was supposed to work, so we just let them test it and give us their feedback in whatever the form they preferred. After only an hour of testing we began to detect a consistent pattern in the user feedback in regards to Nikabot’s core functionality. We iterated on the core dialogue of our app, and then took another 2 weeks to work out the details.

The extent to which you incorporate that feedback into the product strategy depends on many factors — who you choose as your first testers, how deeply your problem space is studied, how well the problem is articulated, how “innovative” your idea is, etc. In our case we were solving quite a familiar problem — employee aversion to time sheets, and our focus was clear — the solution had to be simple. Testing it within our own team made the feedback highly relevant, so we relied on it heavily while iterating on our first MVP.

Long unstructured conversations to dive deeper into the problem space

In the beginning it is very important not to be afraid to have long “unscalable” conversations with your first users to understand their perception of your product but also the problem space. At that point you still don’t know exactly what you’re looking for, so you can find clues anywhere.

We reached out to a handful of companies in our hometown, Lisbon (the one in Portugal) and asked them to test Nikabot in their Slack teams for some time. After 3 weeks we invited their team managers for a chat over lunch.

At that time our conversations were still more about the problem space and less about our solution. We asked how they organized work in their teams, whether they found themselves working on big chunks of work for days or kept jumping from task to task throughout the day, whether they were all in the same location or had remote employees as well, etc. Those conversations were incredibly useful and gave us first clues as for who our perfect customer was and wasn’t.

Surveys as a method to hand-pick beta-testers

Surveys are a good, scalable method of crowdsourcing user opinions and feedback. The only problem with surveys is that it’s not easy to get people to fill them out. A good way to go around it is to design surveys in a way that brings (preferably immediate) value to a user.

For example, after testing Nikabot with the first couple of companies that we knew personally, we were eager to run the bot in more teams and hear their opinion. At the same time we were worried that if we opened our app to everyone too soon, we would scare away prospective customers since at that time Nikabot’s functionality was still quite limited.

To solve that we invited people to ‘Join the waitlist’ on Nikabot’s website, and once they joined, we offered them a chance “to beat the queue” and get the app sooner by replying to our survey. We would then send them a 6-question survey that we designed to hand pick teams whose composition, size and requirements fitted Nikabot’s early-stage functionality. Whenever we got a new reply, we would analyse the team’s profile, and if it was a good fit, we would reach out to them and add Nikabot to their team manually.

In that way the survey had equal value for both sides: we could literally find beta testers that fit our early-stage app, and users felt they had a privilege of accessing the app before others.

Regular check in calls with users

Every 4 months or so we run rounds of Skype chats with our users. Those chats help us understand how the profiles of the teams, their needs and requirements change over time.

We made the first round of calls like that a couple of months after our public launch. When we launched Nikabot publicly thousands of users flowed in. Some would drop out the next day, some would linger for longer, some used it at work, others at their side-projects. A couple of months after a public launch we felt that we were getting out of touch with our users. We didn’t know why teams were using the bot, how they discovered it, and what value it provided to them.

So we wrote emails to a dozen of teams that were using Nikabot at that time, inviting them for a 15-min chat with us.

Compared to our initial “lunch conversations”, those chats were more structured because we already had a feel of what we were looking for. We used a simple template to guide our conversations, which you can take and adjust to your case as well:

• What type of the team are you?
• What do you use (our solution) for?
• What’s the best thing about (our solution)?
• What’s the worst thing about (our solution)?
• How did you find out about us?

When we did this kind of a check in for the first time, it really helped us pinpoint Nikabot’s core value, our users’ main pains and needs. At later stages those chats have been helping us to keep a healthy perspective on our product and prioritise new features.

Live support

Live support is incredibly helpful for capturing user complaints and feature requests before they turn into burning issues. When something breaks users go out of their way to find your support email and complain, but when they have just a small issue or a feature request they are less likely to reach out. By providing them with an easy communication channel you get to capture more subtle opinions and suggestions about your product.

To wrap up: talk to your customers as much as possible. Talk not only to those who use your product, but also to those who tried it but didn’t sign up, those who churned, those who use competitor products. This is very important, especially in the beginning of your path. The more perspectives you have, the more holistic view you will have on your product. This will not only help you determine your product’s evolution and tell nice-to-have features from the must-have ones, but also drive your marketing, messaging and communication efforts at later stages.

This story is published in The Startup, Medium’s largest entrepreneurship publication followed by 306,792+ people.

Subscribe to receive our top stories here.