RVB: 00:00:00.531 Hello, everyone. My name is Rik, Rik Van Bruggen from Neo4j. And it is with great pleasure that I'm here again together with my partner in crime, Stefan. Hi, Stefan.
SW: 00:00:11.808 Hello, Rik. Nice to see you again.
RVB: 00:00:14.604 Exactly.
SW: 00:00:15.161 Super nice, super nice.
RVB: 00:00:16.953 Great. And we are going to do a sequel to the little project that we started a while ago to try and get a better understanding of graph value. Right? We've been working on this for a while. We've been writing about it. We've been blogging about it. We've been tweeting about it. And now we are recording about it. And there's several steps in this process. Right? And we're going to be going on this journey for a little bit longer in the next couple of weeks as well. But the first step that we want to talk about today is-- I've kind of called it the map to graph value. How do we get there? How do we get to a valuable use case for graphs, like graph databases, graph analytics? How do we find that graph use case? Right? And that's a key problem. Right? We have different ways to do that. We have different techniques to do that. And I think today we would like to talk a little bit about what we've seen, the experience that we have had and how we can find those excellent graph use cases that have the most value for people that want to engage on this. So let's start with the top. Right? Let's start with the most obvious place, where we can get--
SW: 00:01:48.838 At the end of the rainbow.
RVB: 00:01:50.507 [laughter] Yeah, exactly. Let's get it started over there. There's different things that we can cover, obviously, but I guess the question is, to be simple here, who's got the graphiest idea? Where do we find that graphy, graphy idea? [crosstalk]--
SW: 00:02:08.233 I think if we break down the graphy idea-- and a graphy idea that has value to your business because that's at the end what we're talking about. Right? So, of course, that will be one that knows graphs, a graph specialist. Right? Of course, that will be one that most likely know your domain. However, I think the interested part here is in the combination of things. So I usually take inspiration from this old protein-folding game, Foldit, where they put scientists and an online game together to solve an unsolvable problem. It took the scientific community about 10 years to solve it. They solved 35%. They made a game out of it that basically then over 10 days solved 85%, and over the weekend it was already done. But if you take that formula and break it down in components - that's what I usually do to make sense of the world - what we have is that we have deep knowledge, in this case, about protein folding. Right? And then we have the game, which is a process to facilitate new perspectives. And so we have basically deep knowledge, new perspective, and a process to facilitate that.
SW: 00:03:26.067 And I think that is also a very good foundation to start to talk about creativity and value, right, because this is going to obviously be graph experts. They're going to exactly know how to use graphs. Do they know your use case? Sometimes they do. Sometimes they don't. Right? You are an expert on your problem and your domain, necessarily not on graphs. However, what we have now is a very interesting piece here. We have two deep knowledge and two new perspectives. If we then only have a process to facilitate this, we have a success recipe, a success story to be written. Right? So one thing here is to kind of allow that and allow for curiosity and trust the graph experts, in that sense, and have a process so you can actually try ideas. And I think that's one of the things that I fell in love with with Neo4j, just trying it out, because that's the only way to figure it out, how flexible, how easy and understandable it was to actually just kind of have this agile prototyping way and just go with the flow. So that's kind of my idea of this.
RVB: 00:04:40.476 Can I maybe drill down into it a little bit? I mean, you have a little bit of time here.
SW: 00:04:43.773 Yeah, yeah, of course.
RVB: 00:04:44.704 So the first part that I heard there was you talked with the main expert. Right? So let's say the protein-folding example. That means you're going to get some kind of a high-level biology and protein expert in the room, and you're going to ask him, "What are you struggling with? What are the things that you're currently not able to solve in your data world?" and, "How could, potentially, connected data graphs help you with that?" Is that kind of what I'm hearing?
SW: 00:05:19.176 Yeah, yeah, a little bit like that. Right? So try to kind of define what are the challenges, define what they cannot do. And I think, on one hand, the interesting part here is something I talk a lot about, this idea of mental models. Sometimes we are so used to working with things and tables that--
RVB: 00:05:38.956 That's very true.
SW: 00:05:39.615 --everything structured in our head has become [all those?] tables. Right? It's like a ledger system of-- I don't know. It's just insane. So sometimes this is actually also a limitation for the specialist because they have worked with those limitations their entire life. So, of course, you wouldn't go down a path which you tried a gazillion times. However, you haven't tried it with graphs. And this is, again, the new perspective and why I really like that curiousness and working together. And kind of one of the tricky parts that I do see a lot is looking upon people-- a lot of us ask, "Do you have any use case in my domain?" And I think one of the skills-- which is good because use cases are awesome to get inspiration from. Right? But very often we look for the exact use case that somebody else did, so we can solve our problem. But, of course, then that problem is already solved, and the competition is already far away. So it has very little value. That's the kind of paradox here. Right?
SW: 00:06:41.902 So one skill to practise is to kind of break it down into formulas, break it down into pieces, because what it very, very clear is that a graph, as we say, are everywhere. So the use case looks totally different on the outside [in front of them?]. But from a structure point of view, they are very often very likely. As soon as you get that kind of graph thinking going in your organisation, in your team, becoming curious, then it's just to start do it. That's the good part and also the sometimes bad part with Neo. We have so much great content. I think I haven't even watched 1% of it, to be fair, and here we are creating new content trying to solve this out. But at least we're trying to give a structure for looking at content. So--
RVB: 00:07:32.088 The funniest thing for me is that when you actually get a domain expert in the room and you ask them to explain, "What are some of the data problems that you're facing?" before you know it, they grab a whiteboard, and they start drawing graphs. Right? It's happened to me so many times. And I feel like it's an obvious illustration of the fact that if you want to find that graph use case, just ask the expert, the domain expert, because they will usually know, especially like you said earlier - and this was kind of like the second point - if you bring someone who has worked with graphs before into the same room. Right? So the graph experience, having done this before, is actually extremely useful. And I mean, I think it's also one of the things where Neo4j as an organisation has a lot of value to add because I know that I've been living with graphs for the past nine-plus years, and I think I've seen a couple. [laughter] You know what I mean?
SW: 00:08:35.900 What? Have you seen a couple? You're most famous for the beer graph, but let's not go into that. I have to say it in every episode. [laughter] That's just how it is. The beer graph is the reason why I'm here. So that's your fault, but nevertheless--
RVB: 00:08:51.244 So what about the process aspect that you mentioned? So you basically said earlier, "If you bring those two people together and you put them through some kind of a process that brings these two worlds together, that's where kind of the magic happens." Is that a fair way of putting it?
SW: 00:09:12.200 It's a fair way, and also it's a fair kind of case when a lot of people actually F up a lot. Everybody has been to a horrible brainstorming. Right? Everybody has traumatised memories from school and group work. You have to do all the work because nobody else gets it. Right? So basically, what very often happen is that we don't use the collective knowledge. We don't have a process for it. Right? We just think that brainstorming comes to us naturally. It doesn't because it involves a lot of fears with the leader of the room, and some would be more extroverted, introverted, and so on. So I think, again, taking help from somebody that actually knows how to kind of facilitate behaviour is, of course, needed. And it sometimes feels like no, but we know the technology - we know the domain - but that doesn't mean you have the process to talk about it. That's why I love the folding example because the process itself, in that case, the game, solved it. None of the two components could solve it together. So I think, "How do we bring out the best of this?" and use kind of a structured way to do it. Right? And--
RVB: 00:10:22.263 Is that kind of what you're doing in the Innovation Labs and stuff like that, that you're doing with the Neo4j Innovation Labs?
SW: 00:10:29.142 Yeah. This is exactly what we're trying to do, basically, also trying to take the knowledge and kind of design that into a process, so taking basically 10 years of enterprise learnings and processify it because if we have a process that's repeatable, right-- the easier it is to repeat it, the better it is for the client if they learn it because then they can go find their own use case. They can facilitate themselves, which is a very good point there, because very often-- yeah, go ahead, Rik.
RVB: 00:11:03.502 No. Well, I mean, I think it's a great way of doing it, but there's also a couple of pitfalls to it, I think. And maybe the one that I've seen a couple of times - and maybe I'll just ask your opinion for it - is the fact that graphs are everywhere. Everything is connected more and more. And the temptation is always that we take on too much, where we're going to put everything into the graph. Right? And it becomes this humongous hairball of information that doesn't necessarily add as much value as you would hope it would. So I kind of wanted to ask your perspective on, how do you untangle that and how do you get there?
SW: 00:11:53.204 No, it's a fair question. Very often it's like you want to connect everything. It's a classical-- we see it in the customer 360s, one of those examples like, "But what the hell is the question you're solving?" Right? It will be a scenario. So the way I do this is I use this idea of convergent/divergent thinking. It's coming from any design-thinking process. Basically, it's about opening up, getting a lot of ideas, and then basically narrow it down by prioritising based upon the business value, the user need, and basically the technology. Right? Is it feasible to actually do this? And then you will have a bucket list of things, right, and be very clear of those. And this gives me also time to talk about one of my favourite formulas. Right? It's called 6:3:1. It's actually scientifically proven, which means it's not proven at all. [laughter] Sorry for that bad joke. But when you look upon ideas, right, if we have 10 ideas, 1 of these ideas are really, really good, 6 of these ideas are pure crap, and 3 are kind of lukewarm, meaning that your competition already is doing it, you're not going to get a promotion, and nobody would actually care. It's good to do it. It's decent, bread and butter. Right? So that's the way of thinking of ideas.
SW: 00:13:17.204 So very often we always go, "If I only had one idea--" but that's not the case. Right? You need to come up with a couple of ideas and then start validating if it's actually true because very often they're not. And it's kind of an agile process to kind of circle around that. And very often when doing these things, there is this kind of a great matrix to use about innovation. So it's called 70:20:10. It's very similar. But basically, 70% would be the core business. Right? This is not where you do innovation. So you have the core business. That's 100% of what you do. If you can make that more efficient using graphs, for example, and do it [in?] 70% of the time, that means you have 30% of money and time left that you can spend doing actually structured experiments. So the way I usually do it is I take 10% of those and just do stupid ideas because I don't know which one is going to work, but I need to test it. And that then becomes the 20. The 20 then becomes the new 70 along the road. Right? So a structured way of looking on ideation instead of, "Rik is super cool. So he has been at Neo for a long time. So his idea must be better." Obviously, that's true, or not. We all know the real answer. I don't want to make Rik sad now.
RVB: 00:14:42.022 [laughter] Hey, Stefan. I think we've covered a lot already in this episode. I'm hoping that we gave our listeners a lot of ideas on how you find that graph use case that is most valuable to your organisation. Lots of really, really good stuff there. We'll write it up. We'll blog, tweet, post about it. And I'm hoping to talk to you very soon again about the next step in this quest for graph value. And I think we're going to talk a little bit more about that very, very soon, which is how do you actually build the case for these graph use cases? So--
SW: 00:15:21.678 This is going to be awesome. Yeah. Looking forward to that.
RVB: 00:15:23.418 --[crosstalk]. Why don't we wrap up now and we'll be back soon.
SW: 00:15:28.593 See you later, alligator.
RVB: 00:15:29.211 Talk to you later, Stefan.
SW: 00:15:30.300 Bye.
RVB: 00:15:30.879 Bye.