 OK. I'm sure we can get started. So, the most important thing about Drew Brokawn to me, is it's your time, and what matters to me, is that you get the most out of the sessions that you go to see. So if this session isn't for you, you can leave, it's fine. I won't be offended. I want to make sure, you know, what's valuable to me is how many people are here at the end. If you do feel that this isn't what you expected, Ac ydych chi adael a gynnyddio chi ddaeth i'r ddaeth. Fy mod i chi'n gweithio. Ac ddweud yn fawr cymorth. Ac mae'n gweithio ar y dyfodol ac yn dddangos y Dwyplecom. Mae'r partidol y gallwn i chi i chi gwaith i'w dweud yma yn ymgyrchu'r proces dyma ar y dyfodol yn y gallwn gwybwysig. A ddweud hynny i gweithio i'w dweud hynny i gael... yw'r prospectau hynny. I'm Richard Jones, the CTO of a company called Invica. We're a digital company in the UK. We also have a couple of offices in Germany. Our position is we are a technical partner. We specialize in content, obviously, Drupal, as we are here, but also in commerce. What we're looking to do is work with large organizations to build partnerships and long term partnerships with large organizations to help them implement their digital strategies. As a CTO, what my role is, well, there are many aspects to my role, to be honest with you, but one of the most important ones is to ensure that we get technical delivery of projects to expected quality on time and on budget. So really, whilst I do lots of other things as well, delivery of projects is part of my remit, but this is the thing. How often do projects actually turn out as you expect? Very rarely. Pretty much never, in fact. There's always something that happens. There's always some sort of overrun. You're going to compromise somewhere along the way on one of those three aspects. So time, budget, quality are the three things we're working towards and something has to give somewhere when there's a problem. Normally budget, sometimes time, hopefully never quality. But all of these have to be, all of these competing forces have to work together and will have to be within acceptable limits before we get to a point where we feel that we have a successful project. Now, what you'll probably find me saying a lot of today is, this session is not about this. So, and what I will do is reference you to other places as I go through. Of course, I'll put the slides up later so you can follow these. But there's an interesting talk that I saw a few months ago and there's a link to all the details of it here, which is about why content projects fail. And there is literally a whole talk on why content projects fail. And as I said, there's a multitude of reasons and today I'm not going to try and go through all of that and I would advise you to go and have a look at this. Instead, what we're going to think about is what we do and how we behave when things do go wrong because they eventually do. So instead of talking about why projects fail and these sorts of things, I want to give you a little bit more of a personal story that I hope you can relate to. So what happens when a project gets into crisis? You've got a dev team working really hard. What happens next? Yeah, as a developer, historically as a developer, what happens, how do you react when something starts to go wrong? This guy, this guy comes out every time, right? So, again, historically, you do what it takes. You don't want to let a client down, you don't want to let the project down. So Superman Cape comes out. You work extra hard, you work late night, you get stuff done and you deliver. And that's how we all behave. No projects left behind. And that was sort of okay as long as it wasn't all the time. And every now and then, yeah, we get into a situation for the project where we just have to put that extra bit of effort in. And that was fine, but it's not anymore. And I personally, again, this is my personal story. Now I have to deal with 200 developers and I have to deal with multiple projects. I can't do this stuff anymore. I can't jump in and help. I can't fix the problem on my own. So even if I wanted to, I just can't. There's not enough time, there's not enough capacity and I'm not the one that has to fix everything. So this isn't a session about estimation. This isn't a session about waterfall versus agile. It's not about the no estimates which I'm very interested in. It's not about estimates versus forecasting which has been sessions on earlier in the week which I'd recommend you watch on playback. Instead I want to talk to you about a journey of discovery about something that I've gone through when I realised that the superpower part isn't going to work anymore and how I adapted and figured out what I could actually do to help the process of projects. The reason I'm telling you is that even if you're not running 20 or 30 simultaneous projects, you still, if you've ever had that tendency, hopefully some of what I'll show you today can help you avoid that situation before it happens. So as I said just now, there's never one reason for a project getting into trouble. There's never one unique thing. It could be a multitude of things. It could be bad estimation. It could be a difficult client to work with. It could be a developer sickness or any number of reasons. It could be development environments exploding. Who knows what it could be? And again, I'm not going to try and solve every problem for you. So what I'm going to do today is focus on what I believe are the areas of highest impacts that we can actually do something about. And the first one is what I refer to as unknown unknowns. Now, we often have unknowns in projects when we go through our scoping phases. And an unknown is generally something like, say, migration. So we know that there's a migration exercise to be done here. We know it's going to be complicated. It's coming from some legacy system somewhere. But we know that we have to do it and we know, therefore, that there's a certain amount of risk around that particular task. An unknown unknown is something that flies out at you in the middle of the project. Whether you're doing a waterfall project or an agile project, it's something that your product owner suddenly pops up and says, oh yeah, I thought you knew about that. Happens every time, no matter how hard you try. And these are the unknown unknowns. These are the things that threaten the project because they're the things you've not got time, you've not got budget and you're just not ready for. So we're looking to see what we can do with these unknown unknowns. And only, of course, the ones of these which we can actually do something about. The second thing I want to focus on, again, this is from personal experience, one of the biggest problems that we've seen in projects in the past is editorial experience. And it's not that Drupal's editorial experience is bad. It's just that the editors are the people at the end of the project that are people who are actually going to be using the system. And if they're not consulted at the right time or at all, then you get a great project, everyone's happy, product owners happy, clients happy, you deliver, the people actually using the system rejects it because they were never asked what they needed. And this is sort of my second thing that I want to address in this particular session was if you don't have that buy-in, then although your project is great for nine sprints out of 10, in sprint 10, you suddenly have a massive problem on your hands or even worse after the end of the project. So I'm going to take a step back and talk to you a little bit about our existing discovery process that we go through. These are a couple of the steps that we have. The most important one at the beginning is what we call goal definition. And what this is for is for us to understand the business and understand why this project exists in the first place. We call it the business value. So what we're trying to understand is what exactly are the things the business is trying to achieve? Is it trying to get more customers? Is it trying to get more traffic? Is it trying to make money in some way or another? Is it trying to get subscriptions? And these sorts of things, we're trying to understand the real reason for the project because that stuff doesn't necessarily come out in the specs and the stories that we get. So we go through that process and we force the stakeholders who are probably already quite well-evolved in how they're thinking before they bring someone like us in. So we need to take them back and say, why are we doing this? What's going on? And once we understand that, then we go through a couple of other workshops, specifically things like impact mapping, and we look at all the things they want to do and we see how those things map towards those goals. And if we find that there are things that they've decided they want to do, which have no relevance to those goals, then we certainly challenge those very, very hard to make sure that it is relevant and it's going to actually make things significantly better. So this is our traditional discovery. We do lots of interviews. We do technical interviews, stakeholder interviews, people around the business, not just the people that we're directly working with. And out of that, we get what you're used to seeing. I'm sure which is a product backlog in agile terms. Again, this is not a session about agile, but what we end up with is our user stories or cards in a product backlog. And then we go into our traditional... Again, I'm sure you'll be familiar with this. I think pretty much everyone is now sort of working on this agile methodology. We go into a two-week sprint process or maybe one week. We review that product backlog. We make candidates for a sprint. And then what we do is something we call in the example workshop where we go into much greater depth on those tickets before we go into a planning. So that's generally how we work. But ever since we've been doing this, I've always struggled a little bit with how agile story creation and Drupal fit together. When you're thinking about a product, it actually works. I think it works really well. But when you're thinking about a content-based website, sometimes I struggle to make the correlation between the two things. I find that that a bit of a challenge, definitely. I'm going to give you an example, a couple of examples here. So, again, story format that you hopefully will be familiar with. As an existing customer, I want to search for the most competitive product so I can renew my car insurance. So a traditional user story. Another one for the same kind of system as an existing customer. I want to log into my account so I can update my address. Again, standard kind of stuff that I would expect to come out of a discovery. This isn't a session about BDD either. And yet another thing. And I'll send you somewhere else to look at that. We've got a really good BDD reference that if you're interested in that stuff that I would recommend you look at as well. So these are typical stories that we would see coming out of a workshop that we would then refine in our example workshops later. And to give you an example of this kind of refinement, what comes out of the workshop looks about the stuff on the left. That's 20%, delivery costs for a small basket, less than £20 is three, delivery costs for a medium basket, more than £20 is two. But the thing is that stuff on the left there, there's still ambiguity. And you get to the situation where it's, okay, well, what happens when it is £20? Which way do I go? And these are the types of ambiguities that we find trip you up because it's not obvious which way to go and the developer has to think about it. It's suddenly in a block situation or you just make a guess and get it wrong. So generally our example workshops would be like that on the right where we go into much more specific detail to try and eliminate that uncertainty before we go. So the format of these stories again is like given describing the initial context on the right here, when describes the action and then describes the outcome. So again, that's as deep into BDD kind of stuff I'll go right now. So how does that stuff relate to Drupal? This is the problem. How does this relate to content types and fields and modules and all that stuff? And so what I've decided to add is once we've got our product backlog is to add a different discovery session which is what I want to talk to you about today which is what I call the content discovery. To try and fill this gap and I feel make things map better into Drupal. So the process we go through is once we've got our backlog we look through those stories and we figure out which of those touch content in any way because not everything does but many and many of them do. So we figure out first of all we put a fine filter through and say which ones of these are going to affect content. And then we go back in with the customer and we collaboratively we work together to build the content model together. And I'll give you an example now. So generally what we'll try and do and this is taking the example from that sort of insurance those insurance stories from earlier we start with a central asset what's the most important piece of information or piece of content that we're dealing with in this case maybe it's the customer and we work our way from there to all of the different things. So the customer is looking to get a policy so the policy becomes a piece of content. The policy is going to be about a vehicle of some sort so that's the piece of content that's associated. They may have claims, prior claims that are important for the process so that becomes content. We already have a story about the customer wants to change their address so we know that's content. What if they've got different family members if it's a multi-policy or something like that. And then what their outcome is is they want to find new insurance so the insurance product itself and the insurance product will be coming from one of many providers. So all of a sudden you've gone from a single content type to multiple content types. This is another example which is the reason I did the prior examples because this one's so hard to read but this is more of a pure content project. This is done for a, we did a premiership football club site and we started with the one at the top. I'll talk you through because it's hard to see but the one at the very top is the article. So the prime piece of content on the site is the article but everything else related to that so an article might be about a fixture or a game. A game, a fixture is going to have a team related to it. A team has players, the players might have blogs. The fixture's happening at a venue. The fixture might have other media, TV coverage, commentary, that sort of stuff. Of course there's going to be a result and a write-up at the end. There may be sponsors. So we literally start with something that sounds like it's going to be relatively simple and we work our way through a spider web of these are all the things that are going to spawn off of this central concept. And once we've done that process and again it's very collaborative so you're making sure that it helps people walk through the system and understand. Once we've got to that point, we go into a slightly deeper analysis of the content types. And I'll spend some time now just stepping through how that works. So this is the model that we use. Again quite small to see but basically the idea is that for each content type we walk through a methodical process and I'll walk you through it now. And the whole aim of this is to make sure that we don't miss something. This is to make sure, well, it can't guarantee but it can certainly reduce the risk of these unknown unknowns cropping up on us later because it makes us think of lots of different aspects of the system. So I'll start. You'll see the little diagram on the bottom there. Basically, let's go back a second. What I'm going to do is I'll work my way from the left and take these vertical slices all the way through to the right-hand side. So starting off, we've got to figure out what our content type looks like. Everyone's very familiar with this, of course, but we have to go through the detail. So first of all, what are the fields related to the content type? What types of fields are we using? Are they plain text? Are they limited in some fashion? Are they media and so on? But this gives us the opportunity to look at the validation. Again, not coming at it later, but thinking right now for this field, what's the validation we're going to use? So we capture all this stuff as we go along, making sure that we don't miss something critical, and getting everyone into this mindset that we're thinking about content, we're not thinking about the site, we're not thinking about the design, we're thinking about the core content of the site. So we think about the fields, we think about the validation, we think about whether this is actually a taxonomy or how these things relate to each other, and then we think about the relationships between this particular piece of content and all the others. Now remember, we do this process for each content type to make sure that we have it covered and maybe we'll loop through them a few times. The next one is thinking about the source. My experience, migration causes more pain than anything else in a project, and that's, again, not through Drupal being particularly painful, but the fact that data comes from all over the place, it can come from legacy systems, it's in formats you don't need, so I can see people in the room that I've worked with that we've been through this pain together. So we think about the source, we consider it now, we consider it at the beginning. Is it coming from a legacy system? Are there media assets we're dealing with? Have we got a dam or a CDN or something else? Is the data coming from a third party? In the case of that football example, a lot of the data comes from a third party that's centrally managed by another organisation. Or is it manual entry that's going to happen? Because that's okay as long as it's not too much. Or are we talking about user-generated content? Is this not migration? Is this something that we're talking about in the long term? So all of these things, now I don't pretend this is exhaustive, by the way, I modify this quite a lot. Every time I find something I missed, I go back and redo this. So we go through all of that and understand where all this content's coming from. And as I said, one of my main goals here is to think about the editor experience. We're thinking about what's going on with these editors. Now, we've had some great examples over the years where we've built a lovely Drupalite site and then we found out that the customer, the end-user editor, needed to be knee-deep in mud in a field when they were creating their content. We didn't know that. We didn't know that at the beginning and we'd created a lovely, paragraph-based page creation system which we thought was great. They thought it was great. The people in the fields, it's pretty tough for them. So we ended up in that project. We ended up creating an alternative edit system. But if we'd have thought about that up front, then maybe we wouldn't have got ourselves into that situation. So scenarios. What are the scenarios the editor's sitting in? Don't assume it's just someone sitting at their desk. We think about things like groups. Are there any groups and permissions and these sorts of things that are important here? What are the expectations of the editors? Again, this comes out in stakeholder interviews. Are these editors used to using WordPress? Are they used to using some legacy system where anything's an improvement? Or basically what are they used to? And what are we giving them is going to be different? Again, it doesn't mean it's better or worse, but let's understand what their expectations are. And what devices are they going to be using? Again, we've worked with media companies where their expectation is to be able to use a phone and be out filming a protest, upload their images and write their story on the spot, have it up there. So we need to understand that stuff. Nope, did I miss one? Workflow, okay. So next one, workflow. And there's a few aspects to this. You've got the obvious things about workflow like signing off content. Does someone need to? Have you just got a simple draft in live? But we also, in this aspect of it, think about caching because workflow is great, but caching's part of it because if we don't consider caching properly, then someone publishes a page and then it doesn't go live when they want it to go live because the home page is cached. So we think about caching here. We think about content governance and we think about lifecycle and how we get that content out. And then we think about translation. Is translation going to be important? Not every site requires it, but if it does, how are we going to do it? How many languages are we supporting? What's our mechanism of translation? Is someone going to do this stuff manually or are we going to connect with someone like Lingatech? And what's the workflow there? What happens when the original content goes out of date or is updated? What do we do with the translations? So again, considering these things now, not asking later because hopefully you've got people in the right mindset. And it's only then that we start thinking about is this piece of content something that users are going to interact with? Are they going to do social sharing, commenting, rating or anything like that? So anything that a user might do to engage with content, then we think about that next. And then we come back to this again. We come back to the business value. No, this doesn't always apply, but we was asked anyway. We've got the whole why does the site exist conversation happening at the beginning. So it might be that an article that they create has to perform, has to meet certain KPIs, for example. If we don't ask, we don't know. So is there something they're measuring this content either through analytics or something else so that we can understand what's going on? Is there any access control going on? Is all of this content free or is there some sort of visibility? Have we got a paywall? Have we got any sort of restrictions on this content that might be important to us? And we keep going. Personalisation is the next thing we talk about. Is the content we're looking at here going to be personalised in any way now or in the future? Because it would affect how we go about building the site. So who are the persona that we're targeting this at? What are the content variations that might affect it and what are the rules on this visibility? Where does this stuff appear? So again, you're just working through methodically, figuring out what matters. And the last one is destinations. And, well, this is probably the most important. But I've spent a lot of time talking about just this one part over the last few years. And the reason is that traditionally, we thought like this and we have done for so many years. And what you'll see and you saw from Drew's keynote, the future direction of Drupal is decoupled. And the reason for that is because there are so many other possible ways that content can be consumed. All of these different places that... What you're doing, you're sending out that same content. You're sending it out to different devices and you're sending it potentially to places you don't even know. When we start to expose content through APIs, as we now can with Drupal 8, we don't know exactly who's going to pick that content up and what they're going to do with it. So we need to take this stuff into account. And what is our expectation? Are we expecting to build a voice UI? Are we expecting this to be integrated with a food mixer? And we have seen that example where a food mixer that's internet connected that reads a recipe. There's no point that recipe being a giant lump of WYSIWYG content. So the food mixer is expecting step one, step two, add this, add this, add this. And we will structure our content accordingly. So considering absolutely everywhere this content's going to go, things like mobile apps, of course. Are we going to be using AMP or Facebook and how are we going to handle those sorts of things? What's the content going to look like in search engine? So all of these different aspects of where that content's going to end up are vitally important to us. All that, I forgot one, email. Cos we don't want to have duplicates of our content. We want to be able to reuse this content in lots of different contexts. So it's important to try and think through. And what we do with this model is we're actually saying to the customer, have you thought about this? Have you thought about this? Because they won't necessarily have gone all the way through that thought process. And we don't want them to pop up at the end and go, oh yeah, you know what? Actually we need to send all this content to our mobile app that you know nothing about. Oh, and another one. Had this one come up the other day, that's why I added it. We're building a brand new site for someone, but actually they already have feeding content on completely other sites that we're nothing to do with and they need these specific URLs that deliver the specific volumes of content. So is there a legacy system that depends on what you're rebuilding? So that's a deep dive into that whole process. And again, what it's about is thinking through the whole process, trying to assist and really acting like a giant checklist of have you thought of everything and that's why I keep modifying it. But this is now important. This is the part of engagement with the editor. How do we validate all of this? How do we prove that what we've just gone through in these workshops is going to work? We need to be able to get this and prove it. What we're suggesting is that you can use these tools. You can use the tools we've already got to validate the content model. There are a number of ways of doing this. One of them is what's just been released as Reservoir. I know there's another version of this sort of headless version of Drupal. But this is just Drupal. It's just a Drupal distribution. But what I find interesting about this is it subtly modifies some of the way the admin works so that it feels more like a content modeling tool. Now there are other ways to do this. It doesn't have to be Drupal. We've spent some time, for example, investigating gather content, which is a SaaS product, which has a really lovely workflow tool in it. And that allows us again to model content potentially before we build in Drupal. So what we can be doing here or in gather content or somewhere like that, we can build our content model quickly. Now we all know that we can throw together content types in a couple of hours. You're not actually building a site at this point. You're just building your content model. So the idea of this is that we go to a proof of concept very, very quickly, which maybe could become your real site. Who knows? It doesn't matter. But we're trying to do it in an agnostic way, basically. So we're creating our content model and then we're trying it out. And we're trying it out with the users, with the editors, and saying, look, even though you don't have a design yet, this is what it's going to feel like to use this system. This is what it's going to feel like. This is how the content all relates to itself. And if we get an understanding at that level, then it sort of avoids the big bang. It gets the stakeholders really involved. And no one should really have to go through that sort of big reveal at the end. And what we're doing is we're taking the editors and these key stakeholders on the journey with us so they understand why we've done things the way we've done. They don't have to retrospectively try and get themselves into our headspace and say, oh, well, that's the content because of this and that's because of this. In this case, we can talk them through and get them to buy into the whole concept, basically. And we can help them understand if they're coming from a world where, well, our previous system just had a big whizzy wig and that's how we did it. Why are we changing that? We like it. Because they don't necessarily understand about where we are now that we want to be reusing content to all these devices. So we can help understand these new paradigms and get this sort of information across. So you're helping these site owners by walking them through the whole process. You're helping them to build this new vision of what they're going to get. Because at the beginning of a project, everyone has their own vision of what they're going to get. And every stakeholder in the room probably has a slightly different vision. So what we need to do is to step through a methodical process with them to help them understand the constraints we're working with, what the options are available to them, almost coaching them through the process rather than dictating. So that we can help them build a combined vision between them, a shared vision between them and between us. So that when we get to the end of the project, there's a... Not a sense of disappointment, but a sense of satisfaction that we've all got to the end of the journey we were on. OK. So how does this help with estimates? That was the point, right? So the reason we do this is that I think the methodical approach, a checklist kind of approach, and maybe that's just my personality type, going through a very structured approach. I don't have to do it in order. We can jump around, but as long as we cover all the ground eventually, then we reduce the risk of these unknown unknowns jumping out of us somewhere through the project, whether it be beginning, middle, or end. Because it doesn't matter what your methodology is. It doesn't matter whether you're doing a waterfall project or whether you're practicing agile methodology. If it's waterfall, then you go into this change control mode. If it's agile, OK, you might be able to swap something out that takes something out of the backlog, put something back in. But you know what? Either way, the stakeholder or the product owner is going to be a bit disappointed. Change control is just a conflict and an argument. And even the agile methodology, even if they fully buy into it, they know they've got to lose something to get the thing they want because we didn't discover it early enough. So, for me, this is really reducing the risk and actually making sure that the partnership relationship we want to build is protected because if we don't want that conflict, no-one wants conflict. So I think a full scope that's more than just the stories gives you a much better foundation to build upon for your project. And this is another thing I could seem to keep saying, but we talk about business value. The content is the value. It's not the technology. The content itself, that's the value. So let's put it right in the middle. Let's not think about it at the end. Let's put it right in the middle of the process so that that's where our focus is. That's our value. So I'm going to leave some time for questions, but I just want to do some sort of action points, maybe some takeaways for you. My first one is keep doing it your way. I'm not asking anyone to change what they do. I'm not asking anyone to change from their methods to an agile method or to do different types of discovery. That's not what I'm here for. I think you're probably doing it fine. All I'm trying to do is add some depth to your discovery process. Our discoveries are actually quite long on projects, but I'm trying to make them even longer because I think it's better to spend that time upfront figuring stuff out than, again, getting to that point where you're in a crisis or you're in a conflict with the client. There's no reason you can't do this rapid prototyping step. All I've presented there is reservoir as an example, gather content as an example, but you can do it just from a pure drip late site. All you're doing is that part of the build that is relatively quick, relatively straightforward. There's no reason you can't do that. Get that in front of the editors and save yourself that pain later. If they've got some sort of objection to the way Drupal's editing experience works, best know now, best work on that now before or potentially adapt. We use paragraphs a lot for our builds, but it's not for everyone. Sometimes we use media embeds into a WYSIWYG. It's okay if that's what we need to do. So make sure that we've got that understanding. Make sure that you've got that buy-in and don't traditionally what Drupal developers and myself included tend to do is say, this is the right way to do it, and then sort of steamroller that through and not really taking it into account the person who's got to do the job when we've gone. The other thing here, I mean this whole process came about, as I said at the beginning, because I couldn't do what I was doing before. So I had to find a way to have the biggest impact for myself personally that wasn't me getting my hands into code, because that was, again, not scalable. So it's very much about for yourselves looking at your own process, retrospectively looking at projects. What went wrong here? Because although there's lots of things that went wrong, figure out what the things that are happening a lot or all the things that caused you the most pain. Measure and learn and figure out what your highest risk is. So for me, editor experience and unknown unknowns came out as a top for you. It might be, I don't know, maybe a consistency of estimation might be the thing. And then you can address that. I haven't answered that question here, but it's identifying what's the thing that you should focus on. Not trying to solve every problem in the world, just focusing on something. That's it, actually. So we've got some contribution sprints coming up tomorrow. For anyone who's still going to be around tomorrow, hopefully you'll be able to join in. And there's a session evaluation. I'm not quite sure how that works. I think that pops up when the session's over. But yeah, I just wanted to make sure I left a bit of time at the end for any questions that you might have. So if you do have questions, there's a mic in the middle and I'll do my very best to answer them. Thank you. Thanks. I just want to make sure this is on. Great session. I have a couple of questions, so I'll try to narrow down two areas to give you some context. I've been exploring doing a part of Discovery using site building somewhere to what you're looking at. So the first question I've got, with this content modeling approach, this is really looking at, let's say, the architecture of the project, but not necessarily, let's say, the content editing portion. Or are you exploring that? And can you give us some more detail about that? Yeah, and when you look at that, it sort of looks a bit like data modeling or data architecture, but actually no, I'm thinking much more about implementation and how things connect to each other. So using doing this sort of live in Drupal actually is something that we've talked about as well in that rather than sort of going through it as a sticky note process, checking you through, you could, with the right type of group, just go straight in and start building content types in Drupal. I don't know, I've never tried it, I don't know whether it would work and I think it would definitely depend on the group if they've had some good training beforehand that could work. But yeah, I mean, as you probably see, that the editor experience is key to all of it. So making sure that we're not making arbitrary decisions about using bricks or paragraphs or stuff because that's not the important thing, the important thing is how it fits together and if, like taking that football example, if I'm making an article, I need to very, very quickly find the opposing team and associate it all together. That needs to be really quick. And in fact, that project also had a different, one of the scenarios. They need it on match day, they need a special mode so that they can really push content quickly during a game, otherwise they're not the ones who reveal the goal score. Everyone else gets there before they do and they don't want that. They want to be the first people to break the news. So again, that's the scenario, match day mode and this sort of thing is really sort of interesting way of looking at things. And then so the second question and this is someone related. How much collaboration with the customer do you envision in this process? Is it a manner of taking a first draft for a view? How many is it? And the related question to this, do you see this more practical to certain verticals or for certain kinds of customers? Let's say more technically proficient versus a brand new to the Drupal Sphere. So this has to be done really face to face. This is the sort of thing we do in a room with preferably all the stakeholders because everybody has their own little piece of the puzzle and we need to bring those people together, get them talking and we're really facilitating. We're saying, look, we'll nudge them in the right direction every now and then but what we want them to do is to be figuring the stuff out that's right for them. Oops, let me do that, sorry. So yeah, it's very much a collaborative process and it's not a technical process but it does require some understanding of how we're doing. And one of the things that we try to do actually is to get some very sort of base level Drupal training done prior to these sorts of things. It doesn't always happen but we would like to be able to do that so people understand our terminology and they understand that certain things are actually quite easy and therefore what they've got us to do is the hard part. So yeah, if you've done that, then it does make a lot of sense to even do it live. I think it might work in some scenarios. Thanks. Thank you. Thank you. Thank you, very good session. My question is around the actual workshop and selling of the workshop. So you mentioned that your discovery sessions are actually quite long at the moment and you want to make them longer. How do you sell that? Well, firstly, how long are they generally compared to the project? There's a rule of thumb, Miles, was it at 2010? I don't know. It depends on the project, maybe not at 10% of the project. Yeah, so we're not selling individual workshops. I'll repeat that. Sorry, yeah, for the mic. So that was 10% of the project. Something like that. It's not fixed. Generally, what we look at is the complexity of the project, how many stakeholders there are, but we're not necessarily selling. You can pick and mix this session and this session. We're saying, look, we need to have two weeks or four weeks or whatever. Do you find that clients go for that? It's a very difficult sell I've found to say to people, OK, we know what you want and now we've got to find out what you want. Yeah, when it's difficult is when they've already been through, I took a few slides out about this, but when it's hard is when someone's already been through a discovery, like a UX discovery, where you've got a creative agency or a UX agency involved. And what we have to do then is we still need to do the discovery, but they've already been through it and they don't want to go through it again, but we still need to go through it. So actually what we have to do then is slightly reframe it and maybe don't do some of those steps, maybe don't do the stakeholder interviews because they might have got to the point of having the product backlog internally or through another partner. If that's the case, then actually one of the reasons this type of workshop exists is because it's something they definitely won't have done yet because it's not something that you would do in a UX experience. So you're basically taking the backlog and bringing it on to the next level. So in that scenario, no, it's not 10%. You're saying, look, okay, you've done all this stuff. We would love to do it with you, but we understand that, yeah, it's difficult. It's difficult to convince anyone to do the same thing again if it's like a five-day discovery. Sorry, I'm hogging questions here. Would you turn down a project or walk away from a project if they then refused? Yeah, the risk is too high on a project. If they won't engage in discovery at all, then yeah, the risk is very high. I mean, we wouldn't just point back and refuse. We would be talking to them and explaining why. But yeah, the risk of going into a project with a backlog that someone else made with no consideration to this stuff, you're just setting yourself up for failure, I think, from minute one. So yeah. Thank you very much. All right, anyone else? Okay, well, we've finished a little early, but that's okay. There's a couple of people around. If I can get them to stick their hands up. Nick, who's sitting at the front, is one of our trainers on Drupal, and he's very much an advocate of actually building it live, and this might be an interesting conversation for you to have. Yeah, so if you've got any other questions, you want to come see me afterwards, that's absolutely fine. But thank you very much for your time.