Launching a new software product? Great! First 100 users registered? Way to go, mate! 🥳 Now it would be great time to introduce some new features. But hmm, what should we actually do next? Well, it should all boil down to user feedback and fast feedback loops. So let's get to it!

Collecting the feedback

There is many ways to collect feedback either by automation or by manual labor. For clarity, I have split techniques to different levels which makes it easier to see where you are now and what could be the next step.

Level 0: No feedback

It all starts in point where you know nothing or very little about what the users want from your product. Making product development decisions at this level is based only on hunch. You might have some ideas from your team if they are using the product themselves but that may not reflect the other users of the product. Here, eating your own dog food is good practice but might not reflect the real-world issues with the product.

As everything is unknown and scary 👻, the best course of action is to setup something to get feedback from the users. To which level you want to jump next is up to you — in this game skipping levels is even encouraged.

Effort: None Value: None Maintainability: Very easy Feedback loop: None

Level 1: Automatic collection

This level presents the state where you have some automatic way to collect feedback from the users. This can be for example measuring the time they spend in different parts of the service or how they navigate in the product. It can also relate to the performance of your system or some business metrics. While this can be important information, it still might not provide enough to make good product development decisions.

There are many tools for automatic feedback collection. What you want and can use it's up to your technology stack and infrastructure. Try and experiment with different tools to find what brings you the best value.

Effort: Low to medium Value: Low to medium Maintainability: Easy to medium Feedback loop: Very short

Level 2: Surveys, forums, social media and other support channels

This might be the easiest and cheapest way to setup a feedback loop. Creating and sending surveys to users, creating a product forum or asking feedback on social media is very easy to do. Engaging many users this way is easy but might backfire on the quality of the feedback; beware of the trolls! 🦫 Another problem with this way of collecting feedback is that it's taken out of the product context which takes us to the next level…

Effort: Small Value: Small to medium Maintainability: Easy Feedback loop: Medium

Level 3: Feedback loop embedded in the product

You might know some good examples of this level, like reviewing apps on Google Play or Apple store. If your product is a mobile app, you already have completed this level and get feedback from the users out-of-the-box provided by these services. If your product is instead something different, let's say a web service, you need to do some work. Embedding way for users to give feedback while they are using your product is very efficient. This way, the context of the user at the time is right and the feedback is real time.

Simplest way to do this is to show user a form with possibility to score the product (or part of the product) and also give some free-text feedback. You may even collect some technical data at the same time for example screenshots. In my experience, this is very good way to improve the product and usually doesn't cost much.

Effort: Medium Value: Medium to high Maintainability: Medium Feedback loop: Medium

Level 4: Interviewing the user

The best way to gather feedback is to actually see the user use the product. You can do it several ways and in several points of development for example as part of usability testing. On the downside, it's also the most labor heavy way to collect feedback and thus hard to do continuously.

The most important thing is to prepare and ask the right questions; Why is the user doing something? What is hard? Is there anything missing? Good idea is to have at least two team members to do the interview with the user so that other one can do the talking while other takes notes.

Effort: Very high Value: High Maintainability: Hard Feedback loop: Short

Level 5: Mixing it all together

For the best results you should mix all kinds of feedback loops. Unfortunately many feedback sources comes with high maintenance cost as you have to process much more data. Be aware of this and select your channels carefully. In bigger organizations there can be some centralized tools for the feedback collection so keep an eye out for those to save some effort.

Effort: Very high Value: Very high Maintainability: Very hard Feedback loop: Short to long

Great, now I have some feedback. What's next?

First, you should make sure that all people working with the product can access the data. By this you ensure that everyone can see how the users are behaving and what they are requesting. It allows people in different positions to prepare for their part of possible new solutions to the product. Optimally all data from different sources is found from a single location for cross-referencing.

Good practice is to go through the feedback together periodically. For example, in my team we are doing that on a monthly basis (got to say, we should do it more often). Picking the best ideas and improvement actions should always be joint effort with all team members.

The selection of best ideas should be done based on the amount of work needed compared to the user value it brings. Especially keep an eye out for feedback that is repeated by different users. Once you have the ideas, then it's up to your team to plan when the best ones will be implemented.

I am a developer. How does this concern me?

As a developer you are responsible of delivering quality software for the users. To do that, you have to understand the users and how they use your software in depth. Feedback loops are the only way for you to get exposed to this.

As a member of DevOps team, it's your responsibility to understand the user behaviour and effects to your operations like infrastructure and costs. Equally important is to understand the consequences of you changing something in the product. Making your deliveries and feedback meet in your reporting can help you determine if specific change was good or not.

About me

I am Heikki Hellgren, Lead Developer and technology enthusiast working at OP Financial Group. My interests are in software construction, tools, automatic testing and continuous improvement. You can follow me on Medium and Twitter and check out my website for more information.