Brick Thompson: 0:04

Welcome to The Dashboard Effect podcast. I'm Brick Thompson and today I have with me Will Trickett who is one of Blue Margin's solutions architects. How's it going, Will?

Will Trickett: 0:13

Doing good, how are you, Brick?

Brick Thompson: 0:14

I'm good. So today we're going to be talking about a topic that has come up in a lot of our previous podcasts, sort of interspersed throughout and I wanted to just focus in on this topic, since this is something you do and are very well aware of. That is, how do you interview an SME or stakeholder in order to build a report that really meets their needs? I'll preface it by saying it seems like this would be obvious, like how hard could it be? Ask them what they need, they'll tell you, you build the report. As it turns out, you can actually get tripped up if you don't follow a methodical approach and make sure you sort of check all the boxes. So with that, why don't you start telling me, how do you go at this when you start a project?

Will Trickett: 1:03

So I guess to start it, we probably learned the hard way, as an organization by probably doing it wrong a few times, and then just learning some best practices. We like to focus on kind of four particular questions that really drive those conversations. I feel like by the end of those four, you can generally have a really good sense of what is going to be valuable. Or are we just building something to build it?

Brick Thompson: 1:27

Okay, so It's like four areas of questioning, not just four questions, right? So what's the first area?

Will Trickett: 1:34

Yeah, so the first one we asked about is just the business goal of the report. The reason we start with that is I think a lot of times we get stakeholders that come and they say, "here's what we want built. Here's all of the metrics and slices", and they just hand it to you to build, What we find is really helpful is to just zoom out first and say, "okay, why are we tackling this effort in the first place? Help me understand what the the return on investment is that's intended for This report? Are we trying to save someone time for manual reporting? We're trying to generate more revenue, because we have increased visibility. There's a lot of different examples there, but that's the first thing we try to zoom in on.

Brick Thompson: 2:14

Okay. So it's really about the business goal. What are we going to be affecting, in the business by having this visibility that the report provides?

Will Trickett: 2:24

Exactly. Yeah. One example just to help kind of frame that. We have a client that we've worked with for a number of years. They do medical imaging, and they have kind of this referral process that comes from doctors who send them patients who need to get scans. Then from that point, when they receive this order, there's 15 to 20 different stages that the person goes through before they actually get to recognize revenue on that order. So working with them, the first thing we identified was that conversion between those different stages was going to be crucial. When we asked this question, they said, "Well, for every 1% in conversion from the start to the finish of that process, we generate an additional million dollars in revenue, just from bumping that number up." So That helped us frame the importance and goal. We know that we're trying to get people from A to B, and that's the key here.

Brick Thompson: 3:26

We know the goal is conversions. So the goal of the report is to help with figuring out how to increase the conversion percent, because a 1% increase is a million dollars in revenue. So after you've identified the business goal, what's the next area you go after?

Will Trickett: 3:44

So after the business goal, it's specifically about the personas who are going to access the report. A persona is just a group of users that kind of have the same maybe level in the organization or a similar job site and function. So it just represents who's going to be viewing this. That helps us kind of identify with the audience and what the particular view is that person might need.

Brick Thompson: 4:11

Okay. Have you ever had a case where you built a report where you didn't understand the personas and it not go well.

Will Trickett: 4:21

Unfortunately, yes. I think what tends to happen is, you might think you know who the personas are. Then sometimes there'll be new users that are introduced later. So we've definitely had that before. I can think of a couple of cases where there's the initial group we gathered the requirements from and then after we're into the report build, we find out that there's kind of this unknown shadow person who's actually really a key stakeholder and is going to be accessing this report. They might have very different ideas of what needs to be viewed than the others.

Brick Thompson: 4:57

So you've built a report, present it and this new persona that you didn't know about shows up and says "What? This isn't gonna work."

Will Trickett: 5:06

Yeah, and "I need a whole other page for this."

Brick Thompson: 5:09

Hopefully not back at the drawing board, but you need to do a bunch of work to get it right. So really important to drill down. I'm guessing that you somehow need to dig in and try to figure out if there is a hidden persona, that maybe the stakeholder who you're interviewing is not aware of?

Will Trickett: 5:27

Yeah, I think it's super helpful if you can highlight the fact that different people need different things. You need to really build things to a certain group of people. Make sure that's clear.

Brick Thompson: 5:40

Do you always want to talk to that persona?

Will Trickett: 5:43

Absolutely. Yeah.

Brick Thompson: 5:45

