Review of Stakeholder Whispering by Bill Shander

Full disclosure: Bill and I met through the DVS, and have known one another for years. I received an advance copy of his book. I don’t think that has influenced my opinion, except that knowing Bill makes me even more willing to encourage you to trust his advice. I have always appreciated his warmth, patience, and common sense. He’s a very positive guy who’s focused on making good things the right way. That ethos shows through when working with him, and in the book.

Stakeholder whispering by Bill Shander is an approachable book about why it’s important to solve the right problem, and how you can make sure that you’re doing it. Having worked with many designers over the years, I can say that stakeholder whispering is the hardest part of the job to get right, and often the most important one. The book offers simple, clear advice on how to make sure you’re getting to the bottom of a situation before diving in with solutions.

It can be very hard to whisper well. Consequences for failure can be severe, but there aren’t a lot of books that focus on just this one aspect of working with a team. This book offers guidance from an expert whisperer on the small things that might trip a new designer up. Reading it is like shadowing a senior designer at work.

Bill brings the reader along at a level that’s gentle enough for a beginner but also valuable for an expert. Written with empathy and a sense of humor, the book feels like a comfortable conversation over tea with a friend, commiserating and sharing tips with someone who has had all of the same struggles and knows what it’s like. At different times, I found myself laughing out loud, grimacing in recognition, and nodding along. I appreciated how Bill used simple, practical examples to demonstrate his points (usually accompanied by a verbal wink, just to make sure we saw what he did there).

What does this have to do with data vis? Everything, really. Helping people push past “I want this chart” and get to a good outcome is a struggle we all face. This book is for anyone who needs to work with multiple stakeholders to help their projects succeed. (It might also be useful for stakeholders who need to work with designers, so that they can understand why we’re asking all these questions.)

Here are some of the topics addressed in the book.

Common painpoints:

Pushing back without saying no
Stakeholders who dictate solutions or don’t care about their stakeholders (especially the hidden ones)
Knowing how & when to lose the battle
Breaking a problem down into manageable chunks
Switching roles as you moving from problem identification into the design process, and remaining flexible in your approach

What you will learn:

Using neuroscience and cognitive behavioral therapy to understand stakeholder dynamics
Keeping the focus on the problem, and not making it about you
Empathy as a tool to enter the client’s frame of mind, without losing your own
Creating a space for not-knowing: encouraging curiosity, even when people think they know what they need
How to prepare for a conversation, and how to use what you hear
The four components of productive listening: focus, attention, interruption-free, and picking up on nonverbal cues
Switching between the surface ask and deeper structure when solving a problem
Listening for holistic understanding, and simplifying without oversimplifying
Why finding the right problem might not be enough (and what to try next)
What success looks like
How to tell whether your stakeholders are open to whispering, and what to do when they’re not

These topics apply everywhere. I think these techniques might matter more for data vis for a few reasons:

Stakeholders are less likely to understand the details (of the user task, or the solution)
Other designers may not have the technical experience to follow along
Experts may be so frustrated by trying to explain the problem that they won’t even try. When you can use these techniques to demonstrate understanding, you get to the real conversation faster.

As with all experience, the magic happens in knowing how to dance, not in just following the steps. You need to develop a sense of rhythm and an instinct for where these principles apply. That said, experiment. Apply these techniques. They will help.

Question time with Bill!

I had a few questions after reading the book, so I reached out to Bill. He kindly answered them here, to share as part of the review:

This book was focused mainly on what I would call framing the problem: the needs identification step before you get into the design work. Can you talk about why you chose to focus on that part of the process?

The short answer is that I haven’t seen enough people write about or talk about this. It’s the part of the process that is mentioned but rarely explored in detail. In other words, designers (and others) are told they need to do “needs assessment” or “requirements gathering” and “ask questions”, etc. But to me, that’s like saying “make some beef stew” without providing a recipe. Because it’s not so simple. The recipe is the “how”. You need to ask the right questions, in the right way, of the right people, with the right tone, to really figure out what is called for. And that takes either years of hit and miss experience to figure out on your own or you can learn a process and a way of thinking about this that will get you up and running much more quickly. I wanted to provide that to people based on my experience. Oh, and by the way, a key part of all of this is to first just acknowledge the idea that our stakeholders often don’t know what they need. They need our help figuring it out. Once we acknowledge this, we can move on to the “how”.

What do you do when you’re stuck with a stakeholder who can’t be whispered?

As I say in the book, the short answer is that you should find new stakeholders. If your boss, or client, or whoever, won’t engage, then you should find a new boss/client/whoever. Honestly. Life is much more fulfilling when you’re working with people who respect you and engage with you as a thought partner. That being said, there are some techniques to help soften an intransigent stakeholder. For instance, start small. Just ask ONE key question, like “how will we measure success”, which is a very informative question to help you understand true needs pretty quickly. For instance, if your boss says “make a dashboard of our HR data”, but the measure of success is “employee retention goes up”, then you know retention is a key part of that HR data that needs to be the focus, and maybe it will lead to follow-up questions about how that data might help with retention, what other data might affect it, etc. Part of starting small is realizing you have to gain trust to engage with reticent stakeholders, so a short focused meeting with incisive questions will earn you longer and more complete conversations over time.

