A recipe for software teams to engage with their customers
There’s a shift happening in the product and software development industry. Technical people in teams are no longer relying solely on a product owner, business analyst or UX expert to represent customer needs. The gap between teams and their users is crumbling (and in many places, it has already well and truly crumbled). More and more people in teams are engaging directly and deeply with their customers.
I’ve been in such a team, and I’d like to share how we ran customer interviews, analysed our findings, and agreed on how our product could change based on what we learned. We discovered a recipe for engaging everyone in customer research — so that we could all make great product decisions together.
Perhaps you’re in a team that wants to do the same thing. Maybe you don’t have a user research or customer experience pro in your team, and you’re looking for how to get started. Or maybe you’ve been doing this for a little while, and you’re looking for other practices to incorporate into your own. Either way, this recipe is for you. It’s one answer to how a team can develop customer-centric thinking and engage with customers themselves, without needing an expert, a product owner or a business analyst to do it for them.
An overview
To start with, you’ll need access to customers or users who are happy to meet with your team. From there, it’s quite simple — just a matter of prepping the user testing, running the tests and then debriefing together on the findings. The final outcome: your team will be in the best position to make the right thing for their users, because they share understanding about what customers really need.
Let’s do a deep dive into each step.
Set up the infrastructure.
Book in some interview times with your users and customers. Make sure you’ve got a debrief session booked in soon after the interviews, ideally on the same day.
Decide together what you want to research.
Discuss the things that you’re not quite sure about as individuals and as a group, and anything else you’d like to validate. Rule of thumb: has anyone heard people in the team exchanging opinions on how something should look, without finding an easy or speedy resolution to the discussion? Those opinions are things that you want to validate with customers.
When you’re recording your opinions, questions and uncertainties as points to validate, you might notice that you’re getting pretty deep into the details. If so, try converting these detailed questions into open-ended scenarios that encompass the thing you’re trying to validate. Later, when you’re testing, this will come in handy. It’ll help you to focus in on what’s important to your customers (as opposed to what’s important to you).
Let’s look at an example of moving from a detailed feature-based question to open scenario-based question. Imagine that you want to validate whether people need to see overdue dates on their screen. Ask yourselves why those dates need to be there — what value do you think your users will get from them? Perhaps it’s about the user being able to prioritise their workflow by looking at the overdue things first. So your open ended scenario might be to ask present the screen to a user, and ask them to prioritise the things that most need their attention. As they talk through why they picked certain things, you’ll soon hear about whether dates come in to their decision.
When you’re finished prepping, ideally you’ll have a list of scenarios to run through, and maybe some stray questions. Now it’s time to get your hands dirty!
Run the sessions with customers
Invite the whole team along to a session where you meet with customers or users, and run through the scenarios that you’ve prepared. Make sure that as a team you’re prepared with something to take notes on, and that everyone has a chance to ask questions.If you’re facilitating, try to encourage the open ended lines of questioning. For example, if someone asks your customer “do you need X feature?” try to move the conversation to the intent behind the feature, and speak to what the underlying human needs are.
Once you’re run the customer testing session, you’re in the situation where everyone in the team has observed the test, and they’ve all come away with their own different interpretations of what your customers think and why. These different interpretations are gold — now it’s time to bring them together!
Team debrief
This is where everyone in the team has the chance to speak. Collect everyone’s observations, and start writing them up in a visual format. I find that mind mapping is a very useful tool here. As your team are talking, write down what everyone is saying, clustering similar observations together into themes. Draw connections between the different ideas. Look at the different clusters of observations. Can you start to see patterns emerging? Obvious action points? Underlying user needs and mindsets becoming clearer? Capture any answers that you’re finding to these questions.
This technique is kind of like mind mapping, but from the outside in. Most mind maps start with the central themes, and move outwards to details. But here, we’re starting with the details, and connecting the details to try to find the central themes that summarise what we’ve seen.
If you’re wondering how this works, pay attention to the order in which things are written in the animation below:
This team debrief is a process of moving from everyone’s individual observations to a shared understanding of customer needs. It can be quite tricky, and it might take a few goes. On the other hand, you might find that your customer needs are quite unambiguous and it doesn’t take you much effort — it all depends!
Find your action points as a team
Look through the observations, user needs, actions, suggestions, patterns and ideas that you’ve uncovered. Triage what you’re going to do about them. Here’s an example of how you could triage things:
- Implement. This means there’s an obvious solution we can all see, and we’re going to do something about it right now.
- Survey. We’ve got a couple of different ideas in the team for how an implementation could look, so we’re going to do a low cost form of testing where we prototype up a couple of options and send them out to our customers in a survey.
- Question. This is looking pretty ambiguous and we need to do further investigation on this specific theme at our next customer testing session.
- Defer. We’ll track the need to see if it pops up again later, but we won’t consider it a high priority for now.
Once you’re done with this triaging process, you might have a list of things written down with I, S, Q or D against each of them. You’ve got your actions taken care of! These outcomes are gold, because they represent shared commitments, shared understandings and shared questions for your teams.
Putting it all together
So you’ve set up some customer interviews, completed the interviews together with the team, analysed the results and found the action points. Nice going! You might now have something which looks like this:
Now it’s up to you to take those actions, and to remember these learnings as you’re making further decisions on what your product should and shouldn’t do. You’re at the end of this round — and hopefully everyone feels clearer now on what they know and don’t know about their customers.
I’d love to hear whether this recipe was useful to you, and how it relates to the way you connect with customers in your team. Leave a comment below if you have thoughts to share!
