Ever been in a situation where it’s not clear why you’re implementing a feature in a particular way? What about a time where you question why you’re building the product that you are and not something different?
Many developers and designers have been in these, or similar, situations. It’s a frustrating place to be in and often comes up after being days or weeks “in the weeds” of a particular problem. Coupled with this feeling can be a sense that the product manager is coming up with feature requests without thinking through implications or asking too much of the team. When an alternate implementation or approach is suggested, it gets shot down, sometimes without a clearly articulated reason.
A sure-fire way to get back on track is to sit in on conversations with customers. Be it sales meetings, customer interviews, talking to churned customers, usability testing, or sitting alongside the support team for the afternoon, shift focus to doing one thing: empathizing with the customer.
The software you’re designing or developing might be used by ten people, or ten thousand. Regardless of the number of customers, their needs come first. Without understanding the problems they’re looking to you to help solve, work can seem tedious or unnecessary.
By hearing first-hand how customers feel about your product, what compels them to use your product, and even why they stopped using your product, you’ll have more of a personal stake because those experiences will stand out. With this context, what seemed like a tedious solution might make total sense!
It might seem like your recommendations to simplify approaches go unheard. This isn’t to say that your suggestions are wrong, per se, but they might not appropriately solve a customer’s problem. With additional context around the problem the customer is trying to solve, your recommendations become more appropriate because they address immediate needs.
By spending time throughout the design and development process understanding customers’ needs and empathizing, you’ll become a more effective developer, engaged teammate, and meaningful contributor to the product you’re building. On top of that, its likely that features will be more clear, alternative approaches will be more appropriate, and requests that once seemed questionable will begin to make sense.