Solving microproblems with user feedback

Your users can help shape your product, if only you’ll listen to them

m-tron
Bootcamp
5 min readJun 1, 2022

--

The success of a product hinges on its ability to solve a given problem (or a cluster of problems) in a given niche. In general, these problems and their proposed solutions are then fleshed out through user stories and validated with target market research. A minimum viable product is developed, starting with a basic prototype and iterated upon in development cycles.

There’s more to it, of course, but this time-proven process forms the core of initial strategy for startups and products.

A causal diagram of product design, business, and production
Just something I found on the net. Looks cool, though

But what about when the product has started to make a name for itself, is seeing growth in its userbase, and is starting to branch out in terms of features? How can it make sure that newer features align with what users actually want?

At a certain point, the problem(s) that the product has set out to solve is/are best broken down into a set of smaller problems. Let’s call this breaking macroproblems down into microproblems. We can sort microproblems according to category: some will be best addressed with improvements to customer service, some concern the user interface, knowledge resources, onboarding, etc.

What they all have in common, regardless of their category, is that users can identify microproblems much better than product owners or UI/UX designers. They may not be able to articulate microproblems with the same degree of fluency as technologists, but users are more liable to encounter them in daily use.

If your product has launched and has an active userbase, it’s already met with some success in solving the macroproblem(s) faced by its target audience. But its ongoing performance will depend on its ability to solve the microproblems that characterise how users actually interact with it.

When users put time into working with a product, especially an immature one, they want to have some indication of how the product is going to improve and evolve over time. Will the UI become more refined? What features will be added? Will it integrate with apps and services they already use? These, from a user point of view, all constitute microproblems. They want to know if they’ll be solved, how they’ll be solved, and when they’ll be solved.

An excellent way to show users that your product is going to evolve in line with their needs is to put the effort into providing a streamlined and effective user feedback system. This shows that you’re listening to them.

Without this, users will simply leave without saying why.

If part of the reason you’ve stopped using a product is that you’ve felt your feedback to be undervalued, you’re hardly likely to pass this on when you’ve finally given up and moved to something else. You don’t utter an angry tirade about why you’re leaving and slam the door on your way out — you just stop signing into the app, or quietly unsubscribe from the weekly newsletter.

By the time things have reached this stage, it’s very hard to reach out to a user to find out what went wrong. The whole sum of that user’s experience with the product becomes inaccessible, and can’t be fed back into further improvement of the product.

Consider the following inner monologue that’s run through my head many times as a user.

“This is a cool app! I love how feature X works, it’s much better implemented in similar apps I’ve tried. But how can I access feature Y? Wait, does this app even have feature Y?

“I’ll check the FAQ or knowledge base. Hmm, no mention there. I’ll send a support email — automated response, they’re receiving a high volume of enquiries at the moment. Meh. I want something that can solve my problem today, not tomorrow.

“Is there a way I can lodge feedback? I can’t see it on their website. Is there a feature roadmap? How do they communicate with their users? Do their other users want feature Y, or is it just me? No way to know… maybe it’s not on their roadmap at all.

“I don’t think this is the app for me. I’ll look around for something else with both features X and Y, preferably more responsive to user input.”

And so you’ve lost another user, and worse, you have no idea why. All that crucial information will be lost in time, like tears in rain.

Roy Batty from Blade Runner (1982)
If only they’d taken my user feedback more seriously…

This is why it’s crucial for the product owner to be closely attuned to the needs and wants of users. Feedback can come through many channels: UX research, A/B testing, CX interactions and support tickets, and other useful inputs such as blog posts and reviews, comments on sites like Product Hunt, and feature comparisons with similar products.

User feedback has limited utility when it comes to solving macroproblems. After all, these are the big questions, the raisons d’être of products, and they form part of the business strategy and product design decisions in a startup or company.

But that same user feedback is invaluable when it comes to solving microproblems. And it’s hugely underleveraged just about everywhere you look.

It all boils down to listening attentively, taking feedback seriously, and demonstrating to your users that you’re doing both. Even that is the bare minimum — if you really want your product to stand out, you have to make it easy for users to speak to you. You have to make feedback frictionless. You have to make it clear that their input is valued. You have to make users feel involved in the ongoing development of your product.

I’ll continue exploring this topic in further detail, using examples of what to do and what not to do that I’ve noted down from my own experiences as a user. Please like, share and follow if you gained something useful from this article. And of course, I have to practise what I preach — feedback welcome!

--

--