Why Engineering Teams Care About User Feedback

It seems like if you read anything about product development, you hear a lot about reducing the space between product owners and their users. This makes perfect sense, right, how can a product owner decide what to build next if they aren’t close to the user? Some other sites (the ones that I prefer, unsurprisingly) talk about reducing the space between makers and users. Makers that are close to their users can also help make informed decisions about what to build next and how.

To me, all of this seems like common sense. Unfortunately - in more traditional organizations (or ones that are in the middle of transition) it seems like I experience a lot of resistance to making sure engineers also have access to user feedback. I’ve heard many reasons behind this resistance (engineers don’t present the best view of the company to the user, engineers don’t care about the users - they just want to write code, etc) but having access to user (and stakeholder) feedback has a large impact on the success of an engineering team - and thus success of the product.

Engineering decision making

Understanding user feedback has a huge impact on decisions the engineering organization makes about their codebase. As an engineer, I find myself spending a lot of time trying to balance building new features in a way that makes sense with making sure our codebase is organized and doesn’t cause too much developer pain. Understanding both user and stakeholder feedback helps engineers make decisions about their work. It also helps engineers stay in sync with changes that might be happening with the product - the more transparency, and the more changes we can begin to predict, the better prepared your engineering team will be for future feature development.

Recently, I was in a situation where my team had decided to reorganize our component library. We had decided, that since we had a lot of “card” components that were very similar, we would consolidate them into a set of fewer components. Work had begun on this as part of a user story that was already in flight. In another planning meeting, I found out that there was feedback (whether from stakeholders or users) that the design was too generic, and that there would be a push to move to more variety in components/design. If the engineering team had been aware of that feedback, I’m pretty confident in saying that we would not have begun work on consolidating components - and it would have informed decisions we were planning to make on the future of our component library.

Fortunately, we had not marched too far down the path of consolidation, and now that we know we need to be more prepared for variety and flexibility in our components, we can move forward with other decisions we were struggling to make about how to structure our code in a way that supports upcoming work, and can deliver much more quickly than if we had been caught completely unaware weeks from now when the new design work was delivered to us.

Product decision making

Engineering should be a key player in product-level decision making. Engineers tend to have a unique view on work that can be done to enhance the user experience. If engineers are aware of user feedback, we can be leveraged to help ideate and build a solution that both answers the user’s feedback and gets the feature into the hands of users as fast as possible.

I have experienced a lot of pushback in my time from various parts of businesses about having engineering involved in product-level decisions. We may argue for decreased scope, or arguing to solve a problem in a different way. We don’t do this because we don’t want to work or because we want to be difficult. We do this because we have a deep understanding of how the code works under the hood, and an understanding of how much work it might take to deliver certain features. If the idea is to make users happy, sometimes alternate routes can be taken, especially if we understand why a feature was suggested. If I understand the user feedback and why this feature was suggested, I may be less resistant to a feature that is much larger in scope than another solution I may have come up with that takes less time to develop.

Engineering teams understanding why features exist helps teams build the right things and in a way that makes sense. It helps us see the whole problem, and what this feature is trying to accomplish. It helps us avoid certain edge cases, ask the right questions of the various disciplines within the team, and ultimately allows us to deliver more quickly.

Happy, healthy teams build better products

For me, healthy teams understand why features and deadlines come about. They are part of the decision making process, and they get to see users actually using the things they spent so much time building. They work on a team that includes all disciplines to arrive at decisions, rather than declaring one discipline or another doesn’t want to be involved at all levels of the process. Healthy teams feel ownership over their product and their process.

For me, part of feeling ownership means that I understand the user feedback. I understand why certain things happen to me and my team. I understand why and how we’re moving forward as an organization with certain feature sets. I also understand why deadlines have appeared, and what we are hoping to accomplish with each iteration of our product.

Happy, healthy teams deliver better products - and we can only get there if every discipline is included in understanding user and stakeholder feedback.