Effective Feedback – Involve Developers

As a developer I think it’s great if I don’t have to deal too much with customers. They need so much time explaining their complains and most of the time it’s just an issue of wrong configuration, using the software in an unsupported use case or they are not aware of a feature. All these questions can easily be answered by a non Dev person like the support. Of course, we want to fix bugs in the software and get new cool ideas from our customers, so the support can note these and give them in a consistent format to the developers or discuss them in a weekly meeting together with the product owner. That way we developers can concentrate on developing and doesn’t get disturbed by doing support.

The Gmail team is calling this “The Sh*t Umbrella”. They have 4 product managers that protects the 100 developers from customer requests and questions. The developers can concentrate on making Gmail awesome. The product managers take care, that the customers requests get into the product in consistent format. Sounds right?

Well, if you’re doing a product like Gmail it probably makes sense. Gmail has currently 500 million users. That makes 5 million users for one developer. That really wouldn’t work. But do you have 500 million users that uses your product daily and just 100 developers? Do you have a product that is used by your own developers day in and out and you’re able to dogfood with your whole organization? If both answers are “Not really” you should consider to bring developers into the communication with the end users.

DevSups

At Atlassian we have a program called DoS-“Developers On Support”. We put a developer for two weeks into a support team. That helps both sides: The developer get in contact with real customer to learn how to fight at the front line. It’s really important to get the problems first hand from the customer and ask the right questions to understand the root of the problem. The dev becomes a better idea how the software is used in the real world.

But it’s also great for the support people: The developer get to know how the support works. For some problems you probably have work arounds. So the support is telling the customer how to work around a special problem. The development department got a request to fix this ages ago but didn’t hear of the problem anymore just because the support is providing that work around to the customer. Very often developers are saying: “I wasn’t aware that this is still an issue” and will bring it up when he is back in his dev team to fix it. In addition the support can learn from the developers why decisions for the product has been made and can explain that more honestly to the end users.

Direct connection

We also use a public JIRA instance and a community support system that is called Atlassian Answers to connect to the customer. At Atlassian we encourage developers to answer questions through that systems. The good thing: You can do a time box each day (maybe 30-45 minutes) where your developer answer these questions and work without support interruptions the rest of the day. Customer are so happy to get in contact with someone that can fix the issues instead of someone that talks about telling someone who is putting it in the schedule that someone can fix this issue (and most of the time there are even more layers). So it is a win on both sides! The developer get to know what bugs the customer and the customer knows that his issues has made it to the right person. Even if you have to let a customer down on a feature because of technical issues, he will accept the answer better, if it comes from a developer.

The GreenHopper team is discussing all feedback each day in a time box. They come together with the product manager in the morning, looking at all new feedback, maybe set new priorities and answer questions.

Expand the program

But not just developers should be at the frontier line. The management, HR, finance and many more departments should be frequently in direct contact with end users to understand the business better.