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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
> 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?
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.
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 can do user testing and have developers watch.
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.
Yes ! nothing like doing support for basic questions to understand the pain points and what can be improved.