Through Your User's Eyes

It’s plain and simple. Your users don’t see the product like you do. They have a problem that needs to be solved, and all you have is one possible solution. How that solution is presented to them and functions is almost more important than the problem it solves.

You have to ask yourself questions like:

  • Is it easy to use? If not, do you have sufficient tutorials and/or documentation in place to support them?

  • Is it fast and snappy? If not, how can you keep the user engaged while something loads/processes?

Do you understand the technical capabilities of your users? Can they “figure things out” if it doesn’t work perfectly? Apple has this nailed better than anyone else (and they have the valuation to prove it). They understand that the vast majority of users just want it to work. They don’t want to spend time tinkering with settings and getting it just the way they like it. They just want it to work. Sure, you could argue that people are now just used to the way Apple products are configured, but how do you think they got the majority share in the first place? They hired some of the most talented product and engineering people in the world to figure out how to build a simple and intuitive user interface.

What about your own users? B2C software is tough. Consumers are notoriously picky and will quickly move to the next thing if it doesn’t work right. If you are building B2B SaaS, it can be a bit easier, as business people are a bit more forgiving (mostly). At the very least, you usually have a sales, customer success, or support person that can help smooth over the rough edges and buy you time to fix it. These are just two of many markets, but I think one of the best case scenarios is if you are building a tool for developers. They are more understanding when something is broken, and honestly might even help you fix it.

Just avoid building anything for test engineers. They find all the problems, even the ones you said weren’t possible.

— Me (a former software test engineer)

Seeing things the way a user sees them is one of the hardest things to do as an engineer, especially early on in your career. You are often more excited about doing cool things with code or getting lost on a new technical challenge, than building a product. Couple that with a lack of experience building at scale, and you will have quality problems. But that’s a post for another day. You have to pull your head out of the code and forget about “how hard that will be to build”. Though I would also argue that if it is hard to build, it might actually be hard to use. Often, intuitive designs are intuitive to build. If something feels clunky or weird, that’s probably because it is.

Truly understanding how your users will use your product to solve their problem is extremely important, but if it is hard to use or understand, it doesn’t really matter how well it solves the problem. There are numerous frameworks out there to tackle/track these issues: Jobs to be Done, Definition of Done, Spotlight, Net Promoter Score (NPS), ACAF Feedback Loop, etc. That’s just from memory and the first page of Google for “customer feedback framework”. Honestly, ChatGPT could probably come up with an even better answer. But the most important part of any framework is actually talking to your customers and listening to the problem(s) they need solved.