Ask HN: How do you get your devs to understand your customers?
16 comments
I hear a lot of encouraging but not requiring. Having something that is required would go a long way imo. If you know you have outstanding work to complete it can be hard to give yourself permission, or feel like you won't be seen as neglecting your responsibilities if you go to something that's only encouraged. That's a struggle I have anyway.
Some sort of customer panel where you ask questions of your users about their business, how they use your software, what it enables them to do and what doesn't it do I imagine would be helpful. You can't take your whole org to you customer(s), but if you have the budget you can bring the customers to you. Also, if you have a good support org, have them work one week in support.
Some sort of customer panel where you ask questions of your users about their business, how they use your software, what it enables them to do and what doesn't it do I imagine would be helpful. You can't take your whole org to you customer(s), but if you have the budget you can bring the customers to you. Also, if you have a good support org, have them work one week in support.
At most employers product management is far separated from product development. There are several reasons for that:
* management distrust of developers, if your developers need a lot of help to do their jobs management won’t let them near the customers for good reason
* separation of concerns, specialization
* emphasis of productivity, developers should be developing
* assumptions and biases that developers are not people people, which is sometimes completely unfounded and other times strongly reinforced
If you want developers to understand your customers they have to be directly embedded in customer engagement meetings where they can directly see customer wants and reactions the same way your product management learns these things. This can prove very risky due to the personalities involved.
In my line of work developers are completely on the front lines directly communicating with customers. My line of work, enterprise API management, is highly technical demanding a wide technology background but it’s not that challenging. The customers know what their end state is but not how to express their business requirements or diagnose their challenges. The developers, myself included, often have no idea behind the business goals for interconnecting various business system but have little challenge solving for the communications in the middle. Most areas of software are not like this, by a lot.
* management distrust of developers, if your developers need a lot of help to do their jobs management won’t let them near the customers for good reason
* separation of concerns, specialization
* emphasis of productivity, developers should be developing
* assumptions and biases that developers are not people people, which is sometimes completely unfounded and other times strongly reinforced
If you want developers to understand your customers they have to be directly embedded in customer engagement meetings where they can directly see customer wants and reactions the same way your product management learns these things. This can prove very risky due to the personalities involved.
In my line of work developers are completely on the front lines directly communicating with customers. My line of work, enterprise API management, is highly technical demanding a wide technology background but it’s not that challenging. The customers know what their end state is but not how to express their business requirements or diagnose their challenges. The developers, myself included, often have no idea behind the business goals for interconnecting various business system but have little challenge solving for the communications in the middle. Most areas of software are not like this, by a lot.
I'm a dev, and we typically ask ourselves what are the customers needs? Then we typically go from there by visualising how the customer would possibly solve their problem today. Then we sketch up ways we could solve their problem with our solution.
If we find ourselves saying "we don't know what the user does today" or "we don't know what the user needs in this scenario" we typically reach out to customers and politely ask for a meeting and try to ask questions that only pry at their needs and problems, rather than hinting at our solution.
We also have metrics and opt-in analytics of our services so we can monitor what the customer do with our product as well.
We have UX designers on our team that really really emphasise this type of way of working/thinking and I think it helps us devs understand our customers better, although it can feel slow and annoying at times to keep asking these questions and doing prolonged workshops.
If we find ourselves saying "we don't know what the user does today" or "we don't know what the user needs in this scenario" we typically reach out to customers and politely ask for a meeting and try to ask questions that only pry at their needs and problems, rather than hinting at our solution.
We also have metrics and opt-in analytics of our services so we can monitor what the customer do with our product as well.
We have UX designers on our team that really really emphasise this type of way of working/thinking and I think it helps us devs understand our customers better, although it can feel slow and annoying at times to keep asking these questions and doing prolonged workshops.
This will sound harsh but:
> The software we make isn't software for software developers
Like most software companies on the planet.
> we need to improve developer understanding of how our customers use the product
I'm pretty sure no dev said that, ever. It's the job of the CEO, managers, project managers, sales people, etc. Anyone but the devs who would do anything not to get fired nowadays.
> encouraging devs to reach out to customers
It's NOT their job. I would be very reluctant to contact customers directly. Most clients don't know what they want, and devs want to please anyone as long as it involves coding. You need direction. Also, when customers have impossible demands, managers will lie that it's possible and try to sell something different. No dev will tell you that something impossible is possible. We are not salesmen.
> We've also pointed to existing bug trackers
That doesn't mean anything at all. Which bug tracker?
You seem very confused about what a dev is supposed to do. You need a PO (project owner) or PM (project manager) or anyone that can understand the customer's needs. Right now you have none and you think your devs should find the issues themselves, or magically find what the customers want.
Feel free to ask if you have more questions.
Edit: the last time I spoke to a customer, I gave a few technical details and no one cared. I don't know what is his IT department, what is his budget, who I have to contact, I know nothing. That's the job of a whole team (CFO, sales, etc). It feels like one of those niche projects where anyone can do anything and the client is supposed to accept that with some kind of unlimited budget, am I wrong? (Edit: "Payroll, HR, and Workforce Management" no wonder your devs are not understanding what you do, you need serious training, simulations, or anything to entice them, but speaking to customer would be a bad idea).
> The software we make isn't software for software developers
Like most software companies on the planet.
> we need to improve developer understanding of how our customers use the product
I'm pretty sure no dev said that, ever. It's the job of the CEO, managers, project managers, sales people, etc. Anyone but the devs who would do anything not to get fired nowadays.
> encouraging devs to reach out to customers
It's NOT their job. I would be very reluctant to contact customers directly. Most clients don't know what they want, and devs want to please anyone as long as it involves coding. You need direction. Also, when customers have impossible demands, managers will lie that it's possible and try to sell something different. No dev will tell you that something impossible is possible. We are not salesmen.
> We've also pointed to existing bug trackers
That doesn't mean anything at all. Which bug tracker?
You seem very confused about what a dev is supposed to do. You need a PO (project owner) or PM (project manager) or anyone that can understand the customer's needs. Right now you have none and you think your devs should find the issues themselves, or magically find what the customers want.
Feel free to ask if you have more questions.
Edit: the last time I spoke to a customer, I gave a few technical details and no one cared. I don't know what is his IT department, what is his budget, who I have to contact, I know nothing. That's the job of a whole team (CFO, sales, etc). It feels like one of those niche projects where anyone can do anything and the client is supposed to accept that with some kind of unlimited budget, am I wrong? (Edit: "Payroll, HR, and Workforce Management" no wonder your devs are not understanding what you do, you need serious training, simulations, or anything to entice them, but speaking to customer would be a bad idea).
100% this. Encouraging devs to reach out to customers? I can't think of a single engineer (particularly on the backend) that would EVER have any desire to do this in their already limited time.
If you have PMs, directors, product designers, etc. actually doing their jobs - then the needs of the customers should already be more than adequately translated into well-defined engineering tasks.
Engineers already have enough on their plates without being forced into some customer-facing or adjacent role.
If you have PMs, directors, product designers, etc. actually doing their jobs - then the needs of the customers should already be more than adequately translated into well-defined engineering tasks.
Engineers already have enough on their plates without being forced into some customer-facing or adjacent role.
> We've tried things like visiting customers in person
The devs are the ones doing this?
> encouraging devs to reach out to customers
> encouraging devs to pair with customer-facing staff
Are the devs actually doing these things or are you just encouraging it?
The devs are the ones doing this?
> encouraging devs to reach out to customers
> encouraging devs to pair with customer-facing staff
Are the devs actually doing these things or are you just encouraging it?
They are doing it a little bit, but rarely initiated.
So is your problem that you can't think of any better ways to encourage or require those things? Enough that your devs will start actually bothering to do them in useful amounts?
Yeah basically. I think we might just be thinking about it wrong.
> devs don't really understand how the customers use the product or why
At the risk of overgeneralizing, I think we do understand, but we just don't sympathize. Either because the product is trying to trik the customers into buying/subscribing (so naturally we don't like that kind of behaviour, even less when we know exactly how's that implemented), or because the product is designed "for babies": nice graphic colors here and there, videos, sweet transitions, whatever. We think that's all unncessary, and a simple HTML+CSS page would suffice for most products out there.
At least, that's what I have seen around. My team is currently building a fitness app. We are discussing tirelessly things like what engaging content we can use, the transitions between fitness exercises, how to keep them motivated to use the app... and the engineers I'm working with (I'm included) we all think that a simple bullet list of exercises and links to videos would suffice.
More often than not, the product just sucks and nothing can be done to fix that (e.g., Linkedin, Facebook, Quora) ... but obviously we won't say anything because we are here for the paycheck.
At the risk of overgeneralizing, I think we do understand, but we just don't sympathize. Either because the product is trying to trik the customers into buying/subscribing (so naturally we don't like that kind of behaviour, even less when we know exactly how's that implemented), or because the product is designed "for babies": nice graphic colors here and there, videos, sweet transitions, whatever. We think that's all unncessary, and a simple HTML+CSS page would suffice for most products out there.
At least, that's what I have seen around. My team is currently building a fitness app. We are discussing tirelessly things like what engaging content we can use, the transitions between fitness exercises, how to keep them motivated to use the app... and the engineers I'm working with (I'm included) we all think that a simple bullet list of exercises and links to videos would suffice.
More often than not, the product just sucks and nothing can be done to fix that (e.g., Linkedin, Facebook, Quora) ... but obviously we won't say anything because we are here for the paycheck.
I think there are different solutions for features vs issues.
For features -
Do developers have ownership? Do they write tech specs, proposals, etc? If so, these should include a section on what problem is being solved. If they don't understand the product this is a good way to kick off more conversations about it.
If developers aren't doing this - e.g. if you're leaving it up to management to tell them what to do and how to do it - that's the problem. Companies like this lack incentives for devs to learn about the product if they're just going to be told exactly what to do and aren't given the freedom to think creatively. If this is you and you want to shift the culture, start encouraging developers to propose features and show that you value their contribution to the product. Invite lead devs to meetings and to comment on documents where features are being proposed, from the beginning, instead of handing them a thing to implement.
For issues -
Are PMs communicating issues well? Including why the issue is important? Perhaps something like a loom demonstrating the exact issue would help.
Have a rotation for addressing issues. e.g. if a dev is on call they should work on customer issues when they're not fighting fires.
For features -
Do developers have ownership? Do they write tech specs, proposals, etc? If so, these should include a section on what problem is being solved. If they don't understand the product this is a good way to kick off more conversations about it.
If developers aren't doing this - e.g. if you're leaving it up to management to tell them what to do and how to do it - that's the problem. Companies like this lack incentives for devs to learn about the product if they're just going to be told exactly what to do and aren't given the freedom to think creatively. If this is you and you want to shift the culture, start encouraging developers to propose features and show that you value their contribution to the product. Invite lead devs to meetings and to comment on documents where features are being proposed, from the beginning, instead of handing them a thing to implement.
For issues -
Are PMs communicating issues well? Including why the issue is important? Perhaps something like a loom demonstrating the exact issue would help.
Have a rotation for addressing issues. e.g. if a dev is on call they should work on customer issues when they're not fighting fires.
I've always tried to include the "why" in the documentation/task/ticket that hits the developers eyes.
When I was an engineer, most PMs/POs would just dictate "what" needed to be built, and give us the standard Agile mantra of telling us to choose "how". But if you also include the "why" of it, not only are you constantly communicating additional information about the customer, but you give more opportunities to get different ideas from different people. In my processes, I always have the engineers look over incoming tasks before they get assigned to be done, and it was common to have some iteration on implementation based on the engineer's reactions and ideas. Of course, not all their ideas were good, but in general the additional collaboration was appreciated, and resulted in additional customer understanding, so it was worth the extra time and effort to bake the customer info into the tasking process.
When I was an engineer, most PMs/POs would just dictate "what" needed to be built, and give us the standard Agile mantra of telling us to choose "how". But if you also include the "why" of it, not only are you constantly communicating additional information about the customer, but you give more opportunities to get different ideas from different people. In my processes, I always have the engineers look over incoming tasks before they get assigned to be done, and it was common to have some iteration on implementation based on the engineer's reactions and ideas. Of course, not all their ideas were good, but in general the additional collaboration was appreciated, and resulted in additional customer understanding, so it was worth the extra time and effort to bake the customer info into the tasking process.
"we need to improve developer understanding of how our customers use the product".
Why? What impact is it having? Or is it just non technical people complaining similar to how a dev may complain that PMs should understand the code more.
Why? What impact is it having? Or is it just non technical people complaining similar to how a dev may complain that PMs should understand the code more.
Rotating shifts on customer service having them serve as a customer service rep for a day 1 to 4 times a year.
Yes, as long as they also have visibility into everything else customers do where things go smoothly. You definitely need to see and fix problem areas of the product, but if 95% of the product is working well, you can get a false impression that the sketchy 5% is a much larger piece of the puzzle than it really is.
Good idea. We should also let customer service write code from time to time, so they get familiarized with how the product is built and get a sense of what's feasible and what's not.
Yes ! nothing like doing support for basic questions to understand the pain points and what can be improved.
[deleted]
It's the PMs job to do all this. Never heard of devs dealing with customers.
If you choose developers because they are technically excellent it means that is where their focus is. You can't blame them. By focusing on the actual use of it you remind them that no one cares how elegant the software is.
You have a weak product management team if you need developers to get requirements. Until you realize that you will never solve this problem.
A company invented the role of "forward deployed engineer" to solve this problem.
You can do user testing and have developers watch.
We have a strong product management team, and a strong engineering leadership. From my perspective, we generally work on the right things, and get them done reasonably quickly to a reasonably high standard.
Whenever I put the word out for feedback, questions, or suggestions for things we could improve on, something that always comes up is "we need to improve developer understanding of how our customers use the product". I'm sure this isn't unique to us.
We have tried many things over the years, I wouldn't say I've found a silver bullet for it. We've tried things like visiting customers in person, encouraging devs to reach out to customers, encouraging devs to pair with customer-facing staff internally on meetings. We've also pointed to existing bug trackers and customer feedback forums as a place where devs can hear the word of the customer that's already been written down. All these things help a little bit, but the general vibe of "devs don't really understand how the customers use the product or why" persists.
Interested to hear how other companies approach this!