Will you ever proceed without being able to talk to that persona?

Will Trickett: 5:48

90% of the time, we would require it. Maybe in certain cases, if it was clear what they needed. I think generally speaking, you want to get on the phone with them, or at least get their input via email or something.

Brick Thompson: 5:56

Because you don't want to have the telephone game. The persona told the person who's telling you. So then what's the third area of questions?

Will Trickett: 6:14

Yeah. So once we know the goal and the user, then we're asking, what questions are you trying to answer with This report? This is kind of the next layer down, we're really trying to understand like, What are the knowledge gaps that they're looking to fill with the report? Maybe there's just not good visibility into a certain area. I think back to that conversions example, one thing there is, you know, a lot of different patients had demographic characteristics that might suggest that they would be easier or harder to convert. Then also age, gender, location, things like that. So we wanted to really identify were their characteristics that we could find that would help them target those populations to keep converting through the funnel. Secondly, within the different stages of the funnel, there might be one particular area where it took a long time for them to convert to the next stage. So another piece of that was, is there an association between the length of time something is stuck in a bucket, and whether or not they convert? When you kind of start to understand those questions, and you can design a report that answers those effectively,

Brick Thompson: 7:33

So you want to make sure that it answers questions, it's going to allow the user the report, then to go and do something about it. So I'm assuming in those examples, that would allow them to fine tune their funnel management processes. Figure out ways to help certain demographics, get this diagnostic test that the doctor ordered, or figure out if there's a way that you can make the process of getting a persona go smoother. That way you don't get stuck in one of these buckets of the whole process?

Will Trickett: 8:09

I think that's the other side of the coin is, like you said, what action do you take with answering that question, right? If you get some of that, as you understand what they're trying to try to answer.

Brick Thompson: 8:21

Then I'm guessing you also want to make sure this is contributing to the original goal that we talked about. I mean, the example you're giving, obviously it does, but there might be cases where it's not quite so obvious, where you can sort of get lost in the okay, we're answering all these questions. Was it really getting us to that goal?

Will Trickett: 8:39

This would help weed that out to make sure that you're, you're delivering value with what you end up sending to end users?

Brick Thompson: 8:47

So you said there were four areas of questions. What was the fourth one?

Will Trickett: 8:51

Yeah. So the fourth one is like the lowest grain, where you're asking them"what are the particular metrics and slices of data that you need to support answering those questions." That's sort of where most people start, is what are the things That you need on this report? We like to keep that last. That way, we understand all that context, and then we can say, based on these few questions we're trying to answer, here's the things that we need to solve that. That's what we use to inform our design. It's just an inverse way of thinking, yeah.

Brick Thompson: 9:22

You might think you want to start with what metrics do you want, what are the measures that you need to see you get to those- but understanding all that context before you get to that is really important to making sure that you're coming up with the right metrics.

Will Trickett: 9:36

Exactly. Kind of as a side note, when you're taking the time to design a report, I think most most developers have reached a point where they're, they're just stuck there and think they know what they want to build, but there's a blockage, you just don't understand like exactly what the user needs. If you've answered those first three questions, I think it helps you in those moments, say I actually need to focus on this more or this more versus just kind of being unclear on what the goal is.

Brick Thompson: 10:03

So metrics are obvious- the numbers, the measures, that type of thing. Slices is really just how you're looking at the data in subsets, right? So, in your earlier example, you want to look at data by certain demographic characteristics, or maybe you want to look at the data by geographical regions or that type of thing.

Will Trickett: 10:27

Exactly. That's a perfect example.

Brick Thompson: 10:31

Those all make sense. So I understand the four areas. It sounds like it might be a lot of work to get through those. What's your typical amount of time? Let's say you're the report engineer working on this- how long does it take you to go through this process? Typically?

Will Trickett: 10:46

Yeah, I think 45 minutes is usually what it would take.

Brick Thompson: 10:52

Oh so this isn't gonna take hours and hours. It's also not, "hey, you can send me an email telling me what you want and I'll get it done."

Will Trickett: 11:01

Right. I think to do it well, you need you need the time. It shows if the stakeholders are invested in making sure that the report is going to be really actionable, too. Yeah, 45 minutes, you can run through those questions and get a pretty good sense of what you need to build.

Brick Thompson: 11:17

Okay, great. I know there's a lot that comes after this- doing wireframing and building a first draft and having to get the data to validate and all that stuff, but we'll leave that for another day. Appreciate your time. Thanks!