Understanding users is actually difficult

One of the things I’ve learned after working with a few startups now is that the advice “talk to your users” is not just extremely important, but way easier said than done. Even if you talk to your users, it’s difficult to predict what people will actually do, especially if your product is complex. You have to get really good at getting people to talk through how they do things and describe problems, rather than telling you the solution (let them do that too, but you probably won’t use their suggested solutions). If you don’t actively observe your users or ask them how they do things, you may never get feedback on how things are going.

We found that after we talked to our users, we were astounded by how much inefficiency they dealt with using the software to do their day-to-day jobs without complaining. It was surprising how our users just wouldn’t say anything even if they’re spending insane amounts of time doing something inefficiently or repeatedly.

Once you’ve committed to having engineering time focus on one of the aforementioned problems, you also have to follow up with your solution and see if it actually helped them. It’s easy when you’re a small startup with so many things to do to simply ship something and forget about it, thinking it’s solved your users’ problems, only to realize that it didn’t move the needle on what you expected it to. Sometimes, the solution was good enough at a certain scale, and then something changes in your business (i.e. you grow a lot) and then that solution is super inefficient again (assuming it was ever a good solution in the first place).

Building products is hard - you can write a lot of code and build a lot of features, only to realize your users aren’t using them how you expected at all, even if your users are on your own team. Sometimes they don’t even use the features, period. It’s cool to see how much progress a small team can make, but building a bunch of features that don’t get used isn’t progress - it becomes a liability.

Building products requires encouraging feedback from users, actively listening to them describe what their goals are and how they use your product to accomplish their goals, and actively working on tuning the software experience to encourage the intended usage of your tools.

You’ll find blog post after blog post talking about this same stuff, and there’s a ton of videos on how you should “run product”. At the end of the day, you may find you’ll still make most of the mistakes everyone talks about, and that it’s genuinely harder than it looks. It’s a muscle you have to put deliberate effort into building.