Designers are often very good at listening, but struggle when it’s time to transition from a position of understanding to become the expert presenting solutions. It can be hard to be seen as an expert when you’re in the role of listener and learner (especially working with an experienced team). Can you talk about ways to avoid this trap?

Expertise is an incredibly valuable thing. If you are new in your career, you may not be perceived as the expert, which makes things harder. But the great news is that you can lean on others’ expertise. Rather than saying to your stakeholders something like “pie charts suck!”, you can say, “we know from research on human visual perception that humans aren’t very good at distinct value comparisons when looking at circular shapes, so a pie chart won’t be as effective for this visual because you really want your audience to compare those two numbers – research also shows that a bar chart will be much more effective here, so I’d recommend that.” When you cite research, that glow of expertise will shine on you and you will gain trust. As you gain more and more trust, you will eventually be perceived as the expert and you will walk in the room with the gravitas and respect you need to engage effectively with any stakeholder!

Interruption free can sometimes be a problem for time management when talking to an expert. Can you share some techniques for using active listening to guide the conversation, as opposed to giving up control?

There is a fine line between active listening (really listening and hearing everything, without jumping constantly to your own thoughts and reactions and perceptions) and simply being someone’s audience, and they’re driving the entire conversation. The difference between the two is a true dialog where you are asking good follow-up questions based on what they’re saying. BUT, the key to doing this well is to NOT be perceived as just listening so you can jump in and respond, which is what most people do, right? (Listen, react…listen, react…) No, you need to truly listen, really hear what they’re saying. What they’re saying will trigger thoughts and reactions in you. Capture that if you need to. And respond with questions. But probably not every thought and question you have needs airing. What are the ones that you really need to address in the context of helping your stakeholder figure out what they really need? This is a gray area and something you can only learn over time and in your context, so this is something I can’t exactly teach, except to suggest you try to find that balance. Simply being reminded that there is a balance to be found will hopefully help you get there in time.

You discuss the importance of building a holistic understanding of the problem, and switching between superficial and deeper concerns. Can you talk about how to interpret what you hear, and how to process that interpretation with stakeholders?

One of the most important initial ideas in Stakeholder Whispering is to acknowledge that we live our lives driven largely by our subconscious. So in the context of work, that plays out in the automated response to all of our work. For instance, in today’s world, what do we do when we want to make “data-driven” decisions? We measure stuff, and then we make a dashboard out of it! This automated response isn’t bad, but it’s just so rote that we don’t always think it through. We need to measure stuff, but which stuff, and how much, for how long? And we need to understand that data, but is a dashboard the answer or might it just be a 5-minute call to review one key metric? It depends. So we have to probe deeper than the automated response. This applies to everything. So to the question, the “superficial” is the initial obvious concern/request/plan. And “deeper” review is literally the entire point of Stakeholder Whispering. Sometimes the superficial initial idea may be all that’s needed. But sometimes it isn’t. Whispering to figure that out is what it’s all about! The way to do it is to ask incisive questions, open your ears with your domain and data expertise, trust your gut about things that you know might be concerns or worth further exploration, and probe those. The book is full of specific techniques to do it, and it’s hard to explain without diving deep. But the short answer is simply to engage what I call “useful paranoia”. Something is always missing or not quite right, so probe it! But that doesn’t mean everything requires a deep rabbit hole. Explore thoughtfully, and know when you’ve done enough to move on to the next concern. This is also something you will develop over time, but hopefully the ideas I share in the book will speed up that process.

For a new researcher, it’s often hard to balance best practices from the quantitative social science research they might have learned in school and design research in a business setting. Concerns about deviating from script, “biasing” responses, etc. are common. To me, it’s always been a matter of incorporating those best practices into a more fluid dance of the conversation. Can you talk more about how you think about that balance?

I think that balance is actually inherent to the Whispering process. Because the way I recommend doing it (and I talk about this in the book) is like therapy. When you go into therapy, and you share your childhood trauma or relationship troubles (or whatever), your therapist doesn’t give you solutions or ask leading questions. They ask intentionally open-ended questions like “how does that make you feel?” The point of therapy is to help you understand what you’re feeling. That’s what Whispering (and research) is about. You ask unbiased questions to be sure your data is pure. Now, in Whispering (as in therapy), sometimes the questions will eventually start to lead the witness a bit. The therapist may eventually say “it seems like you’re getting angry…is that what you’re feeling?” because they are there to guide their patients to some degree, based on their expertise. And in a Whispering session, you may start to ask less open-ended questions as you get a sense of where things are going. You might start with something like “why do you think a dashboard is best for this project?” But later in the conversation, you might ask something like “do you think a report might be more effective since you mentioned that people will be reviewing this on a plane and only 2X per year…maybe a dashboard isn’t the best tool for the job?” It’s OK to get to this point because, as the therapist, using your expertise and experience and active listening, you can help guide your stakeholders to the best decision based on the conversation. You’re not conducting primary research, so the standard does shift a bit from those types of conversations, and that’s the “dance of the conversation”, as you describe it, that you need to get comfortable with.

Erica Gunn

Website

Erica Gunn is a data visualization designer at one of the largest clinical trial data companies in the world. She creates information ecosystems that help clients to understand their data better and to access it in more intuitive and useful ways. She received her MFA in information design from Northeastern University in 2017. In a previous life, Erica was a research scientist and college chemistry professor. You can connect with her on Twitter @EricaGunn.