 value mapping, and I'm not, word is out in the world and how much it is a product of, you know when you really get working something inside your family or your organization and you have words and names for things that seem perfectly up to suit you and then you talk with someone who's not from your company and maybe look at you like they're crazy or you have to actually explain yourself. So value mapping is something that we talk about a lot and at Open Strategy Partners it's kind of a core tool to what we do, we can't really work without it at this point. I'm going to tell you about that and how we use it as a tool to build understanding within organizations and between our organization and the people that we help and how you can use it too and why it's a tool that I think, well we're going to be talking about it a lot more in public and sharing how we do it so that other people can get on with exactly that. I co-founded Open Strategy Partners in 2017 with Tracy Evans. Tracy is a hotshot MBA, our chief strategist and smart person at our company. She's the brains. I'm the pretty one and we do strategy communications and marketing for technology organizations. We have a special focus on open source and developer communications and I think our core function is to translate between complexity and business value. We recognize that there are a lot of people in the world who have had great ideas and they've built a team to realize those ideas and those ideas are really valuable but they have a hard time communicating them and especially if you're highly technical it can be difficult to talk with the marketing person who might have the budget to buy your thing. So we'd love to get involved with those kind of problems that we talk about how we help you communicate, the value of what you do to connect you to the people who need to know about it so that you can grow and in our case growth might mean helping a company spread its open source solution to developer communities. It might mean a partner program. It might mean sales. It might mean all of those things. Essentially Tracy had an experience and I think it's pretty common that when I'm trying to choose a new technology or learn something I hit a lot of vendors who might use a lot of buzzwords and they might use a lot of jargon and I don't know what is behind that and different vendors are using different words and if I'm trying to compare you know Adobe and Drupal and Type 03 and Sitecore and I don't know they're not telling me what they're really talking about and they're not telling me why I should care about it necessarily and the language changes all the time and what I actually think that I need to know is I need to know what features you have and what benefits I have from those features so that can be really really frustrating and even with highly complex technology I think because we operate in the open source space especially I don't think that I should trust things that I really don't understand. Now understanding might mean I get someone I trust to help me. I get an expert whose expertise I trust to explain things to me but I need to trust and I need to trust that your solution is going to help solve the problems that I believe I had and the only way that I think that I can have trust in your solution is that if I understand what your product or service is and I understand what it does and I understand that the value that it delivers to me so these are the three key concepts around clarity and the value mapping that I'm talking about today. So what it is and what it does and what value it delivers. One of the concepts that I came into our company with is my idea of authentic communications, communications that's compelling and accurate. I had a few thousand conversations with people from agencies and a few more thousand conversations with developers and people in our communities and in our industries and I really, really think that you have to understand what people want and need and the problems they face. And you have to be very, very clear about your communication. You can't, selling vaporware is very risky. Talking nonsense and using jargon is very risky. And if you do this well, you can build trust with people. So the value map is what we use to create accurate content with clear and consistent language and that's what I'd like you to be able to do with it. And then we do other things, we do strategic stuff, we do writing, we try and choose good words and put them in a nice order. But you need to be clear about what your thing is, what it does, and what value it delivers. In terms of how we work at Open Strategy Partners in the context that we put the value mapping into, there are classic marketing shaped things, target audience, buyers, journey, editorial plan, and so on. And we mix that with a couple of other things that we feel are special out of the open source perspective. This trust and vibrancy signal idea came from, how do I choose which Drupal module to use if there are ten of them that solve my problem? And we looked at that space for a long time and came up with a series of exercises to look at, especially open source projects and we're now adapting them for other things. But how do I really understand what I'm choosing? How can I project as an organization, as an open source project? How can I project that I'm trustworthy? Most of the rest of this stuff is marketing and it's not a mystery or a secret or anything special, except that I think we put it together with a particular attitude and a particular domain knowledge. So today, I'm going to talk about how we start with value mapping and I'm hoping that you'll be able to start with it as well. So and of course, if I'm telling you about a tool, I need you to tell you what it is and what it does and the value that it delivers. And because our company has a very exciting color palette, I hope that's legible. So, and I don't believe in reading slides, but these are carefully thought out definitions. So the key thing that you need here is we're going to boil out value statements as a sort of atomic unit within this idea of you have a bunch of words containing everything that your product is and does and the value that it delivers expressed in words. And having all of your stakeholders, technical in business, having your external consultants, your communication company, whoever it is, having everyone involved in creating this means that everyone is on the same page about your product and your organization and your goals and we've seen this with clients help them become better businesses, which was an amazing and somewhat surprising outcome of, but having conversations outside of your silo and getting the salespeople and the designers and the developers to all talk about things in the same way. Turns out to be very, very valuable internally before you start doing any communication externally. So we're trying to consent this building and understanding if it's a very technical thing, helping the less technical people, helping the business people understand that can be really, really valuable. So you get a single source of truth using a grade upon language and this living documentation you can then describe, position, talk about your product. And it doesn't matter if you're creating a sales presentation, if you're creating a sales battle card, if you're going to a developer conference and doing a presentation. If you're blogging, if you're making a paper brochure, you have a place to go to have the agreed upon vision of what your thing is, does, and the value it delivers. And it turns out to be really, really valuable. And it's hard and it's a lot of work. But the idea that you can then have, and I have a slide for this later, but you can have sales pitches that are fact based, right, is incredible. And how many of you have experienced the sales teams that weren't purely, you worked at Accus, you have to put your hand up, you know, and then you have young, enthusiastic people who are trying to make the money that we need to build the technical stuff. And they're going to tell whatever story they need, right, and that can be really, really frustrating to talk with that person, right. And at the same time, a really beautiful, I find it really beautiful, it solves the problem. Developers and technical people down within organizations, solving these incredibly interesting problems. We lose touch, sometimes, of what it is that we're delivering and why we're doing it and who we're doing it for. And this actually builds a connection. And I'll try to remember to talk about that a little more in a few moments. So we try to collect every feature, every thing that makes up your product, every atomic unit. And the first exercises we did in value mapping were around CMSs. And we discovered that CMS is easily made up of 700 individual features. And from drag and drop photo editing to spell checking to supporting left and right and right languages to FTP upload to whatever it is that a CMS does. And so that was an incredible lesson in thinking about complexity and how to deal with it. And then, so features are generally the things that we talk about as technical people and think about as technical people, just as a cliched, as a generalization. And benefits are generally businessy things. You know, improve ROI or improve operational efficiency or help me sleep at night. And the features are generally delivered through sometimes we call it a workflow, sometimes we call it an activity. But a feature delivers its benefit by being part of an activity. And an activity is a benefit. And each of these can belong to multiple groups. So I want to try and give some practical examples of this because I think the first person in this presentation got a little bit abstract, a little bit quickly. One of our clients is Sulu CMS. And if you're interested in a really different perspective on what a CMS can be, Sulu CMS is full stack symphony, developer only, no configuration in the user interface at all. So really the complete opposite paradigm of how Drupal tries to empower everyone through the user interface. But it's really, really beautiful. It's really appropriate for certain kinds of solutions, you know, sticking it on top of complex business logic and so on. So Sulu CMS, hey, the benefit here is you have a great developer experience. If I have symphony developers, they can step up and use that thing because Sulu is pure symphony. That's really great for onboarding. It means I know how to hire better. That's great business experience. And the developers who love working in symphony, the feature, in this case now, note this example shows us straight away that a feature doesn't have to be a technical thing. It can also be a business, can be a business aspect or a fact, like the fact that it's built in full stack symphony, we call that a feature. So it's delivered through system architecture that's pretty smart on top of symphony and a great developer experience. So great developer experience by using full stack symphony. If I'm an agency using this and I'm trying to hire people, I can already use this sort of language to help find people and help talk about what it is that we do in a way that might be attractive to some colleagues. There's a really interesting thing that they do. You can only create the back end and only create the interfaces and so on writing code. And you don't have to write any boilerplate theme code because they have all these predefined and really, actually really beautifully designed interface elements. And as long as you write their standard space code, it generates the UI automatically and it's a great user interface. And so you could even talk about this as part of the developer experience because it makes a great UI and that's really satisfying. But that's a couple examples of how we try and put these things together. None of this is finalized copy. None of it is automatically marketing materials, but it gives us things to work from. When we're working with things, it looks a lot more like this and we can end up with spreadsheets of hundreds and hundreds of rows trying to slice and dice and cut things down. And then we'll often use a sort of an auto-generated concatenation of the statements before we get to something that we think is usable and that's still not beautiful marketing copy or anything. But we have an agreement about the fact that our CMS, whatever it is, supports UTF-8 means that in the end we can provide a great authoring experience for clients around the world. And then maybe we need a campaign about internationalization. Maybe we need it about building multi-site installations for global conglomerates, whatever it is. That's the sort of thing that we're aiming at and that's how it looks as we are doing it. So each of these value statements, as I just described, we stack those up and end up over time. We'll usually group them and make smaller areas. In the end they come together to make a positioning statement. So you can already see there's a hierarchical aspect to this. We have a lot of features that get delivered by a smaller number of activities that deliver a number of benefits. And then that's all contained within these statements and we collect these statements and we start to position and we can group them depending on what use case we're making and so on. So we can create the positioning, sort of the essence of what things are about, and then a product like DDEV ends up being, in DDEV's specific case, there is a local development environment. And we have been working with DDEV on and off for the last couple of years and it's been really fun and interesting to work with them. And they have put up with multiple iterations of our process along the way. Thank you, Steve and team. DDEV has DDEV local. And so we have a highly developed way of talking and thinking about the local development environment and how we have promoted that and spread that to other open source communities has been really, really fun. And then product C might be DDEV live in this case and we've created a series of statements and ideas about what's great to use DDEV live as an environment and there's a secret project that might sit in the middle of them in the future that we're also talking about. So each of these sub-products within the platform vision, the platform vision then also has benefits and things it delivers because it is a local DDEV to live deployment platform. So then we might create more things and end up talking about the whole brand. And we can pretty much do this ad infinitum as the complexity needs. Here's an example of the pre-final how we took. So you have to imagine that for every feature, there's a value statement and for every activity, there's a value statement and for every and so on and so forth. And then we keep boiling and boiling and boiling and then we try to find how to address, how to think about ourselves most of all. So we know how to talk about our, we know how to then improvise and talk about whatever it is that we're doing. So in the case of DDEV, here are different lengths of talking about this concept of a DEV to deploy platform that I really, really love. And then who we're addressing, the need, the value they deliver and how you're doing that. And this speaks to another structure that I like to use a lot in communication. Once you know who you're talking with, they've always got a challenge. There's always something that you can give them and you can always talk about how you deliver it. So here's like a final stage application of a highly, highly developed value map that we did with DDEV. I'd like to talk about the process a little more to help you to be able to do it yourselves. And then I have a couple more examples of how this gets expressed in the wild. When we are going to start with a client and if you are going to start thinking about how to do this for yourselves, the first step is to go out in your industry and look around who's the competition and how are they talking about what they do. And especially the things of course that are a direct, indirect competition to what you want to offer. So what are the keywords that they're using? What are the concepts that they're using? And I'll give you a hopefully a relatively practical example of why that's important. We had a client that wanted to position their solution against Adobe Web Experience Manager and we had to decide, we made a decision that Adobe was for the target audience that we were going after which was sort of enterprise marketers, Adobe was a market leader. And then by looking at Adobe's choice of language and keywords that led us make choices about what we called our categories and how to build content later that would come up in using the style of Google search that Adobe was teaching people to use, like the choice of words that Adobe was using and the choice of terms and how they grouped features because we figured we were a market follower and so if we could get in in position two or three in results when people were looking for Adobe style things, that helped us. If you want to define your own niche, if you want to stand out, if you want to whatever all that SEO stuff follows from there. So we need to understand how our industry is talking about what it is that we do and we collect those. And then looking at individual competitors and individual products, we also study really, really carefully what the competition talks about in terms of the features that they offer and the benefits that they offer and then we can compare internally really usefully what it is that we do and this can already, I think it's pretty clear you can see this can already help you inform your product roadmap or your prioritization. For example, Adobe Web Experience Manager talks a lot about integrating with the Adobe full publishing tool suite, right? And which is completely irrelevant for Drupal. So who cares? So that's clearly the bottom of the list in terms of building communications and marketing around that compatibility because we're never gonna have it. So we look at the features and benefits that other people talk about and then we start to create a list of benefits that we think we offer, activities or workflows that we think we have and features that we have and then when we as OSP come into a client, we organize one or more workshops and we're very, very careful to have them to be mixed stakeholder groups. So technical person, designer, business person in different mixed groups. We've done this with individual interviews. We've done this a few different ways. It turns out that the small to medium group of mixed disciplines really, really helps sort of inspire more thorough thinking and clearer ideas and things that I, for example, wouldn't have thought of on my own. And we collect the features, activities and benefits in a mind map format that kind of looks like this. So basically any benefit, we put it in here for this workshop and then we start putting activities around them and then the features that deliver, that go into delivering that benefit. And this is the format that we use. It's not logical for any other way that it works. Well, we use a sort of an online canvas tool to do this. We've gone through a couple. We're using Miro right now and it's really, really fun and beautiful. So this is not strictly an endorsement but it works pretty nicely for us. So we put out the benefits and you can look at if you're marketing yourself already. Here's a way to think about it. What benefits do you tell people that you offer? And if you're telling people that they're gonna benefit from you, can you back it up? Can you back it up with facts? Can you back it up with technical details? And this process, you could say, hey, so we offer X, Y or Z piece of mind. What do you mean you offer piece of mind? Well, we have automated backups and then the technical people can tell you the things that go into having automated backups and then that means that you can actually talk about how the CTO can go to sleep at night because you're automated backups and so you have a much more factual conversation and we feel that that really helps us build smarter marketing communications as well. Alex, I hit the... I did the thing. Yeah, just leave your finger up here. Thank you. The corner that goes to sleep is the dumbest idea ever. So, let's look at what... Oh, it's because Alex has scrolled the wrong way around. I see. So I was talking about typical benefits are often business-y flavored. Improved ROI is a classic. I mean, if you are a for-profit business or a business that has to break even or whatever, basically returning investment is gonna be in there. Scalability and efficiency come up a lot. Ease of use is great for anything that's user-facing at all. Productivity, consistency of delivery and so on. So benefits. Then the questions that we're asking are, what gives me this benefit? How do I get this benefit? What goes into it? Does it contribute to it? And these workshops, when we've done them, they take a few hours each over the course of a few days and we collect then something that looks more like that, but maybe even bigger depending on the size and the scale of the product that we're thinking about. Now, I came up with this slide late at night and I thought it made a lot of sense to me at the time and I just want to sanity check this with you. And to see how I'm doing so far with the room. Every feature, every individual technical thing in my product delivers, goes into one or more benefits and it's delivered by an activity. Does that make sense? Yeah. Yes, okay. And every benefit is made up of a lot of features that are delivered by activities or workflows. So therefore, an activity delivers benefits as a collection of features doing their individual things. Right, so that's the logical flow. For me as a communicator, here's the key concept. If you are a developer or technical person and you're working and thinking about the individual feature level and we know, all of us know, but I can tell you, because we've done a bunch of research and a bunch of actual industry interviews, grassroots marketing, developer upwards marketing is a huge part of technology choices. So as much as we think we need to talk with the CTO or the C whatever, or the CMO, if a developer wants to use it, well, if a developer doesn't want to use a tool, then you're never gonna have it in your organization. And if she does want Slack, she is going to come and bother you every day until Slack happens, okay? But as a developer, if I'm trying to convince developers to try or use my solution, or if I am talking with a technical person about my agency and I want to convince them that we're good enough to work with them. A person who thinks at this level, looking at the activities and the business benefits, it means that I as a technical influencer, I can have a smarter conversation because I can tell the business role what they get out of it, right? But I know it because I've checked the facts. And if I'm a sales person and I'm trying to sell a decision maker, if I'm trying to sell someone with budget what we do, I can have sales, I can prepare sales materials where I can have sales materials prepared for me where I can talk about real benefits that are really, truly good for someone else's business and I can back them up with a set of workflows and activities that are backed up on a technical level so that I no longer am selling vaporware and I no longer have to make things up and I can have factual sales calls and we create content for business personas, and you can too, at this level and we know that it's backed up. So we might make an executive summary video that is five minutes about what we do and catch someone's eye on YouTube and they watch it and they go, hey, I saw that so-and-so does this thing. CTO, go check it out. And the CTO delegates and their junior or senior technical person goes and looks at this level and comes back and says, hey, yeah, that thing that they promised on YouTube in two and a half minutes, it looks plausible, let's try it. And that's the style of, so that's the two directions that we build communications. Sort of, there's other stuff in here and not every benefit has to be business only, obviously, talking about DDEV local as an open source tool, the benefits go to developers as well but this is the conceptual model that I use to create communication. So let's talk a little bit about how we use this. You can use this set of facts, so you end up with facts, you end up with business intelligence, you end up with technical information, you end up with a way to string it all together and agreed upon language. You can use it to build communication marketing strategy and build your campaigns and then target them. All of this can be sliced and diced by personas, obviously, so you can make targeted and smart conversation and then, so content creation becomes huge. What do we blog about? What do we talk about at conferences? Do we, you know, what brochures do we do? Do we do these as landing or product pages and so on? Like, how do we design our website to highlight if we're selling to this persona and that persona? How do we build the website and what do we push forward and how do we build that experience? And then, clearly, you can do a value map as a bit of competitive research and you can start to value map the competition products and decide where your product is going to go, what sort of road map is gonna have, what sort of planning you do. All of this can go into it. So, let me just jump back one thing. I actually had something written down here. Right, so marketers really love this level of stuff. The communications team, this helps us make plans about what to write and how to write it and then the technical teams can also use this same set of facts to decide what are we gonna do next, what are we gonna prioritize and so on. And frankly, you know, at this level, I can use this information to write an investor pitch deck. I can use it to write a quarterly report. It's pretty powerful and I feel it's incredibly empowering to have a factual base to what I'm doing. It's no secret that Robert Douglas is my best friend and PlatformSH has a really flattering, nice implementation of exactly what I'm talking about. This is platform, platform is not a client of ours. It's just that guy who used to have the beard is a friend of mine and we talk. PlatformSH, on their demo page, they have feature videos, right. How to install Drupal with a PlatformSH CLI is a feature video. You can install Drupal, that is a feature, that's a thing that Platform does, right. And then they have, they call the workflows here. How do I onboard new developers to my team is clearly a collection of things that Platform does. The workflow is getting onboarded and the benefit is having a developer who can use the thing to do client work, right. And then they have a set of benefits here and it's kind of nice that it's presented in a matrix this way. You can almost just see these things going up and down like I showed before. So that's a nice real world application and I have one more real world example from a client of ours of applying value map and the things that I've been talking about today and I'll take you through that and then I'd be really, really happy to take some questions. B13 is a digital agency in Stuttgart. The co-founder is the project lead of the Type 03 CMS. So that's sort of the grease of the Type 03 world. Type 03 is also PHP, Symphony Components, PSR standards. Same set of Legos that we use to build Drupal, they just, like their castle looks different. And it's a really nice bunch of people, it's a really nice community. And yeah, so here you have B13.com and there are several agency, agency sort of kind of your more product-y university, university. Who else was it? You have an agency? Yeah. So has any of you asked yourself, this is nice, Jen, but we don't have products, we sell services? I'm so glad that you nodded your head. So they came to us and they asked us for some help with some case studies and then one thing led to another and their clients. We decided that we could apply this value mapping also to a services-based business in that we had a long set of really interesting conversations with them about what they were good at. What are your product project patterns? In the UK it's always gonna be non-profits, right? Like NGOs and that just seems to be such a huge thing in Drupal and here. It turns out that this agency has a really awesome track record doing media and publishing solutions. They do a bunch of really highly multilingual projects for big corporates selling in lots and lots of markets. They do centralized information management. They do like really, really complex information solutions online like an entire hospital system with every clinic, every doctor, every disease, every research institute. So we talked them through and they have performance as well. So we decided that each of these areas, the things that they did over and over again, we decided to treat those as products and we did a value map exercise for highly performance solutions, for media solutions, for international decisions and so on. So we did the whole value mapping exercise, treating those as if they were products and this led us build a landing page structure. The stuff we're working on, these like the things that they use to go in there, backing up their expertise. So we're going into SEO territory a little bit, right? Like case studies and so on. But here we have the products that we value mapped. And so if we go to this solutions page for a second, you can see performance driven websites and so on, each of these has a landing page. And here's already, let's see. So listen, so performance driven websites, websites that deliver what your customers need fast on any network and any device are key to your success. So this is a, anyone paying attention? It's a benefit, right? Performance websites rank higher in search engine results, keep visitors attention longer and produce better conversion rates. So that's what you could have if you get one of those. Read more, okay. So keeping in mind that this is a, comes from a value map. This is the sum, most of this page and we have these features and these feature areas. So it doesn't matter really what order they're in, but each of these things we thought about it and there's a statement, roughly a value statement about the thing as a whole, kind of what it is, what it does, what it delivers. And then individual features that go into each of these things, why should I have caching and like a few facts. And this all comes from the value map. So these are the, basically the value statements about the individual features and they're boiled up into this statement and then a sub area of the fact that they build performance websites. We get to the last one of those. They specialized in building pages with the AMP format. And so here we can look at, we do AMP and what AMP is. Okay, so a little, a couple of facts about AMP and then a fact like, here's a challenge, large font files can lock your site's rendering. AMP makes that an efficient process and how it does it, right? So this comes straight out of the value map into polished web copy and then boiling all of that up. All of the facts that we collected about building a performance website. The structure here that you'll see is this is the benefit of having performative websites. This is the challenge that you're facing and this is how the agency solves it. So we have a format that's, in this case, always benefit challenge solution. This is not called performative websites because we actually did some SEO research and make typo three faster and its German translation rank way higher. So we also want them to have some more business. So I hope that you could see in this case, this is a pretty clear example of taking a lot of facts and boiling them up two or three times until we get to a clear understandable positioning. A business person can read this, the CTO can go and read this and then actually someone can go and do the real research on the technical level and make sure that none of us are talking crap. So we have fact-based sales and because these guys are my clients and because they're my friends, I actually know that these structures that we've had online for eight months, nine months maybe, their sales have improved and they're able to have better sales conversation. So when your equivalent is going out and pitching people, we've also got basically this kind of high-powered brochure ready to go and ready to send them to things. So I really think it's important that we as open source practitioners as fact-based thinkers, as transparent business people like we are in our weird, beautiful part of the world. I think it's really, really important that we can now make our sales processes transparent and reality-based and that we can also connect everyone into the vision of what we're doing and the value that we deliver with it. Are we there? Did we get there? Yes? Okay, thank you. Do you have questions? So you said it's a living documentation that you produce. Where do you encapsulate that? What tools do you use to keep that in one place? Right, so for the microphone, Do you review the question? Yes, and also for the record, for Kevin's box, the question was, we call this living documentation. We were thinking about calling it marketing documentation but I'm not sure that having the word marketing in it helps us with all the people involved. How do we maintain it and how do we keep it up to date? So in an ideal case, we or the team, you, whoever it is maintaining this, you should be revisiting it every feature release, every update, every change and tracking along with that and making sure that it still makes sense. A lot of these generic sales-flavored things are not going to change with a specific, with a minor point update of something but there are facts and adding new features and so on can change the constellation. We currently use a lot of spreadsheets and we have some particular formats for presenting the strategic framework and maintaining it and keeping it. We are looking into turning this into software and we are very much so we have, so our not-so-secret sauce essentially is that strategic framework that I showed you in the hexagons and links to an entire writing and editorial process that's also highly systematic and highly modular so that we can hand off the creative tasks between us and clients and it doesn't matter what language we do them in, it doesn't matter if we deliver the whole thing or only a piece of it. We are going to open-source a great deal of these and the templates and the ideas that we use we're piece by piece going to putting that out online and it's why I'm telling you today. It's pretty clear that if features and workflows and benefits can all have one-to-n relationships with each other that it's gonna have to go into a non-relational database and use MapReduce functions but then once we really get that thing together I'm really excited about the idea of figuring out how to do the data entry so that I can say feature area X for project managers and such and so what are the stories that I should be telling? And we can do that manually, we can follow those threads but it's still a lot of donkey work, a lot of hard work, right? But we have a lot of spreadsheets basically. Tip. So what's the difference between that and say traditional positioning exercises that an agency might go through so if you think about the service side of things about if you're trying to create a new position of market, so what's- Yeah. What is the difference between what we are doing and a traditional positioning exercise? The other positioning exercises that I have experienced in various capacities feel very top-down and they feel very, this is not judgmental, it feels to me like it's, in fact, industry research, who do we believe we are? What do we believe we do for whom? What are other people saying about it? Go. From the top down. If we are a business of type X, therefore a business of type X does why things that must also be us, how do we paint ourselves a different shade of blue or how do we try and differentiate? But it feels to me very top-down and it feels to me often powered by guesswork and by buzzwords, right? And we hate buzzwords and we hate that kind of marketing and I get to show you the slide that I wasn't allowed to have in the presentation anymore if I can figure out how to unskip it in this. We hate that and it's one of the reasons why we founded the company. This is, no, I can't do it. Without turning this off. This is fact-based and we do the hard work to go in down to the feature level and work up and connect position with factually what we can deliver and factually what we do and I think it's a lot more work and it's a lot harder and it takes a real combination of, we're not domain experts for all of the technologies that we work with but we have some highly developed, frankly, journalistic techniques and interview-based creation and discovery so that we put together the facts and then maybe take a brain-like mind that can see the patterns or whatever or write pretty words and come up with a position but even the positioning that I showed you even if it's, and this is not strictly for public consumption, it's not final copy or anything, right? And there's a lot of creativity in there but still this is after a lot of really putting in the work to understand exactly at the most fundamental level how the different subsystems work, how that benefits me in the different personas and so on to come up with a DDEV-DEV to deploy platform helps you deliver your web projects faster, better, simpler, anywhere you need them, right? There's 19 words to talk about a product that we've really researched at the, so long answer, but I think there's a really fundamental difference which is it's facts-based. Is that position so good for you, Steve? Yeah, I was just gonna say, the other thing that we did, someone asked about old replacements, I mean spreadsheets are really, it might sound old-fashioned, but when the Google Docs is because we're all distributed, it really helped us collaborate on them, right? Okay, which is a great topic for the room today, yeah. I thought it was, but then the other key part is that we had to iterate this. I don't know how many times we did this, maybe half a dozen over enough of a window that you get the bottom up with respect to the people who built the product. Right. And the things that they thought were related to positioning, once we started talking to the market, we realized, this doesn't matter, right? Some of that stuff doesn't matter, so your developer, they thought, oh Kubernetes, the market doesn't care what technology we use, so the iteration to me was important, getting all of the respect that people built into the teaching, or do you think as people, who you're talking about potentially consuming and all of that sort of took shape over multiple iterations here, and I thought that was a value-intensive one. Awesome. And a little bit to your point about keeping it updated as well in this, so the question, so Steve pointed out that the fact that we used Google Docs and that we're all working, you know, Steve is sitting in Denver, I'm sitting in Cologne, and we're all working together, I mean, that's a big issue for all of us right now, the remote thing, so Steve felt really enabled, so we've become quite practiced at online workshops, and I suppose the thing, I didn't really talk about the feedback and iterate part of this, it's really, really important to check if it's still true and check if it's still relevant, and before DDEV launched, we thought, oh Kubernetes, and we thought containers, and we thought like, oh technical, because that's a geeky cool stuff, ah, right, in the end, that doesn't matter to the public so much, and once they had test users, and once we had gone out, and Steve had tried to pitch some more investors, we got a different feeling for what the priority of the stories was, and then we can keep our facts, but we prioritize what we communicate about them and discover, and then when you have clients, and you have advocates, and you have champions, right, then you go in and you do another, we've done this a couple of times, and it's really, really awesome, when you have people who love using a product, and you just, you walk into the workshop, and you have all that stuff ready that I talked about, but you say, what is it that you love about using this thing, and they go, boom, and then you have this incredible, and if you've done it right, there's a like, they back you up on half the thing, 75% of the things you were talking about, and then they tell you things that none of the room thought of, right, because they're the actual end user, and you don't have end users when you're still like trying to lock something, so thank you for that, Steve. We are at the end of my slot. Thank you so much for inviting me. Thank you for all of you for coming out. You made my next month of quarantine in the UK worth it. I'm really happy to talk about this and the other pieces of what we do. Obviously, I made a company around it, and thanks for listening, and it's really, really flattering. I have stickers and business cards and all that jazz.