It happened again, you asked for a feature, the developers built it but it’s not really what you wanted. You’re now expecting a cycle of endless revisions. This pattern has become part of how you work, and as a result nothing is getting done on time. You can’t be available all the time to answer developers’ questions as they work, but there’s one simple thing you can do to help them make better decisions on their own.
Early on in my career, I was asked to implement a feature that would allow our customers to configure relationships between different components in their system, imagine a network configuration with nodes and edges connecting them.
I thought deeply about what a good implementation might look like. I drew diagrams, wireframes, imagining all the possibilities. I knew it was going to be a lot of work to implement any of the designs I came up with, but I was confident that almost any implementation was going to be a huge step up over similar features we have. Luckily, I checked in with my boss before I started coding. He had different ideas.
I had never seen a real customer in my life, in fact the engineers were kept away from customers on purpose. This is how the company operated and nobody questioned it. So, when I designed my feature, I thought about how I would use it, how I would test it. For me, that meant spending a few minutes entering data and using the feature, configuring a handful of components. What I learnt from my boss was that our customers enter hundreds and thousands of data point, an ugly but functional spreadsheet-like implementation was a far better choice. Oops, my ‘pretty’ design just became a tangled mess. My boss knew what a good implementation was, he actually talked to customers.
The lesson I learned from this is to always question and verify my assumptions and check in with my boss before diving too deep. The more important management lesson, which wasn’t obvious to me at the time, was about the value of connecting your developers to your users, a thing most companies think is limited to the product manager’s role.
When you connect your developers to the user, developers truly understand what they’re asked to do and why it serves the user and as a result they are able to come up with better solutions and can make better decisions independently. You can’t make yourself available to developers all the time, but you can encourage them to understand your users. You get to avoid many misunderstandings and endless revisions before a feature is launched. Overall, your company will be in a better shape.
So what are some meaningful ways you can engage your developers with the user? This is highly dependent on your business, but here are some things you could try:
- Offer product training to new members as they join your team.
- Require all developers to do a number of customer support days a year.
- Get developers to join a sales demo.
- Send your team to conferences and events with your target customers.
Finally, another overlooked benefit of connecting developers to users is that developers become more engaged since they can see the impact of their work. I still remember the day when an ex co-worker walked into the office with a big smile on his face and announced “First sighting of our app on the TTC!”.