Sharing customer context with developers: 9 ways how to

But before we dig into them, let’s answer the question “Why is it important to share context with developers in the first place?”. Providing your teams with more context allows you to give them also more freedom. They will understand the problems your customers are facing, they will understand the business value they’re helping to create and therefore they will be able to make qualified decisions themselves and faster.

So how can you share customer context with your developers?

1) Forward interesting emails

Did you just receive an email from a customer with interesting insights? Or an angry email with a list of complaints? Forward it to the development team. Simple as that. I can guarantee you that everyone on the team will read it. Even though they might get dozens of email notifications from various internal systems, emails with subject “Feedback on latest release” will stand out.

Recently, I started sending emails to our customers after release asking for their first impression on the new functionality. Once I get the reply, I am forwarding it to the team so we can discuss it afterward. It’s a great feedback loop that provided us with important insights.

2) Involve the team in the conversation

We use Intercom as one of the main channels for direct communication with customers. And one of the great features of Intercom is sending predefined messages to users based on certain triggers. We use this functionality in a few teams to get feedback on recently released features.

We placed a feedback link within the app that opens the Intercom chat window with a predefined message. When the customer replies, the conversation is assigned on the team and they’re also notified via email. This way the team can quickly see what customers think about the functionality.

Link within the app that opens the chat window

3) Track your customer feedback in one place

While it is great to forward the feedback to developers as it comes, it’s also really necessary to keep it tracked in one place. People tend to forget and they also tend to give higher significance to things they’ve heard recently. Having the feedback tracked in one place will help you with both of these issues.

Moreover, later on, you can share all the tracked feedback with your developers when you start discussing improvements in the product given area. You will have much more information, you’ll know which customers were unhappy and you can involve them in the discussion.

There are plenty of tools you can use — Productboard, ProdPad or UserVoice to name a few. But even if you should use Excel spreadsheets, it’s really important to have all customer feedback in one place, especially if you’re in B2B.

4) Summarize the issues

Now that you track all your customer feedback in one place, going through it again and summarize it for developers before you start working on a new feature is always a good idea.

In Kentico, we do that through a document called Problem definition. The goal of the document is to describe a customer’s problem in the detail necessary for the preparation of user stories and design. That’s why it includes a description of jobs our customers are trying to achieve together with linked feedback that’s stored in Productboard, issues with the current solution, overview of the competitive landscape and finally a proposed solution to the problem.

Having the problem summarized and documented really helped us with discussion during groomings and preparation of the development.

5) Invite a developer on a call with a customer

What’s a better way to learn about customer problems than hearing it directly from them. As a product manager, you’re (hopefully) having calls with your customers often, so why not leverage this opportunity and invite some of your development team members on the call as well?

Now you might be arguing that your developers don’t want to participate in such activities or you don’t know how to convince them to do so. Well, a good practice is to start with more technical calls. There your developers can be involved in the discussion and answer questions your customers might have. Or they can ask themselves to better understand the customer requirements. Also, try to explain why you need them on the call beforehand and what they can get out of it.

I am not gonna lie, it won’t be easy to convince developers to participate at first. But once you can do that, you’ll start seeing the benefits. I lost count of conversations we had after the call that started with “wow, we have never thought of their scenario before”.

6) Take a developer on a customer visit

This is a direct step up from the call. If you can afford to take one of your developers on a customer visit with you, do it. They will get unique insights into the everyday life of your customers, they will see them using your product and they can hear the feedback first hand. There’s literally no better way how to share context with developers than this way. This is the holy grail you aim for.

7) Share the takeaways from the visit

It would be wonderful if you could take every single member of your development team together on the customer visit. But let’s be real here, that’s not possible. What you can do though is to share your notes and findings once you return from the visit. You can write a blog-post on your internal wiki or share it via email. But what really worked for us was to organize an optional meeting, where we made a brief presentation with the most important takeaways. Anyone from the whole company could come, listen and engage in afterward discussion.

8) Organize a design sprint

Recently, I wrote an article about my lessons learned from our latest design sprint where I mentioned that it’s very useful to have one of the developers in the design team. Not only they will provide you with a unique point of view, but they will also be present during the interviews with the customers and during the final validation calls. Moreover, you will together have to come up with a solution to fulfill the sprint goal, which further motivates the team to understand the customer’s problem.

9) Raise the issues on a regular basis

In Kentico, we have a bi-weekly meeting for the whole development where each of the teams presents what they delivered within the past two weeks. However, not only developers are presenting on these meetings, but most of the time we also have presentations from sales and customer success departments. During these presentations usually missing or problematic features that come up during recent conversations with customers are highlighted. So if you have a similar platform in your company (e.g.: sprint review) feel free to invite someone from sales or customer success. Not only they will benefit from knowing what functionality was delivered, but your already present developers will hear about issues your customers have on a regular basis.

So there you go, these were my 9 tips on how you can share customer context with your developers. But no matter the form, important is that you DO share context with them.

Author