You are part of a successful multi-disciplinary team working in a user centered and iterative way. A stakeholder – not a user – in the service your team manages gets in touch with feedback. What’s your first reaction?
It’s probably to tell them to go away. This reaction may be even more vigorously expressed when the feedback betrays a lack of understanding about how your team works.
For example: “I need to know the date when you’ll have finished delivering the new system.” Or: “users won’t like that design, so you need to change it to this one”. And, worst of all, “I thought the old system was bad but the new one is even worse: please change it back.”
In my experience, telling people who provide feedback like this to go away is like chopping off the top of a weed without going after the root: they’ll be back again next month a bit stronger, a bit more persistent and a lot more likely to strangle something.
A different approach
Particularly in the public sector, wider organisational hostility towards agile, user-centred approaches can lead us into a hedgehog response to feedback like this: you don’t understand, I’m not giving you a date or changing anything, please go away and now I’m going to curl into a ball and display my spikes.
The alternative is to go looking for the question that lies behind the feedback that you have received. Often, it’s at this point that you realise that the person giving the feedback has asked themselves the right question but come up with the wrong answer.
But what’s the date?
Take the “I need to know the date when you’ve finished delivering the new system” feedback. The obvious response to this is:
agile doesn’t deliver a big bang approach and it doesn’t make exact commitments beyond a 2-3 sprint horizon, so I’m not going to give you a date, now please go away and stop distracting the team from their important work.”
If you step back and ask why your stakeholder is asking for a delivery date, things can change. For example, say that the feedback was given by a stakeholder about to attend a meeting where the work on the service will be discussed. They’re worried about the questions they might get from others about the service and want to show confidence in the work of the service team because they think you’re doing a great job. (You’d probably agree that this is the right question to ask!)
They’ve decided that the way to provide confidence is to give a completion date, because that’s what has given confidence in the past. (That’s the wrong answer to the question.) At this point, you’ve got enough detail about the intent behind the feedback to give a different answer – one that goes something like:
if you want confidence in what we’re delivering, that’s great. Because we work in an iterative fashion, we’re delivering working functionality every two weeks and you don’t have to wait until the end of the project to see it. Here’s what we’ve delivered already, and here’s what we’re planning on doing next. As we’re more than halfway to an initial end to end version of the service, that should give you a lot more confidence than a date in the calendar.”
That’s a different answer to the one we’d have given if we hadn’t asked why our stakeholder was asking for a completion date, and it’s one that avoids our stakeholder coming back and asking for “the date” every two weeks like they’re taking part in a marriage-themed reality show.
(I’m simplifying slightly here. Your stakeholder may still say “but what’s the date?” after that response. In that case, you’ll have to run them through why you’re going to get a more accurate idea of completion with an iterative process that defines a minimum set of functionality and adds to it, and doesn’t pluck dates out of the sky and then deathmarch the team towards them. That’s OK, because once they get it they’re going to explain it to their meeting for you.)
But isn’t this departing from “user needs, not government (stakeholder) needs”?
Listening and responding to stakeholders doesn’t mean that you start changing your service in response to their requests. You should still set and define priorities and direction based on user needs, and user needs alone. What I’d suggest is that articulating and explaining – not justifying – why and how you do this to your stakeholders can save you some time in the long run.
Take the “users won’t like that design, you need to change it” feedback, or even the “change it all back” feedback. This could come from stakeholders who have become slightly too expert in a service. If that’s the case then they’ll need a polite reminder that they’re not the user and what works intuitively for them won’t automatically meet the needs of the users of the service, backed up with data about how users are succeeding using the service.
That feedback could also come from stakeholders who’ve been around for a long time and are aware of past pain points for users. They’ve thought about the pain points (right question) and come up with a solution in their head (wrong answer). If you can find out what the pain point that they’re worried about is, then you can have a conversation where you can show how you are using analytics or user testing or interaction/content design to overcome and monitor the user journey around that pain point.
In all of this, it’s important to note that you’re not taking the feedback into account because the stakeholder is important or because you like them. You’re examining why they’re providing the feedback, then checking whether the point they’re making can be verified by data. Crucially, you’re also allowing the stakeholder to see that you’re not making subjective, emotional decisions but you’re basing your approach on research and data.
How to prioritise user needs when responding to feedback
When I was product owner for a large government website, I had a query from a senior stakeholder about a formatting problem with one of the outputs on the site. They were worried that a lot of people were seeing the issue (right question) and thought that the best response was to immediately fix the problem (wrong answer when considered in context).
The formatting issue was with the PDF version of the output. The stakeholder assumed that most users were viewing the PDF (for a long time, this was the only way of accessing online outputs from that organisation, so it’s an understandable assumption) and not the HTML version of the output. I was able to provide the analytics data to show that a low single figure percentage number of viewers had accessed the PDF version. If I remember correctly, this meant about 30 – rather than several thousand – users had seen some bad formatting. I could therefore evidence why I’d chosen not to immediately prioritise fixing the formatting issue when we had some other bugs that were a higher priority.
Prevention vs cure
This blog post has looked at how to handle questions from stakeholders. At least some of the time your stakeholder will have asked the right initial question and got to the wrong answer before coming to speak to you. If someone cares enough about your service to submit feedback or ask questions about it, then they’re a) unlikely to go away and b) a potential advocate for the work of your team. That means it’s worth taking the time to unpick why they’re asking the question before deploying hedgehog mode.
Before I finish, it’s worth pointing out that questions are essentially failure demand on your communication approach. If your team are proactive in communicating what your team is doing, then questions should at least diminish. You’ll know this is working when you get questions from stakeholders that you can answer simply by directing them to a blog post, or inviting them to a show and tell. (Section 3 of this blog post has a few more thoughts on comms in a multidisciplinary team.)