Wait, why are they doing that?
The best product insights often come from how people use your product in ways you never intended.
One of my users recently asked me a question that was unexpected because usually I am the one asking questions during our “interviews”. Something like:
“What does success mean for you when it comes to the features you launch?”
I didn’t even need a second to think.
For me, one of the best feelings in product work is when I see someone use something I’ve built in a way I never intended, on top of the use cases I had thought about.
When I see a workaround that makes me think, “Wait, why are they doing that?”, it’s a different kind of satisfaction. I feel like a musician whose work is getting remixed.
You might think this means I hadn’t understood the problem deeply enough in the beginning. That’s not completely incorrect. But there’s more to it.
Before getting it right, get it used
First of all, I am happy they are using it in some way, even if it’s not the way I was focused on. You’d be surprised how many people design things people never asked for and have zero interest in figuring out if they actually want them.
Over time, I learned to lower my expectations around that. It’s never about matching what people will use 100% in advance. Now it’s more about being quick in launching so that I can get there as soon as possible.
One of the hardest things in product is figuring out what people actually want.
They can tell you what frustrates them. They can tell you what they’re trying to accomplish. They can ask for specific features.
But the best way to discover is when they show you. My favorite way to make that happen is:
You set the stage for it with some kind of minimum viable product, potentially far from perfect.
You become extremely good at reading between the lines when your users tell you about their experience.
Why you need an MVP to start
Isn’t after release too late to get feedback? Not always.
You can think about new features and redesign your product all day, making tons of assumptions. They will never be 100% accurate. It’s always a gamble.
The more time you spend thinking about how to be correct, the more you’re stealing from the time you could actually be learning from your users.
Launch what you have in mind with minimal effort and see if anyone cares. That’s it. If not, go back to the beginning. But if they use it in an unexpected way, or if they are using it even though the experience seems quite inconvenient for them, keep going. That’s the point where you start learning from them directly and iterating your product accordingly.
In one of my previous articles, I mentioned how Twitter Threads were born exactly like that.
Early on, Twitter had a strict character limit (140) and was built around short messages. But users didn’t always want to stay short. Around 2014, some users started posting sequences of replies to themselves to write longer thoughts in “tweetstorms.” Marc Andreessen was one of the earliest to popularize this format.
It began as a hack. People manually chained tweets together because the product did not support long-form content. As “tweetstorms” became normal, Twitter recognized the behavior and formalized it in 2017 as Threads.
If you're learning to swim, you can study swimming techniques, watch videos, and understand exactly how your arms and legs should move. But at some point, you need to get in the water. Only then might you discover that your breathing is actually the thing you need to improve.
Why listening to what your users want isn’t enough
In very simple words, because they don’t know.
And I don’t mean that in a “users don’t know anything” way. I mean it quite literally we, as humans, are not particularly good at predicting our own behavior.
What we want to want and what we actually choose are not always the same thing.
This is something I wrote about before in “Would you use this?”. Asking someone whether they would use a feature gives them nothing real to react to. Saying yes is free. There’s no effort, tradeoff, or commitment involved.
What people have actually done when faced with the problem is a much stronger clue than what they imagine they might do in the future.
And over time, you should naturally become better at reading between the lines.
Because often, the most useful part of a user conversation is the small detail they mention in passing while answering your question.
“Then I upload everything to Claude...”
Wait. Why?
“I just copy this from the previous version...”
Why is that easier than creating it again?
Those little comments are easy to ignore because the user isn’t presenting them as the main problems. To them, they’re just part of how things work. They are a given.
Then they create workarounds. They develop habits around limitations. Eventually, they stop thinking of them as problems worth mentioning.
The product job is to notice them.
Pay attention to the workaround they created. The extra steps they’ve accepted as normal but actually shouldn’t need. The feature they’re using for something it was never designed to do.
Don’t build the “workaround”
There is another easy trap to fall into that I see a lot of people still keep falling into.
Once users recognize the friction, they will often give you the solution too.
“Can you just add this into the product?”
“Can you automate these extra manual steps for me?”
“Can you automate this so I don’t have to do it manually?”
These can actually be things you should do, but sometimes you’re just turning their workaround into an official feature.
The fact that someone has found a way around a problem doesn’t mean you should make that workaround faster. And the fact that a user asks for a feature doesn’t mean that feature is the right solution.
Take the workaround as a clue. What you really want to understand is what they are ultimately trying to achieve by doing it.
Maybe they don’t need those five steps automated. Maybe those five steps shouldn’t exist at all.
Once you understand the outcome they’re trying to reach, you can forget their proposed solution for a moment and rethink the problem from scratch. There might be a much simpler way to get them there.
Imagine customers at a restaurant constantly asking for bigger tables. You could replace all the tables. But when you watch them, you realize the problem is that menus, water bottles, plates, condiments, and serving dishes are taking up half the space.
Bigger tables would indeed solve the problem. But what they actually need is more usable space while eating. There might be much easier ways to give them that before replacing every table in the restaurant.
When someone uses your product in a way you didn’t intend, the instinct can be to think they’re using it wrong.
Get curious instead. Why are they doing that? What does this let them do that the current product doesn’t?
Your users may not always be able to tell you what they want, but they’re constantly showing you.