RVB: 00:00:00.400 Hello, everyone. My name is Rik, Rik Van Bruggen from Neo4j, and here I am recording another episode in this little series that we are developing. And I have my friend and guest and partner in crime, Stefan, on the other side of this Zoom call. Hi, Stefan.
SW: 00:00:19.652 Hello, Rik. Long time no see. Let's meet up soon.
RVB: 00:00:23.841 Let's meet up soon, absolutely. So yeah, we are on a little bit of a journey here. We're on a little bit of a quest. We have embarked on a little bit of a project to try and get a better handle on and share our experiences on how you build the value case for graphs and graph databases, graph analytics in our organisations. We've noticed that so many people struggle with that. And yeah, so today we're going to talk about the next part of this journey. Last episode, we talked about finding the use case, right, how do you identify the best graph use case? And today we're going to talk about actually building the case for that use case. Right, Stefan?
SW: 00:01:15.895 Yes. It's one of my favourite topics. And one of the questions that I always struggle with is, how do you actually build the case that matters, Rik?
RVB: 00:01:30.129 I know. Well, I mean--
SW: 00:01:30.920 What's your opinion?
RVB: 00:01:32.304 Well, I think we've seen this so many times before. Right? Graphs typically have a high sexiness factor - or how do you say that? - with--
SW: 00:01:45.645 Yeah, yeah. You can say that.
RVB: 00:01:47.660 Well, I can say that, yeah. They're very sexy, and they're very attractive to, I would say, more technical audiences. Right? And so as a consequence, that does not always mean that these technical audiences are great at building the case, the value case for a graph application. And in spite of what we may want and hope, I think how you build that case actually really matters. It's not about what you think. It's about what you can get others to think and how you can convince others to actually adopt this new type of thinking, this new technology, in a material way. Right? So how you build the case, in my opinion, really matters. It's not just about being right. It's about other people granting you that you are right.
SW: 00:02:45.126 Oh, yeah. And I guess that's kind of a tricky thing because-- it reminds me of a really good Swedish person, Hans Rosling. And I remember one time when he said, "I am right and you are wrong." Usually, that has, I think, never ever changed a person. So I think it's a [inaudible] very good book, Factfulness. I think that quote is horrible. A lot of his other stuff is extremely good. But saying that the other person is wrong and you're right, this is the ultimate divide. But maybe there is another way to kind of get people on your team and start exploring this together. Do you have any kind of tip on where to start with that?
RVB: 00:03:28.053 Oh, totally. I mean, obviously, I use those types of tools and techniques all the time. I've been working in the sales environment for a very long time, and there are very clear and proven techniques for this. And I don't mean that in a salesy way. I think if you're genuinely and constructively trying to build a value case for a graph application or a graph use case, I think there are very, very well-documented techniques to do that. And the first one that I think I would mention, the most important one, in my book, is to ask a particular type of open question. Right? I mean, you really don't want to be leading the client or your colleagues too much. Rather, you're asking open questions like, "Why is this important? Tell me. Let's explore this together. We have this wonderful idea. We have this wonderful use case" - see previous episode - "So why is this wonderful? Why is this interesting?" Right? And then the key thing, in my book, is that the first answer is never the real answer.
SW: 00:04:52.267 What?
RVB: 00:04:54.088 [laughter] Right? And in my book, what you need to do is really ask that question over and over again. You really need to kind of peel the onion a little bit. And in the article that we wrote about this topic, I think we gave a little bit of an example on this, right, so how you can do that and how you can actually peel the onion. For example, if you were asking the question, "Why is this an interesting use case?" then people will say, "Well, because it will change the way we do things." Right? And then the next thing--
SW: 00:05:29.208 But why will it change things?
RVB: 00:05:31.192 Exactly. Right? So that's the obvious thing that you need to do. Why will it change the way we do things? Because it will enable us to follow a better process for XYZ. Right?
SW: 00:05:42.587 Super, super cool, Rik. But why will it enable us to follow a better process?
RVB: 00:05:47.648 Yeah. Well, I think you're kind of getting the drift here, and people should read the article that we wrote about it. But the whole point here is that you peel the onion, you keep on scratching, and you keep on trying to understand - why is this really material? - and you drive for as specific of a reason as you can possibly get. Now, there is a little bit of a warning that I need to give people here.
SW: 00:06:19.049 Very good warning.
RVB: 00:06:20.505 I don't know if anyone listening has kids, but I have three kids, and I almost chucked them out the window multiple times when they were asking me, "Why?"
SW: 00:06:34.075 "Why?"
RVB: 00:06:34.635 "And [crosstalk]?"
SW: 00:06:35.104 "Why?" I love kids. They're so good at this. They're like the best interview experts.
RVB: 00:06:41.139 It drove me nuts.
SW: 00:06:43.337 But it's to a point. It drives you crazy. So I remember doing this - the process is simple - it's called the 5 Whys, actually, because usually it takes 5 Whys to get to the root cause of the problem. And in my notes doing this at the university, it says, "Keep asking 5 Whys, blah, blah, blah. Don't always ask 'Why?' because very often that can feel like an interrogation or very pushy." So sometimes you need to linger to make it an actual conversation because, if not, the person can feel threatened, I guess.
RVB: 00:07:19.840 Yeah. And I think this is very natural also. And if you're a little bit practised in this type of conversational technique, it's not very difficult, but you need to be a little bit careful with it. Like you said, you don't want this to be a police interrogation. You want it to be a friendly, joint quest for a better graph value use case-- graph value case, sorry. I think that's the objective. And as long as you keep that in mind, then the "Why?" questions shouldn't be too annoying. Now, there's another question that I think is very, very interesting. I love it. It's also an open-ended one.
SW: 00:07:57.946 It's a little bit like the frog and the princess, basically-- or the frog and the prince. Right?
RVB: 00:08:04.211 [That's true?].
SW: 00:08:05.165 Yeah, the classical.
RVB: 00:08:06.311 Yeah. The second question that I usually ask is, "How are you doing it today?" You've got this suspicion of this graph use case. Right? You identified that, and you have a little bit of an idea of what it might do. And then the question is, "Well, how are you doing that today?" Right? And very often people will say, "Well, we don't really do that today." "Okay. So why are you not doing that today? And what effect does that have on yourself? Who is impacted by this type of activity?" And so that's how you kind of explore this. Right? So you ask these open questions: "Why are you doing this? How are you doing this today? Who is impacted by this way of working?" and, "Who is impacted by the impact of this way of working?" You can do this time and time again until you get to something specific. Right? And I think this is key.
SW: 00:09:12.983 Yeah. How does "specific" looks like? Because I think this is one of the things that can be very, very troublesome, and very often--
RVB: 00:09:23.890 Yeah. Well--
SW: 00:09:24.150 --to say that they are fluffy, that's just an understatement. Sometimes people just make weird noises when I push them on these things. Any tips on this, to double down on it?
RVB: 00:09:33.368 Yeah. Well, I think it is really important to make it specific. I think anytime that I've seen people building value cases for graphs and they are not able to make it specific, then everyone will love it. Everyone gets so excited about it. But when you get to the boardroom and ask for budget, they will just shoot it down. It's pretty simple. Right? So being specific, I think, is very important. Now, what people often get wrong is that they think that specific means money. And I don't think that's the case. It's not necessarily about money. Right? People obviously would love to save money or make more money. In any organisation, value is often quantified as money. Right? But I don't think that's necessary. There's other numbers that can allow people to get a much better view of what this graph value case will actually bring to them. And it could be, for example, a reduction of call volume in the call centre, right, or a customer satisfaction index or a net promoter score or whatever it is that you're looking for, right, or a reduced false positive rate in a fraud use case. You see what I'm saying, right?
SW: 00:11:05.812 Exactly, exactly.
RVB: 00:11:06.680 Any number will do, right?
SW: 00:11:10.580 Yeah. And I think those numbers also are more closely related to the organisation, and they also are working very often on those in that sense.
RVB: 00:11:20.553 The thing is that if you have a number, whatever that number is, at the boardroom, they will understand. They will understand what that number means, and they will make the translation themselves into what that means in terms of money. They will understand that. And by the way, not every business decision is based on monetary effects. It's not. Right?
SW: 00:11:48.950 No. Oh, no, there's so many others. And I think this is a very good reminder because I see a lot of people, they go only for money, money, in that sense, but sometimes time, enjoyment-- and there's other things that actually produce this value. And as you say, the board will pick up this immediately. I cannot stress this enough. I don't know how many times when we have done Innovation Lab sprints, for example, we come to the first question, and then the CFO goes, "Stop," bring out the calculator on his phone, start to run numbers and say, "So we can save actually this amount of time by implementing this solution," [that?] meaning that we can already pay for [indices?] on the first query, and this problem is already solved. But instead of talking about how much money they will save, actually, "What are the problem we're solving? What's the benefits for the people, the organisation, and--?" Yeah.
RVB: 00:12:46.131 Well, I mean, the other thing-- and you will have to stop me in about one minute here--
SW: 00:12:52.844 Yes, [I am?].
RVB: 00:12:53.539 --because I'm going to kind of make the link to something that we both care passionately about, which is prospect theory, and we can talk about this for hours. But I do think that this is part of the reason why making a specific quantitative case for graphs is so important, not just because you want to build a case and you want to present that case and all of those wonderful things, but it reduces uncertainty, or it reduces the perspective on uncertainty, which is what we want. If people are going to adopt graphs, they're going to be faced with this all-human limitation on decision-making, which is prospect theory. And if we make it quantitative, it's just going to make the world of a difference in that decision-making process. So I will end my rant over there. [laughter]
SW: 00:13:58.467 Let's end the rant over there. And I think anyone that is interested in prospect theory, go check out Kahneman, behavioural economics, and a lot of these things. There's so many good examples. Let's write some up for the audience as well. But double down on that, I think there is so much learning, and most likely, all of what we're doing is completely wrong. It feels right, but it is wrong. And I think that's the best cliffhanger for the next one because I think we are ready to go to the boardroom for the next episode almost.
RVB: 00:14:30.908 Yeah, exactly. So let's wrap up this episode. Great talking to you, Stefan. And what we are going to do in the next episode, I think, is we're going to talk about how this newly built case that we've just talked about is going to get presented to the boardroom. Right? So that's where we're taking this. Thank you, Stefan, and talk to you soon. Have a great day.
SW: 00:14:55.396 Bye.
RVB: 00:14:56.277 Bye.